Multi-camera GigE bandwidth budget: divide the link first

Add a second and a third GigE camera to the same switch, and frames start arriving late, banded or blank — with every camera working perfectly on its own. The cause is arithmetic, not hardware: a shared path carries a fixed number of bytes per second, and a simultaneous trigger asks every camera to push its frame at once. This guide gives you the budget the way we size it before ordering: 125 MB/s per gigabit path minus a 5 percent reserve for protocol traffic, divided by the cameras that share the path. You will compute each camera's demand from pixels, bytes per pixel and frame rate, enforce the share with the GenICam DeviceLinkThroughputLimit, stagger the triggers so bursts never queue, and recognize the layouts where the answer is one port per camera instead.

The ceiling: 125 MB/s per shared gigabit path

Gigabit Ethernet moves 1,000 Mbit/s, which is 125,000,000 bytes per second — 125 MB/s. Treat that as the gross budget for image data on any link carrying more than one camera: a switch uplink, or a single host port fed by a switch. After GigE Vision protocol traffic, heartbeats and the occasional resend, plan on 95 percent of the line rate — about 119 MB/s of image payload. The same arithmetic gives 12.5 MB/s on a 100 Mbit path and 1,250 MB/s on a 10 GigE path.

Each camera's cable into the switch is a dedicated gigabit link; the ceiling bites only where those links converge. So count shared paths, not cameras: two cameras behind one uplink share one 119 MB/s pool, while two cameras on two separate host ports share nothing. The switch side of the same plan — port counts and uplink sizing — is in GigE camera network planning: switch ports and bandwidth.

Divide the pool: the per-camera budget

If other traffic shares the path — PLC data, result images to a server — subtract its measured rate from 125 before the reserve and the division. Ten MB/s of results leaves 109 usable, so four cameras get about 27 MB/s each instead of 29.7.

Slices do not have to be equal: give the hungriest camera the largest share and keep the sum at or under 119. At eight cameras, 14.9 MB/s moves a 5.01 MB frame just under 3 fps — often the moment to re-plan the topology rather than the exposure. For the two-camera case worked end to end, see two GigE cameras on one host: NIC ports and bandwidth budget.

Check the demand before you divide anything

The budget is half the arithmetic; the other half is what each camera asks for:

Mono 8-bit images carry 1 byte per pixel; 12- or 16-bit mono and 8-bit color carry 2 and 3. Demand follows from the area scan camera you pick and the frame rate the inspection needs, so compute it before committing to a switch topology.

Worked example: four 5 MP cameras, one uplink

Take a generic 5 MP mono 8-bit camera, 2448 × 2048 pixels, at 5 fps, four of them behind one gigabit uplink:

• Frame size: 2448 × 2048 × 1 B = 5,013,504 B ≈ 5.01 MB
• Demand: 5.01 MB × 5 fps ≈ 25.1 MB/s per camera
• Path load: 25.1 × 4 ≈ 100.3 MB/s against the 119 MB/s budget — fits, with about 19 MB/s of headroom
• Cap: 26,000,000 B/s per camera — above the 25.1 MB/s demand, below the 29.7 MB/s share — so the path can never see more than 104 MB/s
• Transfer time at the cap: 5.01 MB ÷ 26 MB/s ≈ 0.19 s, so trigger offsets need to be at least 200 ms

Push the same line to 6 fps and it breaks: demand rises to 30.1 MB/s per camera and path load to 120.3 MB/s — over budget. Three fixes, cheapest first. Crop the ROI to 1224 × 2048: the frame halves to 2.51 MB and the load to 60.2 MB/s. Split the cameras 2 + 2 across two host ports: 60.2 MB/s per path, comfortably inside. Or move the uplink to 10 GigE, where the same 5 percent reserve leaves about 1,187 MB/s and four 6 fps cameras use just 120.3.

Enforce the share: DeviceLinkThroughputLimit

A budget nobody enforces is a wish. GigE Vision cameras expose a standard GenICam feature for exactly this. In your SDK's feature browser, open the Device Control group, set DeviceLinkThroughputLimitMode to On, and write the share into DeviceLinkThroughputLimit in bytes per second — 26,000,000 in the example above. Set it on every camera on the shared path; one uncapped camera ignores the budget for all of them.

Two details matter at setup. The camera rounds the value to its internal step, so read it back and use round numbers you can audit. And a cap below the demand does not raise an error — the camera paces its frames to fit, and the achieved frame rate quietly falls. If the fps on the line is lower than the sensor allows and you did not plan it that way, look at the cap first.

Set the cap together with the packet size: 9,000-byte jumbo frames cut a 5.01 MB frame from about 3,343 packets to about 557, which lowers CPU load and, with it, the resend risk. The ordering and the pitfalls live in set the GigE camera packet size before starting acquisition.

Stagger the triggers so bursts never queue

