GigE camera packet size error when your link drops below gigabit

A GigE camera that appears in discovery but refuses to open or stream, reporting a packet size error or an out-of-range stream attribute, usually has a link problem rather than a software problem: something on the path negotiated 100 Mbit/s instead of 1 Gbit/s. This guide is for anyone integrating GigE Vision area scan cameras on production machines. You will read the negotiated speed at both ends of the link, compute the bandwidth the stream needs, and then either restore the gigabit path or resize packets and frame rate to fit what 100 Mbit/s carries. The arithmetic takes two minutes and points at the right fix first.

Symptom: discovery works, the stream never starts

The camera shows up in your configuration tool's device list, answers a ping, and takes control commands. The failure arrives when you open the device or start acquisition: the tool rejects the packet size value, an attribute is reported out of range, or acquisition starts and the driver delivers zero frames. Some drivers bury the same cause further down the chain as a buffer overflow, because the stream data rate exceeds what the negotiated link can carry; that symptom has its own GigE camera buffer overflow walkthrough.

The strongest clue is one you may already hold: the same camera opens fine on another computer running the same software. The camera is not the problem and neither is the driver; the path between them is. Discovery frames are small and fit any link speed, so a camera connected at 100 Mbit/s looks perfectly healthy until the stream starts.

Likely causes, in order of probability

Work down this list; the first three cause most 100 Mbit/s fallbacks.

1. A cable with a damaged pair. 1000BASE-T needs all four pairs; a cable that keeps two good pairs still links, at 100 Mbit/s. Most common after drag-chain wear or a crushed run. Test: one known-good short patch cable in place of the machine cable.
2. A forced speed or duplex setting. A switch port or NIC configured to 100 Mbit/s or half duplex instead of auto-negotiation. Test: read the port configuration at both ends.
3. A path device without gigabit. An old switch or media converter between camera and NIC that tops out at 100 Mbit/s. Test: camera straight into the NIC.
4. An MTU cap that appears at 100 Mbit/s. Some NIC drivers cap the path MTU at 1500 bytes when the link falls back; a camera set to 9000-byte packets then loses everything or is refused at open. Test: set the packet size to 1500 bytes and watch the dropped-frame counter.
5. Driver-side attribute validation. Some drivers check stream attributes against the negotiated link and reject values out of range for it; jumbo packet sizes on a 100 Mbit link are refused before acquisition starts. Test: read the negotiated speed, then retry at 1500 bytes.

Test first: read the negotiated speed at both ends

The whole walk takes ten minutes with a spare patch cable and separates every cause above without reinstalling anything.

1. Open the network adapter's status page on the host PC and read the link speed and duplex.
2. Read the link LEDs on the NIC and camera; most NICs use one colour for 100 Mbit/s and another for 1 Gbit/s, and the card manual says which.
3. If a switch sits in the path, read the camera port and the host port on the switch itself, not just the uplink.
4. Bypass everything: connect the camera straight to the NIC with one short, known-good Cat5e or better patch cable. A link that now reads 1 Gbit/s puts the fault in the removed cable or device.
5. Swap the machine's own cable back in. If the link falls to 100 Mbit/s and returns with the patch cable, replace the cable; the diagnosis is done.
6. Re-add the switch. If the link falls only with the switch in the path, open that port's settings: auto-negotiation on, speed and duplex not forced.

Both ends must read 1 Gbit/s, full duplex, before you trust any packet setting.

What the standard says: 1500 bytes and jumbo frames

IEEE 802.3 sets the standard Ethernet payload at 1500 bytes; frames with a larger payload are jumbo frames, and the jumbo frames reference page shows the framing behind that limit. A GigE Vision camera streams over UDP, and the packet size in your camera tool is the payload per packet, set in bytes, commonly 1500 to 9000. Two constraints follow. Every device on the path must carry that payload without fragmenting or dropping it. And the negotiated link speed alone sets the bandwidth ceiling, whatever the packet size is.

One correction to a theory you will meet often: Ethernet negotiates each port independently, so a 100 Mbit/s device on a neighbouring port of the same switch cannot slow your camera's port. If disconnecting other devices appeared to fix a link, what actually changed was a reseated cable or a renegotiated port; the slow neighbour was never the cause.

Worked example: the bandwidth a 100 Mbit link takes away

Take a 1600 × 1200 mono camera with 8-bit output and a 30 fps target. One frame carries 1600 × 1200 = 1,920,000 pixels, one byte each: 1.92 MB. At 30 fps the stream needs 1.92 × 30 = 57.6 MB/s, or 57.6 × 8 = 460.8 Mbit/s of payload. Allow about 10% for UDP, IP and GigE Vision headers and inter-frame gaps — smaller packets sit nearer that figure — and the demand is roughly 510 Mbit/s.

