GigE Vision frame arrival jitter: isolate camera and host timing

Uneven frame delivery does not necessarily mean the camera is capturing unevenly. A camera can acquire regularly while the host delivers completed images in bursts after scheduling delays, packet recovery or application processing. This distinction matters when your inspection receives every image but reports an unstable frame rate.

Start by recording camera timestamps, frame identifiers and monotonic host arrival times together. Then isolate the receive path from processing, inspect Linux scheduling and network counters, and change buffering or MTU only when the measurements support that change.

1. Measure capture timing separately from delivery timing

The first decision is whether the timing variation originates before transmission or after acquisition. A timer around an image-retrieval function cannot answer that alone: it measures when your application obtains an image.

For each successfully completed frame, log:

• Frame identifier, including its documented wrap behavior.
• Camera timestamp and its documented tick frequency.
• Monotonic host timestamp taken immediately when the completed frame becomes available.
• Frame completion status and payload size.
• Available receive-buffer count, if the acquisition software exposes it.
• Processing completion time, recorded separately from acquisition.

Check what the camera timestamp represents. Depending on the device and configuration, it may identify a trigger, exposure event or another acquisition event. Do not label it exposure start without documentation.

Use a monotonic host clock for elapsed-time measurements. A wall clock can change through synchronization or administrative adjustment. If the host clock is frequency-adjusted, account for that when analyzing longer recordings.

Avoid synchronous disk writes or terminal output for every frame. Record compact entries into a bounded logging queue, then write them outside the receive path. Otherwise, the diagnostic logger can create the problem you are measuring.

If frames stop arriving altogether, follow the separate camera acquisition stall diagnostic sequence.

2. Calculate intervals and interpret the pattern

Convert camera timestamp differences using the documented timestamp frequency. Calculate host intervals from the same consecutive completed frames.

Handle documented timestamp and identifier rollover before subtracting. A camera restart may also reset these values and must start a new measurement segment.

At an illustrative acquisition rate of 36 fps:

Suppose the camera intervals remain approximately 27.78 ms, while consecutive host intervals are 24, 32, 26 and 29 ms. Their average is:

The average rate is close to the intended rate, but delivery spacing is uneven. A delayed delivery can be followed by a short interval as queued work catches up.

Consecutive identifiers show that no identifier was skipped within the observed sequence. They do not prove that packets arrived without loss: successful retransmission can preserve complete frames while delaying delivery.

Do not subtract an unsynchronized camera timestamp directly from a host timestamp and call the result latency. Interval comparison does not require a shared time origin; absolute latency measurement requires synchronized or independently characterized clocks.

3. Remove processing from the receive path

The most useful first isolation test is acquisition without inspection, display, compression or recording. Retain only frame-status checks and lightweight timing collection.

1. Record the current camera configuration and acquisition-software settings.
2. Run acquisition into a preallocated buffer pool.
3. Timestamp completed frames immediately at the acquisition boundary.
4. Return buffers promptly according to the acquisition software's ownership rules.
5. Add processing, display and recording back separately.

If arrival variation disappears during acquisition-only operation, the original application is probably delaying image retrieval or buffer recycling. That does not establish a network fault.

Separate acquisition from downstream work with a bounded queue. Define what happens when that queue fills: stop acquisition, reject incoming work or discard older work according to the application's requirements. An unbounded queue hides overload by increasing image age.

Never return a buffer while another thread still reads its image. Either retain ownership until processing finishes or make a deliberate copy into separately owned memory. The copy has a bandwidth cost, so include it in the test.

For applications that also save images, use the recording throughput and dropped-frame checks to separate storage delays from acquisition behavior.

4. Check Linux scheduling and CPU contention

Processor clock frequency alone does not predict receive performance. Core count, memory behavior, interrupt handling, power management and competing workloads can change how quickly the acquisition thread runs.

Inspect per-thread activity rather than only overall CPU utilization. A lightly loaded system can still have one saturated core serving acquisition and network interrupts.

Use operating-system tools to observe:

• CPU usage and migrations of the receive thread.
• Run-queue pressure and scheduling delays during jitter events.
• Interrupt and software-interrupt activity on the receiving interface.
• Memory pressure, page faults and swapping.
• Concurrent display, compression, storage or background workloads.

Repeat the acquisition-only test under idle conditions and under a reproducible production-like workload. If interval spikes correlate with another task, isolate that workload before changing network settings.

CPU affinity can help diagnose migration or contention, but it is not a universal optimization. Placing the receive thread and busy network processing on the same core may make timing worse. Test a documented affinity configuration, record its effect and retain a rollback path.

Do not immediately assign unrestricted real-time priority. An incorrectly configured receive loop can starve essential system work. Prefer supported acquisition-software controls and measured scheduling changes.

If available, compare timestamping at the acquisition callback with timestamping at the application consumer. Regular callback delivery but irregular consumer delivery points to the application's queue or scheduler rather than camera capture.

5. Check network counters and the payload budget

A clean image does not prove that its transmission was trouble-free. Packet recovery can make a frame complete while extending its delivery time.

