GigE Vision stream timeout: check packets, buffers and MTU

A GigE Vision camera can open correctly, deliver valid images, and then stop because the host never completes the next receive buffer. That symptom does not identify the failed layer. Missing packets, receiver scheduling delays, exhausted image buffers, or an absent trigger can produce similar application errors. This troubleshooting sequence helps you separate those causes, measure the receive path, and verify a fix without treating jumbo frames or larger buffers as universal remedies.

1. Preserve the first failure before changing settings

Start with the earliest abnormal event, not the final disconnect exception. A receive timeout followed by an error stating that acquisition remains active usually describes two problems: the original acquisition failure and an unsuccessful cleanup operation.

Record the following before restarting:

• Time acquisition began and time the first failure appeared.
• Last complete frame identifier and available camera timestamps.
• Complete, incomplete, dropped, and unavailable-buffer counts.
• Packet-loss and resend counters exposed by the transport layer.
• Interface errors, dropped packets, and link-state changes.
• Requested exposure, frame rate, trigger mode, image dimensions, and pixel format.
• Software, transport-layer, and driver versions.

Counter names and meanings vary. Record their documented definitions, and compare changes over the same test interval. A cumulative count from an earlier run can otherwise look like evidence from the current failure.

Use the broader intermittent acquisition failure troubleshooting sequence if you have not yet established whether the camera, transport, or application stops first. Here, the starting condition is narrower: one camera has already delivered valid frames through an established connection.

2. Locate where progress stops

Follow the data from the camera toward the application. An image can be transmitted but remain incomplete, or arrive completely without becoming available to the caller.

A resend request is evidence of missing data at the receiver, not proof of a damaged cable. Packet loss can occur inside the host when receive queues overflow.

Conversely, clean interface counters do not prove that every transport packet reached the image assembler. Counters observe different points in the path, and some drivers expose more detail than the operating system interface statistics.

For shared-network effects, use the network congestion diagnostic guide. Keep this initial test to one camera and one receiver so unrelated traffic does not obscure the result.

3. Calculate the load before increasing buffers

Estimate image payload from the transmitted pixel format, not from the displayed image or the sensor's nominal bit depth. Packed and unpacked formats can require different numbers of bytes.

These are planning estimates. Transport headers, packet framing, metadata, resend traffic, and scheduling behavior add requirements beyond the image payload.

Consider an illustrative image measuring 1600 × 1200 pixels, transmitted with one byte per pixel at 30 frames/s:

• Image payload = 1600 × 1200 × 1 = 1,920,000 bytes.
• Payload rate = 1,920,000 × 30 = 57,600,000 bytes/s.
• Payload bit rate = 57,600,000 × 8 = 460,800,000 bit/s, or 460.8 Mb/s.

At 60 frames/s, the payload alone becomes 921.6 Mb/s. That leaves little headroom on a nominal 1 Gb/s link once overhead and recovery traffic are included. It is not a sensible starting point for fault isolation.

Reduce the frame rate substantially while leaving dimensions and pixel format unchanged. If the timeout disappears, repeat at several intermediate rates. A repeatable load threshold points toward bandwidth, packet-processing capacity, or queue exhaustion, although it does not identify which one.

Next, keep approximately the same average data rate but change the delivery pattern where supported. Camera packet pacing can reduce bursts, but it also lengthens transmission and may limit the achievable frame rate. Follow the documented timing constraints.

The high-speed recording guide explains the wider throughput budget when storage and processing are also involved. For this diagnosis, remove recording and image analysis until acquisition alone is stable.

4. Check actual receive-buffer allocation

Several different resources are often called a receive buffer:

• The network adapter's receive descriptor ring.
• An operating-system socket receive queue.
• The transport layer's packet or image assembly storage.
• Application-visible image buffers and downstream queues.

Increasing one does not automatically enlarge the others. First identify which receive mechanism the installed transport uses. A dedicated filter driver or another receive path may not depend on the ordinary UDP socket settings you intended to change.

On Linux, net.core.rmem_max limits ordinary socket receive-buffer requests, while net.core.rmem_default supplies a default where applicable. Raising a ceiling does not prove that an already-open socket requested or received a larger allocation. Depending on the transport, you may need to reopen the stream or restart the receiving process before its allocation changes.

Check three separate facts:

1. The active operating-system limit has the intended value.
2. The application or transport requests an appropriate receive-buffer size.
3. The effective allocation reported for the relevant socket matches the expected accounting convention.

Linux reports SO_RCVBUF using a doubled value for accounting overhead. Do not compare that reported number directly with a requested payload capacity without understanding the convention. An operating-system maximum is also not a measurement of queued image data.

Increasing transmit-buffer limits is not the first remedy for an image receive backlog. Change settings only when you can explain which queue they affect.

Estimate how much scheduling delay a queue can absorb

Using the earlier payload rate, a receiver pause lasting 50 ms produces approximately:

This is a gross estimate, not guaranteed usable capacity. Packet metadata, accounting overhead, existing occupancy, and burst timing reduce the practical margin.

A larger queue can absorb a brief pause. It cannot correct sustained overload. If the receiver drains data more slowly than the camera supplies it, the queue eventually fills regardless of its initial size.

