GigE incomplete frames from bandwidth: fix packets and throughput

A camera that flags frames as incomplete is not handing you a bad image out of spite: image packets went missing between the camera and your buffer, and the software did the right thing by refusing the result. This article is for engineers running GigE Vision cameras — a triggered camera on a busy network, or several cameras sharing switches and NICs — who can wait a few hundred milliseconds for clean frames but keep seeing gaps. You will size the link budget, confirm packet loss from the stream statistics, and apply the three fixes that make frames complete: packet size, throughput caps and trigger staggering.

What does an incomplete frame tell you?

An incomplete frame is the camera's way of telling you that image packets arrived with gaps in them, and the fix starts with packet loss, not with your image-processing code.

The camera splits every frame into UDP packets — about 4,100 of them for a 6 MB frame at the default 1500-byte packet size. The receiving driver reassembles them in order, and a packet that never arrives leaves a hole. Your SDK reports the buffer as incomplete and your handler skips the queue. GigE Vision normally hides single losses: the receiver asks the camera to resend missing packets, and most resends succeed quietly. Incomplete frames are what remains when resends fail too, which happens when the link is congested at that exact moment — the resend itself adds traffic to the same congestion.

Discarding the buffer and grabbing a fresh one is correct handling, and Incomplete frames stay incomplete: discard, requeue, grab a new one covers the code side. It never fixes the cause, though. The cause is on the wire.

How much image data fits through one GigE link?

One 1 Gb/s link moves 125 MB/s of gross data, and after Ethernet, IP, UDP and GVSP overhead plus control and resend traffic you should plan on roughly 100-110 MB/s of image data, not the full 125.

The 125 comes from arithmetic: 1000 Mb/s ÷ 8. The usable figure assumes 1500-byte packets, whose headers cost about 4% of the link (1454 of 1520 wire bytes are payload), capping image data near 120 MB/s; reserving 10-20 MB/s for control traffic and resends gives the planning number.

For a worked example, take a 6 MP mono, C-mount GigE camera with a 1/1.8" sensor:

A full frame is about 6 MB (6,000,000 px × 1 B, 8-bit mono). At 15 fps that is 90 MB/s of payload, or 720 Mb/s; with roughly 4% overhead the wire carries about 753 Mb/s. One such camera fits a dedicated 1 Gb/s link with about a quarter of the link free. Two do not: 1,506 Mb/s of demand lands on 1,000 Mb/s of wire, which is exactly the failure the trigger section below fixes.

How do you confirm packets are being lost?

Open the stream statistics before changing any setting: a resend counter that climbs while frames come back incomplete is the confirmation that bandwidth, not trigger timing or code, is dropping your packets.

Every GigE Vision SDK and viewer exposes per-stream counters: packets received, resend requests, incomplete or dropped frames. The test takes two minutes — run 100 triggered grabs on the failing camera and read the counters before and after. Resends above zero during the failures put the cause in the network budget. Resends at zero with incompletes still present send you to the later sections instead. Read the negotiated speed on the switch port and NIC too: a link that has fallen back to 100 Mb/s misses the budget by a factor of ten, the case in GigE camera packet size error when your link drops below gigabit. In live view the same loss shows as horizontal black bands (GigE Vision packet loss horizontal lines in live images), and a resend ratio that never quite reaches zero turns into buffer timeouts (GigE stream packet resend ratio: fix buffer timeouts).

Do jumbo frames fix incomplete frames?

Raising the packet size from 1500 to 9000 bytes cuts the packet count for a 6 MB frame from about 4,127 to about 671, which is why jumbo frames fix most single-camera incomplete-frame cases.

The arithmetic rests on one assumption: a packet of configured size S carries about S − 46 bytes of image payload (20 bytes IP, 8 UDP, about 18 of GVSP header). At 1500 that is 1454 bytes, so 6,000,000 ÷ 1454 ≈ 4,127 packets per frame; at 9000 the payload is 8954 bytes and 6,000,000 ÷ 8954 ≈ 671. Each packet also spends about 66 bytes of preamble, framing and gap on the wire, so overhead falls from about 4% of the link to under 1%. Jumbo frames — Ethernet frames carrying more than the standard 1500-byte payload, 9000 bytes the usual maximum (jumbo frame, Wikipedia) — also cut per-packet driver and interrupt work sixfold, often the real fix on hosts that lose packets only while busy (bad frames under heavy multi-camera use: plan host bandwidth).

