GigE multi camera bandwidth planning for six cameras on one switch

Six GigE cameras behind one switch are a bandwidth problem before they are a software problem. Frames arrive late or never, the client library gets blamed, and lowering the resolution in code does nothing, because the link saturated before the first pixel reached the PC. This guide gives you the arithmetic that settles it: the per-camera rate in Mbit/s, the usable rate of each uplink class, and the settings that decide whether six streams share a switch cleanly. It is written for anyone wiring several GigE area scan cameras into one host: inspection cells, sorting rigs, multi-station lines. Work the numbers first; the switch, the NICs and the camera settings all follow from them.

How much bandwidth does one GigE camera stream?

Multiply the width in pixels by the height in pixels, the bytes each pixel occupies and the frame rate, then multiply by eight: a 1920 × 1200 camera in YCbCr422 at 20 fps moves 92 MB per second, which is 737 Mbit/s.

Worked example, step by step:

• 1920 × 1200 = 2,304,000 pixels per frame
• 2,304,000 × 2 bytes (YCbCr422) = 4,608,000 bytes per frame, about 4.6 MB
• 4,608,000 × 20 fps = 92,160,000 bytes/s ≈ 92 MB/s
• 92.16 MB/s × 8 = 737.28 Mbit/s ≈ 737 Mbit/s per camera

The bytes per pixel follow from the pixel format the camera sends:

These are decimal megabytes (1 MB = 1,000,000 bytes). If your host tool reports MiB/s, the same stream shows as 87.9 MiB/s — identical bytes, divided by 1,048,576 instead of 1,000,000.

How many cameras fit on one switch uplink?

Divide the uplink's usable payload rate by each camera's rate: GigE carries about 950 Mbit/s of payload, 990 with jumbo frames, 2.5GBASE-T about 2,475 and 10GBASE-T about 9,900, so the example six-camera load of 4,424 Mbit/s fits a 10 Gigabit uplink only.

The usable rates are the line rate minus packet overhead: preamble, interframe gaps and headers take roughly 4.5% of a link at 1,500-byte packets and 0.7% with jumbo frames. Sum the example build: 6 × 737.28 = 4,424 Mbit/s.

• One GigE port: one 737 Mbit/s camera sits at 74% of the 990 Mbit/s payload rate with jumbo frames — it runs, but watch resends. Two never fit (1,474 > 990).
• One 2.5G uplink: two cameras sit at 60%, inside the 70% rule without pacing. Three reach 89% and fit only with pacing on.
• One 10G uplink: six cameras sit at 45%; even eight (5,898 Mbit/s) stay under 70%.

Decision rule: keep the planned sum at or below 70% of the usable rate without pacing, and at or below 90% with pacing enabled on every camera.

A 2.5 MP camera like the MV-CU020-90GC, a 20 MP one like the MV-CS200-10GC and a 12 MP one like the LS-CMR-0053 all obey the same budget:

The same divide-first method runs through the multi-camera GigE bandwidth budget guide, and the GigE camera network planning checklist covers the switch ports and subnets around it.

Why doesn't lowering resolution in software fix the link?

A software scaler shrinks each image after the camera has already pushed all 4.6 MB of it down the wire, so a client-side 690 × 432 reduction still costs 737 Mbit/s per camera; only camera-side settings cut link traffic.

Set the region of interest, the width and height, binning and the acquisition frame rate in the camera itself, before acquisition starts. A 1920 × 600 ROI in the example format moves 1,152,000 pixels × 2 bytes × 20 fps × 8 = 369 Mbit/s — exactly half, because the camera never transmits the rows you cut.

A client that reads slower than the camera sends is worse than a scaler: buffers fill, packets are dropped or resent, and latency climbs on every stream sharing the path. Cap the frame rate at the camera and let the host keep up.

Frames lost to a saturated link arrive as blank or torn images; the packet loss diagnosis for blank frames walks those checks in order.

Which pixel format should the cameras use?

Use the fewest bytes per pixel your algorithm accepts: Mono8 or Bayer RG8 costs 369 Mbit/s for the example stream, YCbCr422 costs 737 and RGB8 costs 1,106 — format choice alone is a threefold swing.

Take Mono8 when the task is geometry, presence or code. Take Bayer RG8 when color matters but debayering can run on the host, because it sends one byte per pixel like Mono8. Reserve YCbCr422 for pipelines that consume it directly, and RGB8 for algorithms that genuinely need unpacked color.

