GigE camera interrupt moderation: balance latency and CPU load

A GigE camera can deliver complete images while still consuming too much host CPU or arriving too late for inspection. Interrupt moderation is one adapter setting that changes that balance, but disabling it is not automatically the best answer. Receive-side scaling addresses a different part of the receive path and needs its own test.

This guide helps you compare Windows and Linux adapter settings without changing camera timing, packet size, and buffering simultaneously. The goal is a repeatable choice based on complete images, delivery-time variation, and CPU headroom under your actual acquisition workload.

Choose the lowest CPU load that meets your timing requirement

Start with the adapter's current configuration as your baseline. Compare moderation disabled, a low-delay setting, and the current or adaptive setting where those choices exist. Keep receive-side scaling unchanged during this first comparison.

Choose the setting that meets your image-completeness and timing requirements with the greatest useful CPU headroom. The setting with the lowest average latency may have worse occasional delays when other processing runs.

Use three acceptance criteria:

• Image completeness: no unexplained missing or incomplete images during the qualification run.
• Delivery timing: a defined percentile and observed maximum below your application's limits.
• Processing headroom: enough capacity for acquisition, inspection, logging, and expected background activity.

If images already disappear at the baseline, first separate transport problems from interrupt-handling behavior. The GigE Vision stream-timeout diagnostic explains that broader investigation. A moderation comparison is useful only when the acquisition conditions remain controlled.

Understand moderation and receive-side scaling separately

An Ethernet adapter normally notifies the host when receive work needs attention. Interrupt moderation groups notifications rather than requesting immediate service for every arrival. Depending on the adapter, grouping may use a timer, a packet threshold, an adaptive algorithm, or several mechanisms together.

Grouping reduces interrupt-related overhead. It can also delay when received data becomes available to software. However, total image-delivery delay includes driver processing, operating-system scheduling, image assembly, and application scheduling.

A simplified relationship illustrates the overhead tradeoff:

For example, 48,000 received packets per second divided into batches averaging 12 packets would imply approximately 4,000 notifications per second. This is a teaching estimate, not a prediction of hardware interrupt counts. Polling, offloads, and driver behavior can change the relationship substantially.

Receive-side scaling, or RSS, distributes eligible receive flows across queues and processors. It does not simply divide every image across all available CPU cores. A single camera stream commonly remains associated with one receive queue because flow ordering must be preserved.

On Linux, receive processing may continue through polling after an interrupt. Consequently, a lower interrupt count alone does not demonstrate better efficiency. Measure CPU consumption and completed-image delivery together.

Define a controlled load and an honest timing measurement

Write down the camera count, image dimensions, pixel format, frame rate, exposure, trigger mode, and inspection workload. Also record the adapter, driver version, queue configuration, moderation setting, and whether a specialized acquisition driver is active.

For an unpacked monochrome image with one byte per pixel, estimate the payload rate as follows:

An illustrative workload of 1920 × 1200 pixels at 30 frames per second produces:

That is approximately 69.1 MB/s or 553 Mb/s of image payload. Protocol overhead and other traffic are additional. Packed formats, padding, and chunk data require their actual payload sizes instead.

Keep packet size fixed throughout the moderation experiment. If it needs separate investigation, use the packet-size configuration guide. Likewise, treat Linux socket-buffer tuning as a separate controlled change.

For timing, distinguish these measurements:

• Callback interval: time between completed-image callbacks; useful for delivery jitter, not absolute capture latency.
• Host trigger-request to callback: a same-clock measurement that includes trigger handling, exposure, readout, transport, and software delivery.
• Camera timestamp to host callback: valid as an absolute interval only when the clock relationship is established.

Use a monotonic host clock for intervals. Do not subtract an unsynchronized camera timestamp from a host timestamp. The frame-arrival jitter guide explains how to separate acquisition timing from host delivery.

Compare Windows settings without changing several variables

Use the network adapter's advanced properties to identify its supported moderation controls. Property names and available values differ between drivers. Some expose a simple enabled/disabled switch; others provide a rate, delay, or adaptive profile.

1. Save the current adapter configuration and identify the interface carrying camera traffic.
2. Stop acquisition before changing adapter properties. Some changes restart the interface and interrupt connectivity.
3. Leave RSS, receive buffers, packet size, and power-management settings unchanged for the first comparison.
4. Select one moderation candidate, restart acquisition, and confirm the intended setting remains applied.
5. Run the same warm-up and measurement periods for every candidate.
6. Record complete images, missing or incomplete images, timing percentiles, observed maximum delay, and CPU utilization.

Read the driver's description before interpreting a numeric setting. A larger delay value generally means more waiting, while a larger interrupt-rate value can mean more frequent service. A label such as “low” may describe either latency or interrupt frequency. Do not infer behavior from the name alone.

Use per-processor monitoring as well as overall CPU utilization. Windows performance monitoring can expose interrupt time and deferred procedure-call activity, helping identify receive-processing pressure.

If the acquisition software uses a specialized receive driver, ordinary operating-system networking settings may not control its entire path. Follow that driver's documented controls and verify the effect experimentally.

Compare Linux coalescing and queue settings carefully

On Linux, receive coalescing is commonly inspected with ethtool. Support depends on the adapter and driver; unsupported fields or rejected changes are not evidence that the camera is faulty.

For an example interface named enp2s0, these read-only commands inspect coalescing, channel configuration, and receive-flow distribution:

