Multiple GigE cameras on one computer: bandwidth and CPU budget

Twenty gauges to watch and one computer to watch them from: the question is not whether Ethernet can carry that many small streams, but how much link and CPU each camera really spends. The numbers are small — a 640 × 480 monochrome stream at 10 fps is about 24.6 Mbit/s — so the arithmetic works, provided you do it before ordering. Work through this page and you can compute each camera's bitrate from the mode you will actually run, size the adapters and switch, set packet size and trigger spacing with numbers, and recognize the one camera that has outgrown the GigE plan.

The decision up front

Twenty 640 × 480 monochrome cameras at 10 fps draw about 492 Mbit/s in total: half of one 1 Gbit/s port. One network adapter and one dedicated switch carry the whole build. Hold every camera near or below 35 Mbit/s — its share of a 700 Mbit/s design budget — and one port serves twenty cameras. Cross that line and the fix is another adapter port plus another switch group, not a smaller sensor.

On the host, count packets rather than megabytes: twenty small streams cost roughly 42,000 packets per second at the default packet size and about 7,000 with jumbo frames. A current vision controller absorbs either without strain. The failure mode is not the average — it is twenty simultaneous triggers landing in the same millisecond, and that is a wiring decision, not a purchase.

Bandwidth per camera: the number everything follows

One formula produces every figure on this page:

Bytes per pixel follows the pixel format: 1 for 8-bit mono or Bayer 8, 2 for unpacked 10- or 12-bit mono, 3 for RGB 8. Compute from the mode you will actually run — ROI cropped, trigger-limited frame rate, mono where colour adds nothing — because the link carries the running mode, not the data-sheet headline.

The 70 % design load leaves about 30 % of the line free for protocol headers, packet resends and frames that bunch above the average. For the twenty-gauge brief the first row is the row to order against: about 25 Mbit/s per camera.

Worked example: twenty 640 × 480 cameras at 10 fps on one computer

Inputs:

• 20 cameras, each 640 × 480 px, mono 8-bit, 10 fps — the gauge-monitoring brief
• One 1 Gbit/s Ethernet port on the host computer
• Design load: 70 % of line rate = 700 Mbit/s

Rule: total link load = camera count × bandwidth per camera, and it must sit under the design load.

Arithmetic:

• Frame: 640 × 480 = 307,200 px
• Frame size: 307,200 px × 1 B/px = 307,200 B ≈ 0.31 MB
• Per camera: 307,200 B × 10 fps = 3.07 MB/s = 24.6 Mbit/s
• Total: 20 × 24.6 Mbit/s = 492 Mbit/s
• Line use: 492 / 1,000 = 49 % of raw rate; 492 / 700 = 70 % of the design budget

Result: the build fits one port exactly as budgeted, with no room for a twenty-first camera.

Decision: order one 1 Gbit/s adapter and one switch with 21 ports or more. The per-camera ceiling is 700 / 20 = 35 Mbit/s. Raise any camera to 1280 × 960 at 10 fps and it alone takes 98.3 Mbit/s: 1,228,800 px × 10 fps × 8 bit. Only 7 such cameras fit per port (700 / 98.3 = 7.1), so twenty of them need three adapter ports.

CPU load: count packets, not pixels

The host cost of a GigE Vision stream rides on packet count: every packet takes an interrupt, a driver pass and a protocol-stack pass, whether it carries 200 bytes of image or 8,000. The estimate is one line:

At the default Ethernet frame size a packet carries roughly 1,450 B of image data, so the example camera moves 3,072,000 B/s ÷ 1,450 B ≈ 2,120 packets/s, and twenty cameras together about 42,400 packets/s. With a 9,000-byte MTU the payload is roughly 8,900 B, so the same stream costs 3,072,000 ÷ 8,900 ≈ 345 packets/s — about 6,900 across twenty cameras, a six-fold cut in host work.

As a planning figure, one stream at default packet size on an untuned adapter costs on the order of 5-10 % of a CPU core; jumbo frames plus the high-performance NIC driver path pull that down sharply. Set the packet size before the first acquisition starts and match it on camera, switch and adapter — mismatched MTUs are the classic cause of incomplete frames on a multi-camera host.

Switch and NIC layout for twenty cameras

Keep the cameras off the office network. Give them one switch, connect that switch to the host with one cable per adapter port, and let nothing else onto the switch. The planning order is fixed: divide the cameras into groups by bandwidth first, then buy ports — the multi-camera link budget shows the division, and the six-camera switch plan scales it to a full switch. Even two cameras on one host reward the same port and bandwidth bookkeeping.

Two layout rules carry most builds:

1. One subnet per adapter port. A second port on the host lives in a different subnet, and reaching cameras across subnets without direct cabling is its own bookkeeping exercise — see how to reach GigE cameras from another subnet.
2. Count the cameras as ports: a twenty-camera, one-adapter build wants 21 switch ports and an uplink that carries the full 492 Mbit/s. For shared switch gear, the port and bandwidth plan sets out the arithmetic.

