SFP+ Says 10 Gbps, the Dashboard Says 10,000 Mbps — Both Are Right
When you slot a 10 Gbps SFP+ optic into a switch, the transceiver label reads "10GBASE-SR" and the spec sheet says "10 Gbps." SSH in and run show interface tenGigE 1/0/1 — the output says "BW 10000000 Kbits/sec," and your monitoring dashboard graphs it as "10,000 Mbps." Nobody's wrong. The hardware negotiates at 10.3125 Gbaud (64B/66B encoding adds ~3% overhead to the line rate), and the switch OS reports throughput in the unit the rest of the system expects — Mbps. The optic does not care what unit you label it; it pushes the same photons regardless.
The conversion exists for a practical reason. A switch chassis might have 1 Gbps management ports, 10 Gbps SFP+ uplinks, 25 Gbps SFP28 server-facing ports, and 100 Gbps QSFP28 spine uplinks. If each reported in its native unit, an engineer would see "1," "10," "25," and "100" — and the "1" could be a healthy management port or a server port that lost 90% of traffic. Converting to Mbps — 1,000, 10,000, 25,000, 100,000 — makes outliers instantly visible. SNMP MIBs feeding PRTG or Zabbix return raw octet counters; the tool divides by the polling interval and displays Mbps. The dashboard's Y-axis covers 10 Mbps to 400,000 Mbps — a shared unit keeps the scale linear and alert thresholds uniform across every port.
Why Network Architects Live in Mbps, Even at 400 Gbps Scale
Network design happens in Gbps. Documentation happens in Mbps. The gap between the two is where most configuration errors breed, and the fix — standardizing on Mbps for all written specs — is older than most engineers writing them today.
Early Ethernet (10 Mbps, 100 Mbps) was natively in Mbps. Gigabit Ethernet arrived in 1999, but by then every management tool, SNMP MIB, and carrier SLA was built around Mbps — rewriting them would have broken monitoring for every network on the planet. The industry translated at the human layer: think in Gbps at the whiteboard, document in Mbps in the config. A typical project involves four or more conversions: marketing says "deploy 100 Gbps spine," the RFP documents 1,200,000 Mbps of server-facing capacity, the QoS policy reserves bandwidth 5000 (5,000 Mbps for storage), monitoring alerts at 85,000 Mbps (85% of a spine link), and the VP slide deck converts back to "2.0 Tbps." Four multiply-by-1,000 operations — trivial on paper, dangerous at 2 AM during a maintenance window. The ones who get it wrong explain an outage to a director the next morning.
The 400 Gbps example is instructive. 400 Gbps = 400,000 Mbps. A QSFP-DD optic pushing customer traffic through a DCI carries VLANs, VXLAN tunnels, and MPLS LSPs whose bandwidth reservations — 200 Mbps for a trading VLAN, 50,000 Mbps for storage replication — are all configured in Mbps. Nobody writes "0.2 Gbps" for voice; they write "200" because the CLI parser was built when 100 Mbps was the ceiling and no one added unit suffixes. The convention is institutional — every CCNA learns it, every CCIE lives by it, and AWS and Azure capacity planners inherit it when Direct Connect and ExpressRoute portals report in Mbps.
Mbps = Gbps × 1,000 Gbps = Mbps ÷ 1,000
Network speeds are strictly decimal SI: 1 Gbps = 1,000,000,000 bits per second. No 1,024 trap here — that belongs to storage.
The Backbone Engineer's Daily Conversions
10 Gbps SFP+ server uplink → 10,000 Mbps
show interface eth1/1 reports "8,450,000,000 bits/sec" — divide by 1,000,000 and your dashboard shows 8,450 Mbps (84.5% utilization). To reserve 20% for voice, you write bandwidth 2000 — 2,000 Mbps, not "0.2 Gbps" — because the CLI expects an integer in Mbps or Kbps. Get the unit wrong and you have silently reserved 1,000 times too little or too much bandwidth, an error that survives show run because the number looks plausible in either unit.
ISP peering at an Internet Exchange — 100 Gbps port → 100,000 Mbps
At DE-CIX Frankfurt or AMS-IX Amsterdam, the peering port is sold as "100 Gbps" but the IXP portal graphs traffic in Mbps — smaller peers at 1 Gbps (1,000 Mbps) and 10 Gbps (10,000 Mbps) share the same Y-axis. When the 95th-percentile touches 85,000 Mbps, the peering coordinator orders another 100 Gbps port — the Mbps number triggers the purchase order. At 800 Gbps (800,000 Mbps), a single IX fiber pair carries more traffic than the entire internet did in 2002. The Gbps figure makes the press release; the Mbps figure pays the invoice.
Data-center spine-leaf with 25 Gbps ports → 25,000 Mbps per port
A leaf switch with 48 × 25 Gbps downlinks has 48 × 25,000 = 1,200,000 Mbps (1.2 Tbps) of server-facing capacity. Four 100 Gbps uplinks provide 4 × 100,000 = 400,000 Mbps — a 3:1 oversubscription ratio computed in Mbps first, then converted to Tbps for the design-review slide. The spreadsheet column is labeled "Mbps" because when you sum 48 port rows mixing 1 Gbps, 10 Gbps, and 25 Gbps, a raw Gbps column produces single-digit and double-digit numbers where a stray "1" could be 1 Gbps or 10 Gbps post-typo. Summing in Mbps — 1,000 + 10,000 + 25,000 — makes the arithmetic self-documenting.
Carrier MPLS WAN — 1 Gbps delivered as 1,000 Mbps on the NID
The SLA says "1 Gbps CIR." The NID reports "1000 Mbps" and guarantees 999 Mbps — reserving 1 Mbps for OAM keepalives. Your NOC polls SNMP ifInOctets every 60 seconds, divides by the interval, and displays Mbps. A grey line at 950 Mbps means "open a ticket" — 50 Mbps below committed rate. The Mbps granularity is what makes SLA monitoring possible; at Gbps resolution, a 50 Mbps drop is 0.05 Gbps — invisible rounding noise on a graph whose Y-axis goes to 10.
Common Backbone Link Speeds in Both Units
| Transceiver / Standard | Gbps (marketing) | Mbps (config / monitoring) | Typical deployment |
|---|---|---|---|
| 1G SFP (1000BASE-LX) | 1 Gbps | 1,000 Mbps | Legacy access, management uplinks. |
| 10G SFP+ (10GBASE-SR) | 10 Gbps | 10,000 Mbps | Server uplinks, campus distribution. |
| 25G SFP28 (25GBASE-SR) | 25 Gbps | 25,000 Mbps | Top-of-rack, hyper-converged storage. |
| 100G QSFP28 (100GBASE-SR4) | 100 Gbps | 100,000 Mbps | Spine-leaf fabric, ISP peering, DCI. |
| 400G QSFP-DD (400GBASE-SR8) | 400 Gbps | 400,000 Mbps | Hyperscaler DCI, next-gen IXP ports. |
| 800G OSFP / QSFP-DD800 | 800 Gbps | 800,000 Mbps | Emerging: AI-training clusters, 51.2 Tbps switch ASICs. |
Every "Mbps" value is Gbps × 1,000. Optics market in Gbps because bigger numbers sell; monitoring reports in Mbps because the same dashboard must show a 100 Mbps port and a 400,000 Mbps spine link without a unit toggle. That is the operational reason the Gbps-to-Mbps conversion exists — not math for its own sake.
From Peering Agreements to Your Speed Test: Where the Gbps-to-Mbps Translation Actually Happens
When you sign up for "1 Gig" fiber, the contract says 1 Gbps. When you run a speed test, it says 940 Mbps. Three distinct Gbps-to-Mbps conversions happened in between, and none are a lie.
The first is physical: Ethernet frames carry a 7-byte preamble, a 1-byte delimiter, and a 12-byte interframe gap — 20 bytes of protocol overhead per frame. For 1,500-byte payloads, that is ~6% of the 1,000 Mbps line rate, leaving ~940 Mbps of usable throughput. This "Ethernet tax" exists on every link from 10 Mbps to 800 Gbps.
The second is the speed test's UX choice. Ookla, fast.com, and Google display Mbps even on multi-gig connections because Mbps has been the consumer unit since the DSL era, and integer results (940, 1880) are easier to compare than decimals (0.94, 1.88). An ISP marketing "2 Gig" hopes you do not notice the test shows 1,880 — market it as "2,000 Mbps" and the same number feels like a 6% haircut.
The third is upstream aggregation. Your GPON port at the neighborhood OLT is shared across 32–64 households on a 2.488 Gbps pool (32:1 oversubscription), and your ISP's 100 Gbps peering port at an IX serves tens of thousands of subscribers. The Gbps on your bill is a statistical promise; the Mbps on your speed test is actual throughput on your timeslot right now. The infrastructure engineer reads both in Mbps — 1,000 for the subscriber, 2,488,000 for the OLT, 100,000 for the peering port — because those are the units the monitoring stack reports.
Engineering Context
Gbps-to-Mbps is a bit-rate scaling conversion — it translates the big number on the transceiver label to the smaller number the config file expects. Optics are marketed in Gbps (10G, 25G, 100G, 400G), but SLAs, monitoring thresholds, and QoS policies are written in Mbps. The conversion is always a clean ×1,000 — no 1,024 trap — because network speeds are strictly decimal SI under ITU-T and IEEE 802.3. The 1,024 confusion belongs to storage (see the Data Storage Guide). For the reverse consumer-facing conversion, see Mbps to Gbps. For scaling at smaller magnitudes: Mbps to Kbps and Kbps to Mbps. For the capacity side (bytes, not bits): MB to GB and GB to MB. The bits-to-bytes bridge is always ÷8 — and that trap catches more engineers than the Gbps-to-Mbps multiplication ever will.
More: mbps to gbps · mbps to kbps · kbps to mbps · gb to mb · mb to gb · Guide
Related Unit Converters
Frequently Asked Questions
Why does my switch CLI show interface bandwidth in Kbps or Mbps instead of Gbps?
Legacy CLI parsers were written when Fast Ethernet (100 Mbps) was the ceiling, and the bandwidth command was designed to accept an integer in Kbps. Cisco IOS takes the bandwidth value in Kbps — so a 10 Gbps interface is configured as bandwidth 10000000 (10,000,000 Kbps = 10 Gbps). Newer platforms support "k" or "m" or "g" suffixes, but the default output format is still Kbps or Mbps because the show interface formatting code predates widespread gigabit adoption. Changing it now would break countless scripts that parse CLI output — network automation depends on stable text formats far more than human-readable unit labels. The same reasoning is why SNMP MIBs return interface counters in raw octets: the conversion to Mbps happens in the monitoring tool, not the switch.
Is there ever a case where Gbps-to-Mbps uses 1,024 instead of 1,000?
No. Network speeds are unambiguously decimal under ITU-T and IEEE 802.3. 1 Gbps = 1,000,000,000 bits per second, always. The 1,024 multiplier exists in two places — RAM (1 GB = 1,073,741,824 bytes) and storage marketing (a "1 TB" drive is 1,000,000,000,000 bytes but your OS shows ~931 GB because it uses binary). Networks never inherited that ambiguity because the bit-per-second unit was standardized by telecom engineers from the decimal metric world, not the binary-addressing world of memory. If you see an article applying 1,024 to a bandwidth conversion, it is wrong. For the full explanation, see the Data Storage Guide.
How do I estimate real download times from a Gbps figure?
Convert Gbps to Mbps first (×1,000), divide by 8 for MB/s, apply a ~0.94 Ethernet framing overhead factor, then divide your file size by that figure. A 100 GB game on 10 Gbps: 10,000 Mbps ÷ 8 = 1,250 MB/s × 0.94 = ~1,175 MB/s. 100 GB ÷ 1,175 MB/s ≈ 85 seconds. On 1 Gbps home fiber: 1,000 Mbps ÷ 8 = 125 MB/s × 0.94 ≈ 117 MB/s, so the same 100 GB takes ~14 minutes. These numbers assume the server saturates the link — Steam's CDN usually can, a random website probably cannot. On Wi-Fi, halve the estimate before you start; a 10 Gbps server uplink to a laptop on 802.11ac at 400 Mbps real throughput is the bottleneck, not the wire. The infrastructure perspective: the Gbps figure is the ceiling; the Mbps figure of the weakest link is the floor.