GVCP resend requests on your network: why frames still drop

Wireshark on every capture PC shows the same pattern: a steady run of GVCP resend requests, and frames dropping anyway. The instinct is to re-tune the image stream. The message points somewhere else. GigE Vision carries those requests on its control protocol, and each one is your host telling the camera which image packets never arrived. It is a loss report, not a fault code. This guide decodes the message, runs the bandwidth arithmetic that decides whether your camera set fits the network at all, and works through the likely causes in order, each with a test and a fix, ending with a decision for two, four and six cameras per host.

What a GVCP resend request actually proves

GigE Vision runs each of your area scan cameras on two channels. GVCP, the control protocol, listens on UDP port 3956 and carries every parameter command; the camera acknowledges each command it accepts. GVSP, the stream protocol, carries the image itself as numbered packets on a port your application opens.

A resend request is a GVCP command from host to camera. Its payload names a first and a last GVSP packet ID, each a 24-bit value that Wireshark dissects into fields such as gvcp.cmd.resend.firstpacketid and gvcp.cmd.resend.lastpacketid. Read plainly: packets A through B of the image never arrived, send them again. The 62 in a GVCP 62 Resend request line is the captured message length in bytes, not an error code.

So every resend request certifies one fact: at least one image packet was lost between camera and host. The camera is obeying the protocol, not failing. Frames drop only when loss outruns the repair. The stream-side view of the same symptom pairs with this control-path reading.

Two channels, two packet sizes

The packet-size setting on the camera or in your transport layer belongs to GVSP only. GVCP control messages keep their own envelope whatever you set there — the classic fail-safe is 576 bytes — whether your image packets are 1500 or 9000 bytes. Raising the image packet size still helps: fewer packets in flight means fewer chances to lose one, as the arithmetic below shows.

Control commands can be resent too. The host starts a timer when it sends a command, and stacks commonly default it to 500 ms. When the acknowledgment misses the timer, the host resends, and the retry count is capped — three is a common default. One held ACK therefore stalls a parameter change for close to two seconds, and repeated stalls are the signature of an adapter holding frames back.

The arithmetic that decides everything

One number decides whether your camera set fits the network: the image payload a link really carries. A 1 Gb/s link moves 125 MB/s of raw bits. Ethernet framing, IP and UDP headers and inter-frame gaps take their share, leaving about 119 MB/s of image payload at 1500-byte packets and about 124 MB/s with 9000-byte jumbo packets. Plan each link at 110 MB/s so resend retransmits have headroom.

Worked example, one 5 MP mono8 camera at 2448 × 2048 pixels:

• Frame size: 2448 × 2048 = 5,013,504 bytes ≈ 5.0 MB.
• At 25 fps: 5,013,504 × 25 = 125.3 MB/s. That is past the 119 MB/s a GigE link delivers, even with the camera alone on the wire, so this camera class does not fit 1G at 25 fps.
• At 20 fps: 5,013,504 × 20 = 100.3 MB/s, 84% of the link budget. One camera fits. Two demand 100.3 + 100.3 = 200.6 MB/s and never do.
• Packets at a 1500-byte packet size: 1500 − 36 = 1464 image bytes per packet, so 5,013,504 ÷ 1464 = 3,425 packets per frame, and 3,425 × 25 = 85,625 packets/s.
• At 9000-byte packets: 8964 image bytes per packet, 5,013,504 ÷ 8964 = 560 packets per frame, 14,000 packets/s — six times fewer receive interrupts.
• Loss to resends: lose one packet in 100,000 at 85,625 packets/s and the stream loses 0.86 packets per second, one resend request every 1.2 s. The 40 ms frame period at 25 fps absorbs that repair. Bursts do not.

Six such cameras on one host at 1500-byte packets push 6 × 85,625 = 513,750 packets/s through the stack, about half a million receive interrupts per second — the load at which desktop-grade adapters start discarding. The port and bandwidth budget for several cameras on one host works the same math per NIC.

The likely causes in order, each with a test and a fix

Capture on a switch mirror port, not on the camera host itself: a NIC that already drops packets will also drop frames out of your capture and exaggerate the loss. Filter on the resend command and sort by packet ID. IDs bunched at the end of each frame mean the host drains its buffers too slowly; IDs spread evenly through the frame mean wire loss.

