GigE Vision packet size exceeds MTU: cap auto-negotiation

A GigE Vision stream that crawls with no error anywhere is often not the camera, the cable or the code: the negotiated packet size is larger than the network path can carry without IP fragmentation. On the switched, router-free links that machine cells use, packet-size auto-negotiation can climb well past the interface MTU - reported runs on 9000-byte links have settled above 12 KB - and the host quietly reassembles every oversized packet while throughput drops several-fold. This page is for integrators commissioning GigE cameras on a host PC. You will compute the safe packet size for your link, verify the path end to end, confirm fragmentation from the host's own IP counters, and lock the value so nothing negotiates it back.

Why does a packet size above the MTU slow a GigE Vision stream?

Any stream packet larger than the smallest MTU on its path - 1500 bytes by default, 9000 with jumbo frames - is split into IP fragments, and each fragment adds reassembly work and doubles the loss a single packet can suffer; fragmented streams measured 3-7x slower in field reports than the same link capped below the MTU.

The maximum transmission unit (MTU) is the largest payload one Ethernet frame carries, and a GigE Vision stream is a run of UDP packets whose size the GevSCPSPacketSize register controls. Above the path MTU, every stream packet becomes two or more IP fragments that the receiving stack must buffer and reassemble before the capture library sees a packet. Loss sensitivity doubles with it: losing either fragment loses the whole packet, and GigE Vision resends complete packets, so the same cable-quality loss rate produces roughly twice the resends plus the reassembly CPU on top. When the damage reaches the image as visibly broken frames, work through the GigE Vision stream packet loss diagnosis alongside this page.

How does auto-negotiation settle above the MTU at all?

The negotiation sends test packets of growing size until one comes back; on a camera-switch-host link there is no router to reject an oversized packet, so the host IP stack silently reassembles the fragments, the test reads success, and the search ends near the operating system's reassembly limit rather than at your MTU.

Most libraries implement the negotiation as a climb: set GevSCPSDoNotFragment, send a test packet, increase the size, repeat until the test fails. The DF bit only obliges a router that would fragment to answer with an ICMP "fragmentation needed" message. A camera to switch to host path has no router, so nobody answers; the IP stack reassembles the test packet, it arrives complete, and the search keeps climbing until reassembly itself fails within the test timeout. That ceiling is a property of the host OS, not of your network, which is why cameras from different makers can report the same meaningless value. The opposite failure, where the test packet never arrives and negotiation aborts, is a different problem with its own fix: GigE Vision test packet not received.

What packet size should you set?

Set GevSCPSPacketSize to the smaller of the camera's maximum and the host NIC MTU minus 28 bytes of IP and UDP header: 1472 on a standard 1500-byte link, 8972 on a 9000-byte jumbo link, minus 4 more per VLAN tag in the path.

The 28 bytes are the IP header (20) and the UDP header (8) that ride under the register value; a VLAN tag adds 4 bytes to every frame on the wire, hence 1468 and 8968. Read the camera-side maximum from the packet-size feature's range in the camera's GenICam map and never exceed it. Write the register before acquisition starts, never after the stream exists - the ordering and the feature calls are in set the GigE camera packet size before starting acquisition.

How do you check the MTU on the host and along the path?

On Linux, ip link show prints the interface MTU on its own line, code can read the same value with the netdevice ioctl SIOCGIFMTU, and ping -M do -s 8972 192.168.1.10 proves a 9000-byte path exists end to end (192.168.1.10 here is an illustrative camera address).

The runtime change is ip link set dev eth0 mtu 9000; make it persistent in whatever manages the interface, because a reboot reverts it. On Windows the equivalent lives in the network adapter's advanced properties as the jumbo packet size; pick the 9 KB value the driver offers. Every switch port between camera and host needs a matching maximum frame size - managed switches expose it per port. To test the path before touching the camera, ping a device behind the last switch with -M do, which sets the DF bit: a reply certifies the whole chain carries 9000 bytes, and a camera that answers ping confirms the final hop too.

The capture host needs a NIC whose driver accepts 9 KB frames, so when you specify the machine for the cell, pick an industrial mini PC with its network interface in mind rather than as an afterthought. Rule out the dumber twin of this problem once, too: a marginal cable can negotiate the link down to 100 Mb/s, a bottleneck no packet size repairs - the GigE camera packet size error on a below-gigabit link lists that symptom. A dedicated camera data cable with proper strain relief removes the failure mode; the 3 m high-flex GigE cable below is the standard cell choice.

Why doesn't the do-not-fragment flag stop this?

The GevSCPSDoNotFragment flag is honoured only by a router that would otherwise fragment; a Layer 2 switch forwards frames without reading IP headers, so on the router-free links typical of machine cells the flag has no enforcer and the host reassembles quietly.