The same effect in reverse — sending packed RGB8 where Bayer RG8 would do — is the classic frame-rate drop described in BGR vs Bayer pixel format on GigE.

In-camera compression cuts the link rate only when your acquisition library implements the matching decompressor; without it, the payload decodes as noise. Turn it on once your client documents support, then budget with the compressed rate the camera reports.

Do jumbo frames and packet pacing matter for six cameras?

Jumbo frames cut each camera's packet rate roughly sixfold, from about 376,000 packets per second to 62,000 for six cameras, and pacing controls keep six bursty sources from colliding on one uplink — set both in every multi-camera build.

Ethernet frames larger than the standard 1,500-byte payload, called jumbo frames, reduce per-packet overhead from about 4.5% to 0.7% of the payload. At 1,500-byte packets, each frame on the wire costs 1,538 bytes (preamble, headers, FCS, interframe gap) and carries 1,472 bytes of UDP payload: 95.7% efficiency. The example camera then needs 737 ÷ 0.957 = 770 Mbit/s of line, and six need about 4,625 Mbit/s. At a 9,000-byte packet size, efficiency reaches 99.3%, the six-camera load falls to about 4,450 Mbit/s, and interrupts on the NIC drop from roughly 376,000 to 62,000 packets per second across the build.

Pacing lives in the camera's transport-layer controls: an inter-packet delay spaces the packets within one frame, a frame transmission delay staggers cameras against each other, and a throughput reserve leaves a slice of the line free for the rest of the build. Spread each frame's transmission inside one frame period — 50 ms at 20 fps — or pacing itself starts costing frames.

Most camera SDKs ship a GigE setup tool that assigns packet size and pacing across all detected cameras. Run it, then read back what it wrote and compare each value against your own budget.

When should you skip the switch and go 10GigE?

Move up a link class when the planned sum passes about 2,475 Mbit/s: the six-camera example needs 4,424 Mbit/s, which one 10GBASE-T uplink carries at 45 percent utilization and a 2.5 Gigabit uplink cannot carry at all.

Three topologies cover builds of this size:

1. One NIC port per camera. A quad-port card takes four cameras at up to 990 Mbit/s of payload each; two cards take six with no switch in the path. The two GigE cameras on one host guide works the per-port math.
2. A GigE switch with a 10 Gigabit uplink. Six GigE downlinks feed one 10G uplink at 45% utilization for the example load. Check switch packet-buffer memory, not only port count: six cameras bursting into a thin uplink is a buffering problem first.
3. 10GigE end to end, as with the MV-CH250-25TC-F-NF, a 25 MP camera with a 10GigE interface: fewer ports to wire, more per-camera headroom, one cable class up the rack.

A single camera stream cannot be split across two aggregated 1 Gigabit links; aggregation distributes whole conversations, so one stream rides one member link and stays near the GigE usable rate. When a camera needs more than one link's worth, browse the camera finder by interface, and check the host too: count free NIC ports and PCIe lanes before ordering, the same way you would size industrial mini PCs for the cell.

What should you check before ordering six cameras?

Write one line per camera — pixels, bytes per pixel, frame rate, Mbit/s — and keep the total at or under 70 percent of the uplink's usable rate: 6 × 737 = 4,424 Mbit/s passes against 6,930 Mbit/s on 10 Gigabit and fails on 2.5 Gigabit.

Then run this list:

• One line per camera: width × height × bytes per pixel × fps × 8, in Mbit/s.
• Sum against the uplink: at or below 70% of usable, or 90% with pacing on.
• Packet size (MTU) matched end to end — camera, switch ports, NIC; the smallest value rules.
• Delivered pixel format read back per frame, not the requested one.
• Camera-side ROI and frame rate; host-side scaling removed.
• Cabling: Cat 5e or better serves GigE and 2.5GBASE-T up to 100 m; 10GBASE-T needs Cat 6A for 100 m (Cat 6 reaches 55 m).
• PoE budget: the switch's total wattage covers all six cameras if they draw power over the link.
• Per-port counters on the switch checked during the first hour of running.

For the camera-to-switch runs, an RJ45 camera data cable with a locking stud keeps the connectors seated at both ends; the LS-CBL-0117, a 15 m camera data cable, covers a bench or cell length in that range.

Browse camera cables for other lengths and drag-chain builds, then start the camera configurator to pair cameras, links and host ports in one pass. The planning guides collected on the systems topic page cover the rest of the network.