Two GigE cameras on one host: NIC ports and bandwidth budget

Connecting two GigE cameras to one host is a bandwidth question before it is a software question. One gigabit port carries about 118 MB/s of image payload, so two cameras that each run near full rate need twice that capacity, and no single gigabit link provides it. This guide gives you the per-port payload numbers for 1, 2.5 and 10 gigabit links, the two-camera sum that decides whether the cameras can share anything, and the three ways to connect the pair: one NIC port per camera, one aggregated faster-Ethernet link, or USB adapters. It closes with the driver, CPU and cabling checks that decide whether a compact host keeps up with both streams at once.

What one gigabit port really carries

A gigabit link runs at 1,000 Mb/s, which is 125 MB/s at the Ethernet layer. Ethernet framing, IP, UDP and the camera's packet headers consume about 5% of that, so plan on roughly 118 MB/s of image payload — near 950 Mb/s — per port. The figure assumes jumbo frames (9,000-byte packets) end to end over UDP, the way GigE Vision moves images. Three planning numbers fall out of the same arithmetic:

Any camera whose stream exceeds 118 MB/s cannot deliver its frame rate over 1 GbE at all. Two cameras whose streams sum past 118 MB/s cannot share one gigabit port in any topology. Everything else here is bookkeeping against those two sentences.

Add the two streams before you pick hardware

Eight-bit mono and raw Bayer output use one byte per pixel; packed RGB uses three. Compute each camera's stream, add the pair, and compare the total with the port numbers above.

Worked example. The LS-CMR-0053 streams 12 MP at 9 fps over GigE. One 8-bit frame is 12 MB, so the camera draws 12 × 9 = 108 MB/s, or 864 Mb/s. That single camera fills 92% of a gigabit port's budget: it needs a port to itself and cannot share with anything. Two of these cameras demand 216 MB/s. Two gigabit ports carry them at 108 MB/s per port; one multi-gigabit link carries the pair at 73% of its 297 MB/s; one ordinary gigabit port cannot, switch or no switch.

The same arithmetic sizes any pair. Two 2.5 MP cameras at 30 fps in 8-bit mono need 75 MB/s each, so the pair needs 150 MB/s — still beyond one gigabit port. Split across two ports, each link runs at 64%; carried on one multi-gigabit link, the pair runs at 51%.

Hold shared links at or below 80% of payload capacity: about 94 MB/s on 1 GbE, 238 MB/s on the 297 MB/s-class link. The margin absorbs frame-start collisions between cameras and the retransmission that follows a dropped packet. A dedicated port carrying one camera can sit closer to 100%, because the camera paces its own stream to the negotiated link rate — which is exactly how a 108 MB/s camera ships with a gigabit interface.

Option 1: give each camera its own port

One NIC port per camera is the default answer. Each port delivers its full payload budget with nothing else on the wire, no switch is needed, and commissioning is a matter of addressing. It works equally for full-rate pairs and near-full-rate pairs, which is why it is the first option to price.

The MV-GE2002P is a dual-port PoE NIC in full height, the standard card shape for tower and rack machines. For four cameras, or two cameras plus headroom, the LS-FGB-0004 is a 4-port PoE card on PCIe x4 built around an Intel i210AT chipset, and the MV-GE1104 is a 4-port GigE frame grabber designed for camera traffic.

Two practical points make it reliable. Give each port its own subnet — 192.168.10.x and 192.168.11.x, say — and bind each camera by IP so the same camera lands on the same port at every boot; the port assignment guide for multi-camera systems shows the mapping. Respect the slot as well: a PCIe x4 card runs at full speed in a x4, x8 or x16 slot and degrades in anything smaller, and PCIe slot compatibility for GigE cameras sorts out which slot is which. The PoE pins matter only for cameras that accept PoE power; otherwise they are spare capacity.

Option 2: aggregate both cameras over one multi-gigabit or 10G link

The cameras stay 1 GbE devices in this option. Both feed a switch, and the link from switch to host runs at 2.5G or 10G, so the two camera streams aggregate onto that one fast path. Everything above the cameras must match the aggregate speed: a switch with a multi-gig uplink, a host adapter of the same speed, and cables rated for it.

That symptom — partial images on both cameras, in bursts that track the trigger — is what the multi-camera frame-drop guide for GigE cameras helps you diagnose.

Size the fast link from the sum. A full-rate pair needs about 236 MB/s, which is 79% of the 297 MB/s payload budget — right on the planning margin, acceptable for pairs a step below full rate, thin beyond that. Above that sum, 10G carries any two-camera GigE cell with room to spare: 1,190 MB/s of payload against a 236 MB/s demand. On a PCIe host, the MV-GE4004 is a quad 2.5G Ethernet adaptor and the MV-GT2104 is a quad-port copper 10GbE NIC; either supplies the fast port plus spares.