Cat5e or better carries 1 Gbit/s to 100 m per run, so gauge cells scattered along a line reach one switch placed at the middle.

Trigger timing: the failure that averages hide

The 492 Mbit/s figure is an average, and averages hide the instant all twenty fire together. One strobe into twenty cameras at once demands 20 × 0.31 MB = 6.1 MB inside a single exposure window; the switch buffers whole frames, resends climb, and the images come back with holes where packets never arrived. A resend ratio climbing above its normal level is the symptom to watch on the host.

The fix is ordering, not bandwidth. At 10 fps the frame period is 100 ms, so pulse camera n 5 ms after camera n − 1: (n − 1) × 5 ms, twenty slots, one camera per slot. Each stream then rides alone and the link stays near the average. Most GigE cameras also expose a packet delay — the spacing between packets of one frame — which spreads traffic wherever cameras share a link. And if 5 fps is enough for monitoring, drop the rate: bandwidth scales with fps, to about 246 Mbit/s at half the rate.

Power and cabling for twenty cameras

A GigE camera needs power in addition to data. At twenty cameras the clean answer is power over Ethernet: one cable per camera carries both, at roughly 15-30 W per port for the common PoE classes, delivered by a PoE switch or by a controller with PoE camera ports. The alternative is a 24 V distribution rail with one fused drop per camera.

Cable runs reach 100 m on Cat5e or better; put locking collars on both ends so a brushed connector does not take a camera offline. On moving axes use drag-chain-rated cable; on fixed runs, pre-terminated cable skips the crimping.

The LS-CBL-0117 is a 15 m RJ45 camera data cable with a locking stud, sized for a long fixed run. The LS-CBL-0199 is a 3 m high-flex GigE cable with screw locks, made for drag-chain service. Longer and shorter options sit in the camera cable range.

Cameras and controller for a twenty-camera build

At VGA-class resolution the candidates are ordinary area scan cameras, not specialised models. For reading a gauge face, a 2.5 MP GigE camera with a global shutter covers the dial plus mounting margin, and an ROI cropped to the dial pays only the bandwidth the crop uses.

The MV-CU020-90GC is a 2.5 MP color GigE camera with a global shutter and a C-mount. Crop its ROI to the gauge and the stream lands far below the 35 Mbit/s per-camera ceiling.

Pick the computer by adapter port count first, then by headroom for the packet rate. The VGA build needs one port; the 1280 × 960 build needs three. Three controllers bracket that range from a compact starter upward.

All 3 share: Certification CE, KC. Values as printed in each product's data sheet; open a part for its drawing and full specifications.

The MV-VC2140-128G40-1T carries three to four LAN ports and four built-in light channels on an Intel N-series processor. The MV-VC3301H-128G66 moves up to five-plus LAN ports, a Core i3, PCIe expansion and an included VM license, with four light channels for strobes at the stations. The MV-VC5525-256G70-NN is the loaded option: 32 GB of memory, five-plus LAN ports, PoE camera ports and eight light channels.

Filter the camera range by interface and resolution, or start the configuration at the camera and let the rest follow the budget.

Checklist before you order

1. Write each camera's mode — ROI, fps, pixel format — and compute its Mbit/s with the formula. The budget follows the running mode, not the headline spec.
2. Multiply by the camera count and divide by 700 Mbit/s per port; round up. That is the number of 1 Gbit/s adapter groups.
3. Reserve a dedicated switch: one port per camera, one uplink per adapter group, nothing else on the switch.
4. Fix a jumbo packet size — a 9,000-byte MTU is the usual value — identically on camera, switch and adapter, set on the camera before the first acquisition.
5. Order the trigger pulses: 5 ms steps across a 100 ms frame period at 10 fps, or packet delay where cameras share a link.
6. Power every camera: a PoE port at 15-30 W per camera, or a fused 24 V drop.
7. Estimate packets per second per adapter group and enable the high-performance driver path on the adapter before judging CPU headroom.

When twenty small cameras is the wrong shape

• One camera climbs past the 35 Mbit/s ceiling: give it its own port, or move it off GigE entirely — the frame-rate arithmetic for a high-speed camera shows where 10GigE and CoaXPress take over.
• The count shrinks to two or three cameras: USB3 on a dedicated host can be the simpler build, up to the limits in the USB camera bandwidth and power budget.
• The gauges only need a still image every few seconds: a compressed HTTP snapshot camera skips the bandwidth maths but returns compressed frames, loose exposure control and no trigger discipline — readable gauges, unreliable measurements.
• The cameras ride moving robots or long conveyors: drag-chain cabling and locked connectors stop being optional.

Where to go next

Size your own build with the formula, then pick parts in that order: group the cameras by adapter port, choose a controller with the port count the budget gives, and only then fix models and cable lengths. For a mixed layout — different resolutions per group, runs near 100 m, an existing switch cabinet — sketch the topology and send it through the contact page, and we will check the numbers with you. The systems topic page collects the rest of the link-budget planning.