DF is a request, not enforcement: it tells a router "do not split me - reject me instead", which only helps where a router exists to answer. An Ethernet switch works at Layer 2, forwarding by MAC address, and never parses the IP header, so it cannot see the flag. The receiving host, which must implement reassembly as part of the IP service, completes the packet anyway. The register can therefore be set on the wire and fragmentation still happens - the flag's state tells you nothing about the path. That is precisely why the cap has to come from your own numbers: the MTU you configured, minus 28.

When is a larger packet size worth it?

Headers cost 46 bytes per packet on the wire - about 3.1% of a 1472-byte packet but 0.5% at 8972 - so jumbo frames pay once a stream's payload passes roughly 900 Mb/s of a 1 GbE link, or when packet-rate CPU on the host becomes the limit.

Worked example: a 12 MP camera at 9 fps

A 12 MP mono camera at 8 bits produces 12,000,000 bytes per frame, about 12 MB. At 9 fps the payload alone is 12,000,000 x 9 = 108,000,000 B/s = 108 MB/s = 864 Mb/s. Count 46 bytes of transport header per packet on the wire (Ethernet 14 + FCS 4 + IP 20 + UDP 8; the GigE Vision header adds a few bytes inside the payload, which this estimate ignores).

• Packet size 1472: 12,000,000 / 1472 = 8152 packets per frame, so 73,370 packets/s at 9 fps. Wire rate = 73,370 x (1472 + 46) = 111.4 MB/s = 891 Mb/s. It fits a 1 GbE link - roughly 940-980 Mb/s is usable once preamble and inter-frame gaps are paid - with little margin left.
• Packet size 8972: 12,000,000 / 8972 = 1338 packets per frame, 12,042 packets/s. Wire rate = 12,042 x (8972 + 46) = 108.6 MB/s = 869 Mb/s, and the host services 6.1x fewer packets.

Decision: one camera at this rate runs on either setting, so jumbo is optional. Two such cameras on one NIC exceed the 1500-byte budget - enable 9000 bytes end to end and set 8972, dividing the link budget first with the multi-camera GigE bandwidth budget method. Above the MTU the same frame suffers instead: a negotiated 12,316 on a 9000-byte path is an IP packet of 12,344 bytes, split into fragments of 9000 and 3344 bytes - two chances to lose every packet, plus reassembly on top.

A 12 MP GigE camera in this class:

What symptoms and counters confirm fragmentation?

Fragmentation is the quiet failure: no error, no timeout, just a stream at a fraction of its rated frame rate; watch the host's IP fragment counters in netstat -s while streaming - if the fragment and reassembly counters climb with the stream, you have found it.

Three checks, in order:

1. Cap and re-measure. Set the size to NIC MTU - 28 and run the same capture. Recovery from a fraction of rated back to the camera's rated frame rate settles the diagnosis.
2. Watch the IP counters. Capture netstat -s output before and after a 30-second stream and compare the lines mentioning fragments and reassembly; they must not move. Climbing counters during streaming are fragmentation happening in front of you.
3. Read the negotiated value. GevSCPSPacketSize above NIC MTU - 28 on a switched link is the bug regardless of any other test - and the only test some headless builds ever run.

Any GigE area scan camera negotiates the same register; the 6 MP camera below is a typical first-build unit on exactly this kind of path.

How do you keep the size capped after commissioning?

Cap it once and assert it forever: disable the library's automatic adjustment, write GevSCPSPacketSize before acquisition starts, save it to the camera's user set, and make start-up check that the readback is at most NIC MTU - 28 before the first frame.

In practice that is five lines of build sheet and code:

1. Fix the cell's MTU policy - 1500 or 9000 - and record it; set the maximum frame size on every switch port to match.
2. Before the stream is created, disable the automatic packet-size adjustment (every library with an auto call exposes a way to refuse it), then write GevSCPSPacketSize = min(camera max, NIC MTU - 28).
3. Save the register into the camera's user set so a power cycle keeps it.
4. At every start-up, read the NIC MTU back (SIOCGIFMTU on Linux, adapter properties on Windows) and the register, and refuse to stream if the assertion fails; log both values.
5. In commissioning, run a 30-second capture and confirm the fragment counters stayed flat while the frame rate hit rated.

Packet size is one of the settings that decide how a GigE link behaves; the GigE camera network planning guide covers switch ports and bandwidth alongside it, and the GigE Vision stream timeout checklist picks up the failures beyond fragmentation. To choose the camera side of a new cell, start in the area scan cameras range, filter by interface in the camera finder, or go straight into the camera configurator. More streaming and networking pages sit on the systems topic page. If a link still underperforms after the cap, send the netstat -s output and the negotiated register value through the contact page - expert support comes with every order.