A PoE switch runs out of power in a way everybody plans for. The budget adds up, a port sheds, a camera reboots, someone opens the web UI and sees the total at 96 %. It runs out of bandwidth in a way almost nobody plans for, and the symptom looks like a bad access point. The PoE log stays clean the whole time. That is why the fault takes three weeks to find instead of an afternoon.
In August I stood in a school in Bao'an with a laptop on a cleaner's cart, watching a 24-port switch I had specified eight months earlier. Twenty access points across two switches, one gigabit SFP uplink, PoE at 61 % of budget. Every afternoon the teachers' tablets stalled mid-video and the APs logged disassociations. The vendor had already swapped three APs, which fixed nothing. I ran a throughput test between two clients on the same switch: 941 Mbps, clean. Then the same test across the uplink: 610 Mbps and a rising retransmit count, with the interface already at 90 % before I started. Twenty APs, one gigabit pipe, forty percent power headroom. The watts were never the problem.
The Watts Were Fine, and That Was the Trap
Power failures in PoE are loud. A port that cannot deliver does something visible: it reclassifies, it drops the PD, it retries the detection handshake, it writes a line in the log. Even a marginal run usually announces itself as a reboot at dusk when the IR illuminator cuts in. You get a timestamp, a port number, and a device that misbehaves in a way you can reproduce.
Bandwidth failures are silent. Every device stays associated, every port stays up, no PoE event is logged, and the copper is clean because nothing is wrong with the copper. What you get instead is a vague complaint about slowness at peak hours, video that stutters but never quite fails, and a support ticket that gets closed as "wireless interference" because the wireless is the only thing anyone can see.
There is a structural reason for the blind spot. PoE is instrumented: a managed switch will tell you the watts per port, the class it negotiated, the total budget, the temperature. Bandwidth has an equivalent — interface utilization, queue drops — but it lives on a different page, it is not on the commissioning checklist, and by the time anyone looks at it the complaint has already been filed against the AP vendor.
My rule since that school: if the PoE log is clean and the complaint is speed, stop reading the PoE log and read the uplink counters.
What a Gigabit Port Actually Delivers
Gigabit Ethernet is a 1 Gbps line rate, and no payload ever moves at 1 Gbps. Every frame carries twenty bytes of overhead — seven of preamble, one start-of-frame delimiter, a twelve-byte inter-frame gap. At the 64-byte minimum frame that is 84 bytes on the wire per 64 bytes of frame, or 1.488 million packets per second per gigabit, the number on every datasheet. At that size you move 357 Mbps of frame content, not a gigabit.
Real traffic runs larger frames, so the arithmetic improves. With 1500-byte frames the port reaches about 986 Mbps of Ethernet payload; subtract 40 bytes of TCP/IP headers per packet and the useful number lands around 940 Mbps. That is the ceiling I measured in the school, and it is the ceiling in every building where someone says "we have a gigabit, that is plenty".
Multiply the same way and 2.5GBASE-T gives roughly 2.35 Gbps of payload, 10GBASE-T about 9.4 Gbps. The packet rates matter more than people expect: 3.72 Mpps for 2.5G and 14.88 Mpps for 10G at minimum frame size. A switch that advertises 60 Gbps of switching capacity but forwards 20 Mpps is a switch that will struggle with a camera VLAN full of small control packets long before it struggles with video.
Where the Traffic Actually Comes From
Cameras are cheap in bandwidth and expensive in watts. Access points are the opposite. Sixteen cameras on a PoE switch barely move a gigabit; eight Wi-Fi 7 APs can fill it. If your uplink saturates in a surveillance deployment, look at the recorder and at playback before you blame the cameras.
| Device on a PoE port | Typical sustained stream | Ports | Aggregate | What it does to a 1G uplink |
|---|---|---|---|---|
| 1080p camera, H.265, 15 fps | 1.5–2 Mbps | 16 | 24–32 Mbps | Nothing at all |
| 4 MP camera, H.265 | 4–6 Mbps | 16 | 64–96 Mbps | Under 10 % |
| 4K camera, H.265 | 8–16 Mbps | 16 | 128–256 Mbps | 15–27 % |
| 4K camera, H.264, motion-heavy scene | 12–25 Mbps | 16 | 192–400 Mbps | 20–43 %, plus playback |
| Wi-Fi 6 AP, 2×2, 80 MHz, busy hour | 400–700 Mbps | 8 | 3.2–5.6 Gbps | Saturated at four APs |
| Wi-Fi 7 AP, 2×2, 320 MHz, busy hour | 1.5–2.3 Gbps | 8 | 12–18 Gbps | Saturated at one AP |
The Wi-Fi 7 row is arithmetic, not a press release. A 2×2 tri-band AP runs 688 Mbps of PHY on 40 MHz at 2.4 GHz and 2882 Mbps on 320 MHz at 5 or 6 GHz — 3.57 Gbps aggregate. Protocol efficiency of 50–65 % puts the MAC ceiling at 1.8–2.3 Gbps. A gigabit port gives it 940 Mbps and no more, which is what every power-budget article about Wi-Fi 7 leaves out: the AP can negotiate its watts perfectly and still be strangled on the data side.
The Ratio Nobody Writes on the Quote
Oversubscription is the total access-port bandwidth divided by the uplink bandwidth. It is a normal design tool — no access switch is built non-blocking for worst case — but it only works when it is a decision rather than an accident.
Twenty-four gigabit ports with two 10G uplinks give 24 Gbps against 20 Gbps, a ratio of 1.2:1. That is healthy and standard. Now take the product that sells on the phrase "eight multigigabit PoE ports": 8 × 2.5G is 20 Gbps of access against a single gigabit uplink, a ratio of 20:1. On paper it is a multigigabit switch. In a rack it is a gigabit switch with expensive ports, and the first two APs that get busy will prove it.
The number I want before quoting any switch is the ratio with the uplink as built, not as optioned. This is how I work it out, and it takes about ten minutes once the device list exists.
- List devices by class, not by port count. Twenty APs are not twenty identical loads — count how many are 2×2 and how many are 4×4, and count cameras by resolution and codec.
- Use the sustained rate, not the peak. A 4K camera that bursts to 16 Mbps averages 8. A Wi-Fi 7 AP that peaks at 2.3 Gbps averages far less, and the honest way to get that average is to read it off the controller for a week.
- Sum the access side. Sixteen 4K cameras at 10 Mbps is 160 Mbps. Eight APs at 500 Mbps busy-hour average is 4 Gbps. Same port count, twenty-five times the traffic.
- Add 25 % for burst, control and broadcast. I-frames do not arrive politely staggered. A flat 1.25 multiplier is crude and it has never let me down.
- Divide by real payload, not line rate. 940 Mbps per gigabit, 2.35 Gbps per 2.5G, 9.4 Gbps per 10G. A 10G uplink is 9.4 Gbps of payload, and that missing 6 % is a whole camera's worth of margin.
- Check the single largest flow separately. Link aggregation hashes per flow. Two bonded gigabit links carry 2 Gbps of aggregate and still cap one TCP stream at 940 Mbps, which is the difference between a backup that finishes overnight and one that does not.
Run end to end: 20 APs at 350 Mbps each is 7 Gbps, plus 25 % is 8.75 Gbps. Against 2×10G in LACP — 18.8 Gbps of payload — the ratio is 2.1:1, with room for the second floor. Against one 10G at 9.4 Gbps it is 1.07:1: fine on paper, no headroom. That 350 Mbps is the load-bearing assumption, and I have not measured enough 320 MHz sites in production to defend it as typical.
What Multigigabit Costs: PoE Watts and Copper
Here is where the two budgets meet. A multi-gigabit PHY is not free, and the watts it burns come out of the same power supply and the same 1U chassis as your PoE budget.
On the boards I have measured, a 1000BASE-T port costs about 0.5 W at the PHY. A 2.5GBASE-T port is near 1 W. A 10GBASE-T port runs 2 to 4 W depending on chipset generation, and none of it appears in the PoE budget, because that figure is a PD-side output. Twenty-four 10GBASE-T ports put 50 to 90 W of heat into the box before a single camera is powered. Add a 400 W budget and you are designing a 500 W fan-cooled unit into a cabinet sized for a fanless 150 W switch.
This is why my preference is boring and consistent: 2.5G on the access ports, 10G on SFP+ for the uplink. An SFP+ port with an optical module draws on the order of a watt, has no 10GBASE-T crosstalk problem, and gives you the 10 Gbps where it is actually needed — the aggregation hop. If you must have 10GBASE-T on copper, price the thermal design and the fan noise, not just the port count.
The cable question, briefly
2.5GBASE-T and 5GBASE-T were invented to run on cable you already own, and they do: 100 m on Cat5e is in spec for both. 10GBASE-T forces a decision — 100 m needs Cat6a, Cat6 tops out near 55 m, and alien crosstalk between bundled runs shortens it in practice. A 10GBASE-T link that trains at 5G instead of 10G usually has a cable or termination problem, not a switch problem. The Cat5e, Cat6 and Cat6a comparison covers the 100 m channel on its own terms.
Where a copper uplink has to leave the cabinet or cross more than a hundred metres, the choice stops being about port speed. A media converter pair or an SFP uplink on the access switch moves the long hop to fibre and costs you a watt instead of four. That is usually cheaper than re-cabling a riser to Cat6a for a 10GBASE-T run that was never going to make 100 m.
Questions I Get Asked About PoE Uplinks
Does the PoE budget on the datasheet include the switch's own consumption? No. It is PD-side output — 802.3at at 30 W per port capped by a total, with the 12.5 Ω channel leaving 25.5 W at the device. Electronics, fans and PHY power sit outside it, which is why a 400 W unit ships with a 500 W supply. Size the input for the sum, and remember the supply derates in a closed cabinet.
Will a 2.5G port make a Wi-Fi 7 AP faster if the internet is only 500 Mbps? Not for internet traffic, and that is not what the port is for. It matters for everything that stays inside the building: controller-to-AP management, roaming key exchange, local NAS and backup traffic, camera-to-recorder streams, and the aggregate at the uplink when eight APs share it. The port is not there to serve one client's download. It is there so eight APs do not queue behind each other.
Can I just bond two gigabit uplinks and call it 2 Gbps? For many flows, yes. For any single flow, no — the hash picks one member and that flow stays at 940 Mbps. Bonding buys headroom for concurrency, not a faster pipe, and adds a failure mode when the two links land on different switches without a proper LACP configuration.
Do sixteen 4K cameras need a 10G uplink? Almost never. Sixteen cameras at 10 Mbps is 160 Mbps, and even the worst case in the table above is 400 Mbps. The multiplier is playback: three operators scrubbing recorded video pull three extra streams through the recorder's NIC, and the recorder is usually the bottleneck before the switch is. Measure the recorder's interface, not just the switch's.
Is the 100 m limit still 100 m at 2.5G? Yes on Cat5e, provided the run is genuinely Cat5e and the terminations are sound — 2.5GBASE-T was specified for exactly that. What changes is margin. A link that trained at gigabit with poor return loss may not train at 2.5G, and the failure shows up as a port negotiating down to 1G rather than dying. Check negotiated speed on every AP port after commissioning, not just link state — the same discipline as the six numbers worth writing down at handover, plus one line for rate.
Send Me Your Busy-Hour Uplink Number
What I would like from anyone running a mixed PoE estate is a single figure: uplink utilization at the busiest hour, and the port count behind it. I have a dozen of those from installations around Guangdong, and the pattern is consistent enough to be useful — camera-only switches sit under 20 %, AP-heavy switches sit above 70 %, and the ones near 90 % are always the ones where somebody chose the uplink to match the AP port speed rather than the AP count.
I will admit where the numbers are soft. Busy-hour average per AP is the weakest figure in the whole calculation — it depends on who is in the room, and no datasheet will tell you. The 940 Mbps payload ceiling and the packet rates are arithmetic. The PHY power figures come from boards on my bench, not a survey. Measurement, constant, range, in that order.
The practical version: instrument the uplink before you buy anything, count devices by class not by port, divide by real payload, keep 25 % for burst. Then look at the PoE side of the same PoE switch and ask whether the thermal envelope still supports the budget you wrote down. Power and bandwidth fail in completely different ways, but they come out of the same supply, the same chassis and the same afternoon of somebody's patience.