5. Establish MTU compatibility before trying jumbo frames

Return to a known baseline before testing larger packets. A standard Ethernet IP MTU is commonly 1500 bytes. Configure the camera's stream packet size according to its transport documentation so the resulting packets fit the entire path.

Do not assume that a camera packet-size setting and an interface MTU express the same quantity. One may include protocol headers that the other excludes.

Check every component between camera and receiver:

• Camera stream packet-size configuration.
• Host interface MTU.
• Switch port and switch-wide frame-size limits, where applicable.
• Intermediate network interfaces or virtual interfaces.
• Transport-driver restrictions.

A host interface set to 9000 bytes does not establish that the switch or camera path supports matching traffic. A successful small ping also says little about delivery of larger stream packets.

Where available, use the transport's documented packet-size discovery test. A correctly sized, nonfragmenting network probe can provide additional evidence, but it does not replace an acquisition test with packet and frame counters.

Jumbo frames can help by reducing packet-processing frequency. At the illustrative payload rate, using 1400 image-data bytes per packet requires approximately 57,600,000 / 1400 = 41,143 packets/s. Using 8400 image-data bytes requires approximately 6,857 packets/s. These are simplified estimates that exclude protocol-specific details.

The lower packet rate may reduce host overhead. It does not repair retained image buffers, a stopped trigger source, or an incompatible network component.

6. Separate receiver behavior from application behavior

Run a minimal acquisition program using supported software. It should receive frames, record status and counters, and release each image promptly. Disable display, conversion, recording, and inspection processing during this test.

Compare the minimal receiver with the full application under identical camera settings. If only the full application fails, inspect callback duration, queue growth, buffer ownership, and operations that block the receive thread.

The image-buffer ownership guide is useful when image references remain active longer than intended. An application can exhaust reusable buffers even when network delivery is healthy.

Also check whether a timeout represents a genuine missing frame. With external triggering, the next valid image might not exist before the receive deadline. Exposure duration, trigger spacing, transmission time, and scheduling margin all affect a reasonable timeout. The hardware-triggered acquisition guide covers the acquisition sequence for that case.

Do not merely lengthen the deadline until errors disappear. A larger timeout can hide a dead stream and increase recovery latency without addressing packet loss.

Keep cleanup failures separate

After the first acquisition error, preserve its details. Then perform the documented stop, buffer-release, and close sequence for the installed acquisition library.

Do not destroy camera or stream objects while another thread may still use them. Coordinate thread termination and outstanding image ownership according to the library's rules. If cleanup also fails, record that exception separately rather than replacing the original fault report.

Recovery is a second acceptance test. A stream that runs normally but cannot stop and reopen cleanly still needs correction.

7. Check hardware compatibility before replacing parts

A direct connection can remove switch configuration and shared traffic from the experiment, where the camera's documented power and connection requirements permit it. Maintain the required power source and electrical connections throughout the test.

For cable substitution, check connector type, locking arrangement, routing, bend requirements, shielding, and any power-delivery requirements. Use the cables category and accessory finder to narrow suitable options rather than selecting by appearance alone.

LS-CBL-0199 is a GigE camera cable option. Confirm its mechanical suitability for the installation before using it in a substitution test.

A replacement camera is not the first diagnostic step when host packet drops or queue exhaustion already explain the failure. Compare area scan cameras through the camera finder only after defining the required interface, acquisition timing, sensor coverage, and shutter behavior.

LS-CMR-0053 is a GigE area scan camera option. Its suitability depends on the inspection requirements, not on an assumption that another camera will repair the host receive path.

Changing to another interface can remove Ethernet-specific constraints, but it also changes cabling, host-controller requirements, and software behavior. Treat that as a system redesign decision, not proof that the original camera was defective.

8. Verify the fix under representative conditions

Use a written test matrix rather than relying on one successful restart. Change one variable at a time, and keep acquisition duration and counter collection consistent.

A practical acceptance checklist is:

• Baseline: Run the minimal receiver at reduced load and the verified packet size.
• Target rate: Restore the required dimensions, pixel format, exposure, and frame rate.
• Host load: Repeat with normal inspection, display, and recording enabled.
• Counters: Check for newly incomplete frames, packet loss, and unavailable buffers.
• Queue behavior: Confirm that application queues do not grow continuously.
• Lifecycle: Exercise normal stop, reopen, and documented recovery behavior.
• Restart: Repeat from a fresh host and camera startup using the intended configuration.

As an initial screening exercise, test for at least 30 minutes and repeat three startup cycles. Longer observation is necessary when historical failures occur less frequently. Passing this screening does not establish a guaranteed failure rate.

Record expected versus received frame counts, elapsed time, counter deltas, and the first error from every failed run. Keep the final packet-size, buffer, and pacing settings with the commissioning record.

If packet delivery is stable but frames remain unavailable, return to buffer ownership and acquisition timing. If loss follows increased traffic, return to bandwidth, receive scheduling, and the physical path. Do not keep increasing unrelated limits.

For a new installation, start with the camera configuration step. For an unresolved receive-path failure, send the configuration, test matrix, and first-fault evidence through technical support so the next investigation starts from measurements.