When the camera takes 9000 but the host never sees large frames, the driver or adapter settings are capping it — MTU stuck at 1500 for camera streaming: get jumbo frames working walks through that case.

Why do incomplete frames cluster when cameras trigger together?

Two cameras that each need about 750 Mb/s of wire time cannot share one 1 Gb/s link when they trigger at the same instant: 1,506 Mb/s of demand meets 1,000 Mb/s of link, the switch buffer overflows, and both frames come back incomplete.

A switch buffer rides out a few hundred microseconds of overflow, not the 50 ms a 6 MB frame spends on the wire (4,127 packets × 1520 bytes ≈ 6.27 MB; 6.27 MB ÷ 125 MB/s ≈ 50 ms). Two simultaneous streams overlap almost entirely, the combined burst exceeds the link for tens of milliseconds, and packets fall out of the switch. Three fixes, in the order to try them:

1. Give each camera its own physical link:

The dual-port NIC carries two cameras on two independent links; the four-port frame grabber does the same for four.

2. Stagger the triggers. One frame finishes in 50 ms, so a 100-200 ms offset between cameras separates bursts completely, at the cost of the offset itself in latency.
3. Cap transmission per camera. DeviceLinkThroughputLimit, a standard GenICam feature, paces each camera so the sum of the caps stays under about 110 MB/s; cameras transmit steadily instead of bursting.

The budget side has its own walkthrough in Multi-camera GigE bandwidth budget: divide the link first, and the trigger-alignment failure specifically in Multiple GigE cameras, same trigger: why frames arrive incomplete.

How do you grab one clean frame while another camera streams?

A single triggered 6 MB frame needs the link for only about 50 ms, so it will always get through once you cap the streaming camera's appetite instead of hoping for a quiet moment.

Two standard ways to do it:

Cap throughput. Set the streaming camera's DeviceLinkThroughputLimit to 20 MB/s. Capacity left: 125 − 20 = 105 MB/s. The burst needs about 94 MB/s of wire (90 MB/s payload ÷ 0.957) for its 50 ms, so it fits with roughly 11 MB/s of margin. The streaming camera slows to what the cap allows: 20 MB/s ÷ 6 MB ≈ 3 full frames per second, each taking about 0.3 s to transfer.

Cut the frame rate. At 15 fps the streaming camera leaves no room. At 4 fps it produces 24 MB/s of payload, about 25 MB/s on the wire, leaving 125 − 25 = 100 MB/s against the 94 MB/s burst. Four frames per second is the cutoff for this 6 MB example, so scale it to your frame size.

When are incomplete frames not a bandwidth problem?

If the resend counter stays at zero while frames still arrive incomplete, work down this list before touching the network budget: driver and NIC MTU mismatch first, then link speed, then host buffers, then the cable.

1. Driver and NIC MTU mismatch. The NIC accepts 9000-byte frames but the adapter driver does not, so packets arrive and frames never complete. Test by dropping the packet size back to 1500; GigE incomplete frames from a driver and NIC MTU mismatch is the walkthrough.
2. Link below 1 Gb/s. A damaged cable or a negotiation fault cuts the budget by half or by a factor of ten; check the negotiated speed at both ends.
3. Host buffer exhaustion. Under CPU load the application requeues buffers too slowly, the driver discards packets that did arrive, and resends climb although the wire is healthy. GigE camera buffer was incompletely grabbed: fix lost packets covers the mechanics.
4. Cable or connector damage. Error counters climb regardless of load. Swap the cable before recabling anything else.

What settings keep GigE frames complete in production?

Keep every camera's steady-state resend counter at zero, keep peak demand under about 90% of each link, and stagger multi-camera triggers by 100 ms or more — those three habits prevent almost every incomplete frame this article has covered.

The first-hour fix order for a new or misbehaving installation:

1. Read the stream statistics on every camera and record resend counts while frames fail.
2. Confirm every link in the path negotiates 1 Gb/s.
3. Set packet size 9000 on the camera, the NIC and every switch port, then re-test and re-read the counters.
4. If resends persist, divide the budget: separate NIC ports or stagger triggers by at least 100 ms.
5. If cameras must share a link, cap each DeviceLinkThroughputLimit so the totals stay under about 110 MB/s.

When you plan ports for a new cell, the area scan cameras page and its cameras finder filter by interface and resolution, the GigE frame grabbers page and the accessories finder list the multi-port cards, and the camera configurator walks the whole chain. The systems guides collect the rest of the network-side fixes.