ethtool --show-coalesce enp2s0
ethtool --show-channels enp2s0
ethtool --show-rxfh enp2s0

Substitute your actual camera-facing interface. The displayed fields and command support vary by driver and utility version.

Record whether adaptive receive coalescing is active and which delay or frame-threshold fields are reported. Do not assume that changing one timer defeats every other grouping mechanism. Use the adapter's documented procedure for changes, then read the configuration back.

Run the same acquisition workload while observing per-CPU utilization, interrupt distribution, and receive-processing activity. /proc/interrupts can help identify which processors service adapter interrupts, although queue names and presentation vary.

Separate hardware interrupt counts from software receive-processing load. Linux can spend substantial time processing receive work without producing a corresponding rise in hardware interrupt counts.

Preserve the current interrupt-affinity policy during the initial moderation test. An active affinity-management service may move interrupt work between processors, so record its state. Test queue count or affinity separately after choosing a moderation candidate.

Avoid combining this experiment with real-time scheduling changes or broad network-security changes. Those alter different mechanisms and make the comparison difficult to interpret.

Use a worked comparison, not an isolated CPU screenshot

The following results are hypothetical. They illustrate a decision process, not measurements of any catalog product or operating system.

Assume the workload generates 30 frames per second for 30 minutes:

For this example, acceptance requires no missing or incomplete images, a 99th-percentile trigger-request-to-callback interval below 5 ms, and an observed maximum below 12 ms. Those limits belong to this imaginary application, not to GigE Vision generally.

Count missing and incomplete images without counting the same failed image twice. Establish expected image count from documented trigger or acquisition counters where available, rather than assuming every missing callback represents a network failure.

Both disabled moderation and the low-delay candidate pass the example requirements. The low-delay candidate leaves more CPU capacity and has a lower observed maximum in this sample. The higher-batching candidate fails despite its attractive average CPU figure.

Repeat each candidate at least three times, alternating test order where practical. A single run can favor one setting because of background activity or changing thermal conditions.

A 30-minute run with no failures does not prove indefinite reliability. At 30 frames per second, one hour contains 108,000 images. Rare faults may need longer qualification and representative production conditions to appear.

Test RSS against the actual camera topology

After choosing a moderation candidate, hold it constant and compare supported RSS configurations. Start with the existing queue arrangement rather than automatically selecting the maximum queue count.

For one camera, extra queues may provide little benefit if its stream hashes to one queue. For several cameras, RSS can distribute separate flows, but collisions can still place multiple streams on the same queue.

Check these conditions during the RSS experiment:

• Is one logical processor close to saturation while overall CPU looks comfortable?
• Do multiple camera streams reach different queues or processors?
• Does image processing compete with receive handling on the same processor?
• Does the expected peak load produce receive drops, incomplete images, or growing delivery delay?

Change queue count and processor placement separately. Restricting receive work too tightly can remove useful scheduling flexibility, while spreading work indiscriminately can increase coordination overhead.

Also inspect application behavior. A busy-waiting acquisition loop can consume CPU regardless of adapter tuning; the guide to replacing acquisition busy waiting addresses that separate cause. If callbacks hold image buffers while running inspection, investigate multi-camera callbacks and buffer queues before blaming RSS.

Check compatibility before choosing camera hardware

Interrupt tuning cannot compensate for an unsuitable interface, insufficient host capacity, or a camera timing requirement that the hardware cannot meet. Use the area scan cameras category and camera finder to narrow interface, shutter, resolution, and mounting requirements independently.

The LS-CMR-0053 is a GigE camera with a rolling shutter. Check whether that shutter behavior suits the motion in your inspection.

The MV-CU020-90GC provides a GigE interface and global shutter. Treat shutter choice as an imaging decision, not as evidence of lower host interrupt overhead.

Neither listing establishes which moderation modes, RSS queues, or receive-driver features your host adapter supports. Confirm those details separately before ordering.

Bring these requirements to the selection process:

• Required image payload and frame rate, including simultaneous cameras.
• Motion and shutter requirements.
• Available host interface and documented adapter-driver compatibility.
• Trigger-to-result deadline, not merely the desired display refresh rate.
• Acquisition software support for the selected camera and operating system.

Know when the usual answer is wrong, then qualify it

Disabling moderation is a useful diagnostic candidate when notification delay appears significant. It is not a universal production recommendation. Under heavy processing load, extra interrupt activity can consume capacity needed for image assembly and inspection.

Conversely, strong batching may suit throughput-oriented recording but be unsuitable for a tightly timed reject decision. Adaptive moderation can work well under sustained traffic yet behave differently when cameras produce intermittent bursts.

If exposure, readout, or an application queue dominates the measured delay, moderation changes may barely affect the outcome. If incomplete images occur with low CPU utilization, investigate transport errors and receiver behavior rather than assuming the processor needs more interrupts.

Before accepting the final configuration:

• Save the original settings and a documented rollback procedure.
• Verify moderation and RSS settings after reboot and interface restart.
• Repeat the test with every camera active and normal inspection enabled.
• Exercise expected logging, display, and background activity.
• Check per-processor load, image counters, timing tails, and application queue growth.
• Record the driver version and retain the measurement logs with the machine configuration.

A Windows profile and a Linux profile need not have matching labels or numeric values. Compare whether each satisfies the same acquisition requirements, not whether its settings look identical.

Use the camera configurator to define the imaging hardware, or send your payload calculation, timing limits, and comparison logs through application support. Those details make the next recommendation more useful than a request for a universal adapter setting.