1. Host NIC receive loss — the usual culprit. Test: resend IDs clustered at frame ends, worse on the busiest camera. Fix: set the NIC's receive descriptors to maximum in the adapter's advanced settings, raise the transport layer's buffer count and size, and on Linux raise the socket buffers as the embedded Linux buffer tuning guide shows. Follow the NIC tuning order so causes get fixed before symptoms, and the blank-frame diagnostic tells you what loss looks like in the image itself.

2. An oversubscribed link. Test: run the arithmetic above for every port. Two 5 MP mono8 cameras at 20 fps demand 200.6 MB/s from a port that carries 119 MB/s, and no setting rescues that. Fix: one camera per port, or consolidation onto 10GigE.

3. A jumbo-packet mismatch. Test: ping -f -l 8972 <camera-ip> on Windows or ping -M do -s 8972 <camera-ip> on Linux — 8972 plus 28 bytes of IP and ICMP headers is exactly one 9000-byte packet, and any fragmentation-free failure names the hop with the small MTU. Fix: packet size 9000 on the camera, MTU 9000 on the camera NIC (9004 with a VLAN tag in use), and 9000 or more on every switch port in the path. Start a new camera at the 1500 fail-safe, then step up. The auto-negotiation cap and the MTU stuck at 1500 guide cover the two ways this goes wrong.

4. A marginal NIC stalling the control path. Test: set the transport layer's read and write timeouts to about 20 ms; the common default is 500 ms. A healthy network answers every GVCP command inside a single retry, so an adapter that holds acknowledgments announces itself with a retry storm. Fix: replace it. The heartbeat timeout is the control channel's other timer and ends streams after pauses — same hardware suspects.

5. Resend repair switched off. Where the stack exposes the resend enable, keep it on: turning it off trades transparent repair for a dropped frame on the first lost packet.

When the answer is bandwidth, not settings

Six 5 MP mono8 cameras at 25 fps need 6 × 125.3 = 752 MB/s, and no number of 1G ports rescues a camera that alone outruns one link. Both answers live in the frame grabbers and network cards range.

10GigE carries about 1,190 MB/s of image payload at 1500-byte packets, ten times the 1G figure, and six cameras at 25 fps use 752 MB/s of it, about two-thirds. The fix at this rate is a four-port copper 10GbE NIC:

CoaXPress takes the stream off shared Ethernet entirely: each camera on point-to-point coax, no switch in between, nothing to oversubscribe and no receive queue to overrun. The deterministic answer is an octo-port CXP-6 frame grabber:

Prevention checklist

• One camera per GigE port, or the whole group behind one 10G link.
• Packet size 9000 bytes on every camera, MTU 9000 on the camera NIC (9004 with a VLAN tag), 9000 or more on every switch port in the path, all locked after a passing ping test.
• NIC receive descriptors and transport-layer buffers at maximum.
• Control read and write timeouts at about 20 ms.
• The resend mechanism left enabled.
• Cable rated for the run, strain-relieved, reseated after any panel work.
• Resend rate logged per camera: a sustained climb past about one request per second under steady load means something changed. Chase it before frames drop, not after.

The decision, per layout

Two cameras per PC. Put each camera on its own port of a dual-port PoE GigE NIC such as the MV-GE2002P. Lock packet size at 9000 bytes, max the receive buffers and set the control timeouts to about 20 ms. Steady state to expect: no resend requests in the capture and zero dropped frames.

Four cameras per PC. At 5 MP mono8 and 20 fps or below, four isolated ports carry the group with room to spare. The MV-GE1104 supplies four GigE ports in a single card. Push past 20 fps per camera and the group consolidates onto one 10G NIC.

Six cameras at 25 fps. Stop sharing 1G: the fleet needs 752 MB/s and a single camera alone outruns a GigE port. A four-port copper 10GbE NIC such as the MV-GT2104 carries the whole fleet; where timing must be deterministic, an octo-port CXP-6 frame grabber such as the MV-GX1008 takes the same group onto point-to-point coax.

Wire the choice together in the configurator: start at the camera step for the sensors and add the NIC or frame grabber at the extras step. The camera finder filters by interface and the accessories finder by port count. The rest of the GigE diagnostics sit on the systems topic page.