On a healthy gigabit link, raw ceiling 1000 ÷ 8 = 125 MB/s, that is under half the pipe: it fits with room to spare. On a 100 Mbit/s link the raw ceiling is 100 ÷ 8 = 12.5 MB/s, about 11 MB/s usable after overhead, so the same stream tops out at 11 ÷ 1.92 ≈ 5.7 fps against a 30 fps target. That is the whole failure in one line.

Two things follow from the table. First, jumbo packets are mainly a CPU-load optimisation: at gigabit they cut the packet rate from about 75,000 to about 12,400 per second, which lightens interrupt load on the host. Second, packet size never changes the bandwidth ceiling; only the link speed does.

Fix A: restore the gigabit link

Fixing the link recovers both MTU headroom and roughly ten times the usable bandwidth, so it is always the first choice. Replace the suspect cable, unforce the port settings, and move the camera onto network hardware you control. In a drag chain or on a moving axis, use cable rated for continuous flexing:

For a fixed 15 m run through a cabinet, a cable with locking RJ45 studs keeps the connectors seated:

If the NIC itself is the weak point — an office adapter sharing a busy host — give the camera a dedicated machine-vision interface:

The dual-port card gives one camera per port with power over the same cable; the 4-port card covers a multi-camera cell from one PCIe slot. With the link back at 1 Gbit/s, set the packet size as on any commissioning: the largest value every hop accepts, set before acquisition starts. The packet size commissioning guide covers that setting and why it belongs before stream start.

Fix B: when the 100 Mbit link must stay

Sometimes the path cannot change today: the switch is validated for the line, the cabinet is sealed, the cable sits in a channel you cannot open this shift. Then make the stream fit. Set the camera's packet size to 1500 bytes, the one payload size every standard-compliant hop carries. Budget the frame rate with the formula above: usable rate ÷ frame size. For the 1600 × 1200, 8-bit example that is 11 ÷ 1.92 ≈ 5.7 fps, so accept the lower rate, narrow the region of interest to the inspection window, or drop the bit depth. The same sensor at 12-bit packed output carries 1.5 bytes per pixel, a 2.88 MB frame, and the ceiling falls to 11 ÷ 2.88 ≈ 3.8 fps.

After the change, watch the driver's dropped-frame counter for a minute: some drivers drop oversized packets silently rather than erroring, and the counter is the only place the loss appears. The blank-frame packet loss diagnosis covers that failure shape. At 100 Mbit/s the host sees only about 7,300 packets per second even at 1500 bytes, so a standard driver copes; the high-performance NIC driver comparison pays off at gigabit rates, not here. If 1500 bytes still fails to open, the packet size was never the whole problem: re-read the negotiated speed and the exact error text.

Prevention: make link speed a commissioning check

Add one line to the commissioning sheet: negotiated speed and duplex at the NIC and the camera port, recorded at handover and re-checked after any rewiring or cable swap. Keep camera streams on their own NIC or on switch ports you administer, and budget total bandwidth when several cameras share one switch; the GigE network planning guide works the switch-side numbers, and multi-camera frame drop troubleshooting picks up the case where the budget is missed. Inspect drag-chain cables on a schedule: a cable linking at 100 Mbit/s today is a line stop next month.

The silent-fallback pattern is not exclusive to Ethernet. A USB3 camera behind a hub or a worn cable can negotiate down to 480 Mbit/s and show the same shape — less bandwidth, no error at the plug. The USB3 fallback diagnosis is the same test in a different socket. More checks of this kind live on the machine vision systems topic page.

The decision

Run the speed test before anything else; the negotiated link decides which fix applies. Both ends at 1 Gbit/s with frames still missing: keep jumbo packets, then chase MTU caps on intermediate hops and watch the dropped-frame counter. Link at 100 Mbit/s: repair the path — cable first, port settings second — which restores about 112 MB/s of usable stream and your full frame rate. Link stuck at 100 Mbit/s for now: packet size 1500 bytes, and cap the frame rate at usable rate ÷ frame size, about 5.7 fps for a 1.92 MB frame and 11 ÷ 6.29 ≈ 1.7 fps for a 6 MP one. Never tune packet size blind; read the speed first.

If you are rebuilding the path, the GigE camera cables and frame grabbers pages carry the parts above with their full specifications, the camera finder filters GigE models by resolution and interface, and the system configurator specs camera, interface and cable as one set. For a stubborn link, the contact page reaches the applications team.