Two details decide whether the fast link delivers. Cabling first: Cat5e carries 2.5GBASE-T to 100 m, while 10GBASE-T wants Cat6a, with Cat6 good to roughly 55 m. Second, set jumbo frames end to end — camera, switch ports, host NIC — because if any hop silently negotiates down to 1 GbE you will see packet-size errors instead of a clean slowdown; the packet-size error case shows exactly that failure.

Compact hosts take the same route through an M.2 socket wired for PCIe. One PCIe 3.0 lane moves about 1 GB/s, far above the 312 MB/s a mid-speed link needs, so lanes are rarely the limiter — the socket type and the chipset driver are.

The checks that decide it: driver, CPU and buffers

Driver support gates the project before speed does. Adapter listings name the chipset, and that chipset must run in your kernel for anything else to matter. Mainstream server chipsets have been in mainline Linux for over a decade; several consumer multi-gigabit chips only entered mainline from kernel 5.4 or 5.10 onward; and early silicon revisions of one widespread family carried hardware bugs fixed in later revisions. Search the chipset name together with your kernel version before you order, and prefer a long mainline history when the host is hard to service.

Where the camera maker publishes a tuned filter driver for the NIC, install it: the gains on sustained multi-camera streams are real (what a high-performance NIC driver gains).

Streaming cost tracks packets, not just bytes. One full-rate camera with 1,500-byte frames sends about 81,000 packets per second — 1,000 Mb/s ÷ (1,538 × 8 bits) ≈ 81,000 — and every packet costs interrupt and copy time. Jumbo frames cut the same traffic to about 13,800 packets per second. Plan per camera and double for the pair, and use interrupt moderation to buy CPU back at a latency price (interrupt moderation: latency versus CPU load). Desktop CPUs absorb two full-rate streams easily; compact boards can spend a large share of a core per camera, so measure one camera at its target rate before adding the second.

Duty cycle softens demand. A triggered station that streams in blocks can absorb the peak in the camera's frame buffer and drain it over the link at the average rate (burst capture against link bandwidth). The wire budget then applies to the average, with the buffer sized to the burst.

USB adapters: bench-worthy, second choice for production

A USB 3.0 port moves about 400 MB/s in practice, so the bus does not disqualify a USB-to-Ethernet adapter; a multi-gigabit USB adapter is not bus-limited. The weaknesses sit elsewhere: ports behind one USB controller share its bandwidth, adapter quality stacks driver quality on top of chipset quality, and hot-plug renegotiation mid-run is a failure mode a PCIe card does not have. One camera at moderate rate, or a bench test before the design freezes, suits a USB adapter fine. Two sustained streams in a machine that runs daily justify the PCIe or M.2 card. If USB is the only path, budget the controller's bandwidth like any other link — multiple USB cameras on one host works the sums.

When sharing one port is the right answer

Sharing is legitimate when the sum is small. Two 1.2 MP cameras at 30 fps in 8-bit mono need 36 MB/s each — 72 MB/s together, 61% of a gigabit port, inside the 80% margin — and they run through any decent switch. Sensor format moves the sum less than the frame rate does: the MV-CU020-90GC captures 2.5 MP with a global shutter. One 8-bit frame is 2.5 MB, so its share of the budget is 75 MB/s at 30 fps and 37.5 MB/s at 15 fps — same sensor, factor of two, set by the rate alone.

If the sum lands above the margin, cut pixels before buying hardware: crop the ROI at the camera and re-run the sum (ROI cropping at the source). Resolution you never inspect is bandwidth you pay for twice.

Order checklist

Work down the list and the topology picks itself:

• Sum both streams. pixels × bytes per pixel × fps per camera, added in MB/s — the one number that picks the topology.
• Compare with 118, 297 and 1,190 MB/s. The payload budgets of 1 GbE, 2.5GbE and 10GbE.
• Shared link, keep the sum at 80%. About 94 MB/s on 1 GbE and 238 MB/s on the mid-speed link; beyond that, split the ports.
• Either camera above about 94 MB/s alone. Give it a dedicated port.
• Name the adapter's chipset. Match it to your kernel version; prefer a long mainline history.
• Check slot and card height. PCIe x4 or larger for multi-port and multigig cards; full-height or low-profile to match the chassis.
• Rate the cable. Cat5e to 100 m for the mid-speed standard; Cat6a for 10G, with Cat6 good to about 55 m.
• Jumbo frames end to end. Camera, switch ports, NIC — otherwise plan for roughly six times the packets.
• Measure one camera first. CPU load at the target frame rate, then add the second.

For a whole cell — more cameras, PoE budgets, switch placement — the GigE camera network planning guide extends this arithmetic, and the systems topic page collects the rest of the integration guides. To size cameras and ports together, start from the GigE area scan cameras in the camera finder, match the frame grabbers to your slots under the accessories finder, or lay out the whole chain in the system configurator. Send the camera pair and host details through the quote request for a sized recommendation.