Average load and instantaneous load are different failures, and the cap fixes only the first. Four cameras firing on one trigger line push four frames into the switch in the same instant. At line rate a 5.01 MB frame lands in about 42 ms, so the switch can hold 4 × 5.01 ≈ 20 MB of backlog while the uplink drains it in 20 ÷ 119 ≈ 0.17 s. Compact switches buffer kilobytes to a few megabytes, not 20 MB, so the excess drops and returns as resends — the blank and banded frames covered in GigE Vision stream packet loss: diagnose blank frames.

The fix is offset triggers. On a 1 s cycle, delay camera 2 by 200 ms, camera 3 by 400 ms and camera 4 by 600 ms, so at most one frame is in flight at a time. The rule: offset between cameras at least the transfer time at the cap — 193 ms here. If that leaves no slack, buy some: at 5 fps the 200 ms period leaves a 7 ms margin over the 193 ms transfer, while 4 fps turns it into 57 ms.

Wire the offsets as a programmable trigger delay per camera or as staggered pulses from one source; the per-camera setup is in hardware trigger configuration per camera: stop the free run default, and the case where you actually want simultaneous exposure is multi camera exposure synchronization with a shared trigger. For the burst-into-buffer mechanism in general, see camera burst capture faster than link bandwidth: use the buffer, and the knowledgebase page on troubleshooting multi-camera frame drops on GigE cameras.

When the answer is one port per camera

Capping and staggering are for paths that must be shared. Up to four cameras, ask first why share at all: a host with enough Ethernet ports gives every camera its own gigabit link, its own 119 MB/s, and no burst problem to manage. The vision controllers in the shop are built around this: the MV-VC3301H-128G66 carries 5+ LAN ports, 4 built-in light channels, 8 GB of memory and an Intel Core i3.

On a plain host PC, add ports rather than a switch. The MV-GE1104 is a 4-port GigE frame grabber, and the MV-GE2002P is a dual-port PoE NIC for cameras powered over the cable. Cameras claiming the same address at boot is a separate, solvable problem: assign cameras to ports reliably in a multi-camera system.

A single camera whose demand exceeds 119 MB/s needs a faster path, not a shared switch: a 25 MP sensor at 10 fps, for example, needs about 250 MB/s. Step up the port speed with a 10GbE NIC — the MV-GT2104 is a quad-port copper 10GbE NIC. A 10GbE path carries 1,250 MB/s gross; after the same 5 percent reserve, about 1,187 MB/s. Port counts across the range are listed under frame grabbers, and the host controllers that carry those ports sit alongside them in the vision controllers category.

When the usual answer is wrong

Three layouts break the divide-and-cap plan, and each has its own fix.

Simultaneous exposure is the requirement — stereo, multi-view metrology, one event from four angles. You cannot stagger what must fire together, so do not share a path: one port per camera, or a 10 GigE link. Caps still help: sized so the sum of all caps stays under the path's drain rate, even simultaneous frames have nothing to queue behind.

The path carries measured non-vision traffic. Subtract it before dividing — with 10 MB/s of results on the uplink, four cameras get (125 − 10) × 0.95 ÷ 4 ≈ 27 MB/s, not 29.7.

The link is not running at gigabit. A damaged cable or a duplex mismatch can settle at 100 Mbit, and the whole plan silently becomes 12.5 MB/s in total; the packet size error that appears when a link drops below gigabit is the classic symptom. Read the negotiated speed on the switch port before blaming the cameras.

Checks before you order

Run this list against the layout before parts are ordered:

• Demand per camera computed: width × height × bytes per pixel × fps, in MB/s.
• Sum per shared path at or under 119 MB/s, or one more path added.
• A cap value per camera written into the setup sheet — 26,000,000 B/s in the worked example.
• Trigger offsets planned at or above the transfer time at the cap.
• MTU 9,000 agreed end to end: cameras, switch, host NIC.
• Host port count at least equal to the shared path count, with direct ports preferred for up to four cameras.
• PoE confirmed separately from bandwidth when cameras are powered over the cable: does my camera support PoE is a port check, not a bandwidth check.
• Downstream sized too — recording 100 MB/s of images is a storage problem of its own, covered in multi-camera recording to disk without dropped frames.

The decision for a four-camera line

For the worked line — four generic 5 MP mono 8-bit cameras at 5 fps behind one gigabit uplink — the decision is: share the uplink, cap every camera at 26,000,000 B/s, stagger the triggers 200 ms apart, run 9,000-byte frames end to end. That leaves about 19 MB/s of average headroom and a burst path that never queues.

Change an input and the branch moves. At 6 fps, split 2 + 2 across two host ports: 60.2 MB/s per path with caps around 55,000,000 B/s and offsets of at least 100 ms. If exposure must be simultaneous, drop the sharing and give each camera its own port. If one camera alone asks for more than 119 MB/s, go 10 GigE.

Size your own variant with the same four numbers — ceiling, division, demand, transfer time — then start at the camera configurator, or send the layout through the contact page and we will check the budget with you. The systems topic page collects the rest of the network-side guides.