Read interface counters before and after a fixed-duration test. On Linux, ip -s link provides interface statistics. Driver-specific statistics exposed through ethtool may add receive errors, missed packets or ring-exhaustion counters. Their names and meanings depend on the driver.

Also inspect acquisition-software counters for packet resends, incomplete frames and unavailable buffers. Compare counter changes with the timestamps of delayed frames. Accumulated counters without a baseline are much less useful.

For a hypothetical uncompressed monochrome stream with one byte per pixel:

That is approximately 24.9 MB/s, or 199 Mb/s, before transport overhead. These are application-example values, not specifications for a listed camera.

A modest average rate does not rule out short bursts, shared-link contention or packet loss. Check the complete path, including switch uplinks and other traffic using the receiving interface.

If resends or interface drops rise with competing traffic, continue with the machine vision network congestion checks. Firewall changes are not a first response when complete frames already arrive reliably.

6. Distinguish receive buffering from application buffering

There are several separate queues: the network adapter receive ring, operating-system socket buffers, acquisition buffers and application work queues. Increasing one does not repair exhaustion elsewhere.

First identify which transport path the acquisition software uses. A standard socket receiver and a dedicated transport driver may expose different controls. A socket-buffer setting may have no effect on a driver-managed receive path.

For socket-based acquisition, inspect the effective receive-buffer size and relevant operating-system limits. ss -u -m can expose socket memory information where applicable, while sysctl net.core.rmem_max reports a socket receive-buffer limit. These observations are not instructions to assign an arbitrary large value.

Size acquisition buffering around measured interruptions. As an approximate planning calculation:

This example assumes eight genuinely free slots available to absorb incoming frames. Allocated buffers already held by processing are not free capacity. Transport behavior and in-flight work can reduce the practical margin.

More buffering can prevent loss during a brief pause, but it cannot make a slow consumer faster. It can also allow older images to remain queued longer. Track queue depth and image age alongside frame rate.

Change one buffer setting at a time. A successful change should reduce the identified overflow or starvation counter without introducing unacceptable latency.

7. Verify MTU end to end before enabling jumbo packets

Larger packets can reduce packet-processing overhead, but jumbo packets are not a general cure for uneven frame delivery. They help only when every relevant component supports the selected size and packet-processing cost contributes to the symptom.

Verify the camera packet size, receiving-interface MTU and every switch path between them. Include virtual interfaces or other network layers if they are present. The camera's packet-size setting and the interface MTU are related limits, not necessarily identically defined values.

Start from a documented, known-working configuration. If the acquisition software offers a manufacturer-supported packet-size test, use it to evaluate the actual stream path. Confirm stable image transfer and unchanged error counters afterward.

An IPv4 no-fragment echo test can provide supporting evidence where the camera responds. For ordinary IPv4 without options, a 1472-byte echo payload plus 28 bytes of IP and ICMP headers produces a 1500-byte IP packet. However, a successful echo test does not validate the complete camera streaming behavior, receive queues or scheduling.

For incomplete images, missing packets or stream interruptions, use the more detailed GigE Vision packet, buffer and MTU troubleshooting sequence.

8. Decide whether hardware selection is actually involved

Do not replace a camera simply because host arrival intervals vary. If camera timestamps remain regular and the receive path becomes stable after application changes, the evidence points elsewhere.

Camera selection matters when the required acquisition rate, shutter behavior, trigger timing or payload cannot meet the inspection requirement. Browse area scan cameras and use the camera finder to narrow the interface and imaging requirements separately from host troubleshooting.

The MV-CU020-90GC is a GigE camera with a global shutter. It is a selection example, not a promised remedy for delivery jitter.

The MV-CS200-10GC is a GigE camera with a rolling shutter. Its shutter type is an imaging consideration, not evidence of a host scheduling problem.

For either selection, verify the supported acquisition rate at the required image dimensions and pixel format. Also check trigger operation, timestamp semantics and compatible acquisition software. A catalog interface label alone does not establish deterministic application delivery.

9. Verify the fix under the real workload

Use a repeatable acceptance test rather than judging a short live display. For example, capture a five-minute baseline and a five-minute candidate run with the same configuration, then perform a longer production-representative test.

Report median, upper-percentile and maximum host intervals together with the observation duration. Compare camera intervals separately. A single maximum without workload context is difficult to interpret.

Before accepting the result, check:

• Camera timestamp intervals satisfy the acquisition requirement.
• Frame identifiers remain consistent, accounting for documented rollover.
• Completion-status and transport counters show no unexplained increases.
• Host interval variation meets the application's actual delivery requirement.
• Queue depth remains bounded instead of rising throughout the run.
• Display, inspection and recording remain enabled during final verification.
• Changed settings survive a normal application restart.

The usual answer is wrong when the process requires tightly timed exposure but the investigation measures only application delivery. Conversely, regular capture does not guarantee that a downstream consumer receives images before its deadline. Define those two requirements separately.

For a new installation, begin with the camera configuration step. For an existing timing problem, send configuration details, interval logs and counter changes through technical support so the next change addresses measured evidence.