Frames arrive torn, one processor core sits pinned, and the delivered frame count lands below the camera's rating. Before you blame the camera, look at the network interface card: its stock driver is built for general-purpose traffic, and a GigE Vision stream at gigabit line rate is roughly 80,000 small UDP packets per second. Camera and vision-software vendors ship an alternative — a high-performance GigE Vision driver that takes over the receive path for camera traffic. This explainer covers what that driver changes inside the NIC stack, the packet-rate arithmetic that predicts the gain, and the decision for one camera, a multi-camera host and a 10GigE link. You leave with one number to compute and a rule for when the stock driver is good enough.
What the high-performance driver changes on the NIC
A stock driver receives camera packets through a path built for file transfers and web traffic: the card raises an interrupt, the kernel network stack processes each frame, the host firewall inspects it, and the payload is copied — often twice — before it lands in your image buffer. None of that is broken; it is simply not built for a sustained stream of same-size UDP packets.
A high-performance GigE Vision driver replaces that path for camera traffic. It pre-allocates receive buffers sized for whole frames, batches packet interrupts the way camera streams want them, copies data as little as the chipset allows, and speaks the GigE Vision protocol's own language — packet resend handling included. It works regardless of the host firewall configuration, because camera traffic never enters the general-purpose stack. And it arrives with vision-sane settings: jumbo frames on, interrupt behavior tuned, no digging through advanced tabs.
You can reach some of those knobs by hand in a stock vendor driver — jumbo packets and interrupt moderation are the two usually exposed in the adapter's advanced settings. Not every knob is exposed, though, and the default settings target average networking, not one UDP stream near line rate. Balancing interrupt moderation by hand buys part of the win, at the price of added receive latency.
The number that decides it: packets per second
The driver's gain scales with one number: packets per second, which is data rate divided by packet size. Every packet costs fixed work — an interrupt opportunity, a descriptor, a firewall check, a copy. Cut the packet count sixfold and you cut that overhead sixfold; multiply the cameras and you multiply it.
The payload ceiling of a gigabit link comes from Ethernet framing. The line carries 125 MB/s. A standard frame moves 1472 image bytes — a 1500-byte MTU minus 28 bytes of IP and UDP header — inside 1538 bytes on the wire: 8-byte preamble, 14-byte Ethernet header, 4-byte checksum, 12-byte inter-frame gap. So:
125 × 1472 ÷ 1538 ≈ 120 MB/s with standard frames.
A 9014-byte jumbo frame moves 8986 image bytes in 9052 wire bytes: 125 × 8986 ÷ 9052 ≈ 124 MB/s. Same link, six times fewer packets. At full line rate that is roughly 81,000 packets per second at 1500-byte frames against 14,000 at jumbo size. Whichever of those two numbers your system produces decides the driver question — and how much frame rate fits on the link at all is the companion question in GigE Vision for a high speed camera: how much frame rate fits?.
Set packet size before you blame the driver
Packet size is the first lever because it is free. Set the camera's packet size to the largest value the whole path supports, and do it before acquisition starts — the setting lives with the camera's acquisition controls, and mid-stream changes are not supported. The details are in Set GigE camera packet size before starting acquisition.
On the NIC side, enable jumbo frames in the adapter's advanced settings and take the maximum offered — typically 9014 bytes; some adapters expose only 4096 or around 5000. The camera's packet size must sit at or below the smallest MTU on the path. Miss that and you get blank frames and stream timeouts rather than slow performance; GigE Vision stream timeout: check packets, buffers and MTU covers the failure pattern.
Point-to-point camera data cables simplify this: with the camera wired straight to the NIC there is no switch to negotiate, so both ends are yours to set.
Worked example: one 6 MP mono camera at 20 fps on a gigabit port
The case: one mono camera, sensor 2448 × 2048, 8-bit output, a 20 fps requirement, one point-to-point gigabit port. Any current 6 MP mono GigE camera with a C-mount from the area scan cameras range fits the same arithmetic. One such camera:
- Sensor format
- 1/1.8"
- Lens mount
- C-mount
- Interface
- GigE
- Resolution
- 6-10 MP
Inputs, with sources: sensor size and bit depth from the camera's data sheet; 20 fps is the production line's requirement; 1472 and 8986 image bytes per packet from the framing math above.
Rule: data rate first, then packets per second at each packet size.
Arithmetic:
- Bytes per frame: 2448 × 2048 × 1 = 5,013,504 ≈ 5.0 MB
- Data rate: 5.0 MB × 20 fps = 100 MB/s, which is 84 percent of the 120 MB/s ceiling
- Standard frames: 100,000,000 ÷ 1472 ≈ 68,000 packets per second — one packet every 15 µs
- Jumbo frames: 100,000,000 ÷ 8986 ≈ 11,000 packets per second — one every 90 µs
Decision, with its threshold: if the path passes 9014-byte packets, set them and keep the stock driver — 11,000 packets per second is routine work for a modern stack. If a switch pins you at 1500 bytes, you are asking the host to service a packet every 15 µs while running inspection software; install the high-performance driver, or re-path the camera where jumbo frames pass.
Multi-camera hosts: where the driver earns its place
Packet rates add across cameras. Four copies of the example camera on a four-port card, each at jumbo size, deliver 4 × 11,000 = 44,000 packets per second to one host — manageable. At 1500-byte frames the same four deliver 4 × 68,000 ≈ 272,000 packets per second, and the receive path, not the link, becomes the limit. The driver's gain grows with camera count for exactly this reason.
Firewall inspection adds the same way: 44,000 UDP packets per second crossing a general-purpose stack is CPU the vision driver never spends. For the host end, start from the frame grabbers shelf: the MV-GE1104 is a 4-port GigE frame grabber, the MV-GE2002P is a dual-port PoE NIC, and the LS-FGB-0004 is a PCIe x4 4-port PoE gigabit card.
- Interface
- GigE
- Ports
- 4 ports
- Interface
- GigE
- Ports
- 2 ports
- Interface
- GigE
The port map, IP plan and aggregate bandwidth are their own task: GigE camera network planning: switch ports and bandwidth and Assign cameras to ports reliably in a multi-camera system cover both, and machine vision Ethernet bandwidth planning for cameras sizes the aggregate for larger hosts.
How to choose: the decision table
| Your set-up | Packets per second | Decision |
|---|---|---|
| One camera, 9014-byte packets | ≈ 11,000 | Stock driver; spend the effort on lighting |
| One camera, pinned at 1500-byte frames | ≈ 68,000 | Fix the path to jumbo first; if you cannot, install the vision driver |
| Two to four cameras, jumbo frames | 22,000–44,000 | Install it; the same host runs your processing |
| Two to four cameras, standard frames | 136,000–272,000 | Install it and fix packet size — both are limiting |
| One 10GigE camera near line rate | ≈ 138,000 even at jumbo | The driver is not optional; choose the card for the job |
Availability is the one constraint: these drivers are written for specific gigabit controller families, not every adapter. If your card is not on the supported list, the stock driver with jumbo frames and tuned moderation is the workable path — the table still tells you what you are asking of it. The card-side choice has its own logic; selecting hardware for GigE Vision acquisition walks it port by port.
Checks before you change anything
- Compute packets per second for every camera: data rate ÷ image bytes per packet. That number picks your row in the table.
- Confirm packet size end to end: camera set before acquisition, NIC jumbo at its maximum, every switch port in the chain passing the same frame size.
- Measure from frame timestamps — count delivered frames over a full minute against the camera's counter, never from a live view. Camera frame rate measurement from timestamped frames shows the method.
- Separate wire problems from driver problems: GigE Vision resend requests climbing means packets die before any driver sees them — cable, connector or switch port. GigE Vision stream packet loss: diagnose blank frames is the walkthrough.
- If a driver swap leaves parameters unreadable or the camera undiscovered, treat it as a driver mismatch and roll back cleanly: GigE camera failed to read parameter: fix the driver mismatch.
When the usual answer is wrong
10GigE kills the packet-size escape. A 10-gigabit link at line rate carries 1250 × 8986 ÷ 9052 ≈ 1240 MB/s, which is ≈ 138,000 packets per second even with 9014-byte packets. No tuning of a desktop NIC absorbs that; it is host-end work for a dual 10GigE frame grabber such as the MV-GT1102P. The intermediate 5GBASE-T tier carries its own bandwidth and cable limits — 5GBASE-T camera interface: bandwidth, cables and distance has the numbers.
Latency work reverses the trade. Batching interrupts cuts CPU but adds receive jitter; if you act the moment a frame lands — trigger, measurement, closed-loop control — tune moderation toward low latency and accept the CPU cost.
And when frames arrive complete, on time, with CPU to spare, the driver buys nothing. A frame rate that lags on a healthy link points at the processing side: Acquisition faster than processing: fix the frame rate gap.
A five-minute checklist
- Camera packet size set to the path maximum, before acquisition starts
- Adapter jumbo frames at the maximum offered — 9014 bytes where available
- Packets per second computed for every camera on the host
- Driver decision taken from the table, not from a hunch
- Frames counted from timestamps after every change
- Resend requests at zero before crediting any driver with the improvement
When you know your row, pick the host end in the vision accessories finder, walk the configurator from the accessories step, or ask us through the contact page.
The configurator matches a camera, lens, light, light controller and cables to each other, step by step, and lists only parts that fit what you already picked.
Questions
Does a high-performance GigE Vision driver raise the camera's frame rate?
Only when packet processing was the limit. The camera's readout and the link ceiling do not move: a gigabit port carries about 120 MB/s of image payload at standard frames and about 124 MB/s with 9014-byte packets. If the camera was frame-starved by 68,000 packets per second of receive overhead, the driver recovers those frames. If the camera cannot produce more, no driver will. Compute packets per second first.
Do I need the driver for a single camera?
Not with jumbo frames. One camera near the gigabit ceiling produces about 11,000 packets per second at 9014-byte packets — one every 90 µs, which a stock driver absorbs alongside normal processing. The same camera at 1500-byte frames produces about 68,000 per second, one every 15 µs, and there the driver earns its keep. Fix packet size first and treat the driver as the fallback.
How do I tell driver overhead from a bad cable or switch?
Watch the GigE Vision resend requests. If they climb, packets are dying on the wire before any driver sees them — suspect cable, connector or switch port. If resends sit at zero while one processor core runs hot and the frame counter lags, the receive path is the suspect, which is the case the vision driver addresses. Count frames from timestamps over a full minute rather than judging from a live view.
Will the driver help with a 10GigE camera?
Yes, and packet size alone cannot save you. Near line rate a 10-gigabit stream hands the host roughly 138,000 packets per second even at 9014-byte packets — six times fewer than standard frames is still too many for a desktop NIC. That stream needs a host card and driver pair built for sustained acquisition — a dual 10GigE frame grabber at the host end — rather than a general-purpose adapter with a tuned driver.
Is interrupt moderation a substitute for the high-performance driver?
No — it fixes one of the driver's four jobs. Moderation batches interrupts, which cuts processor load, but the packets still cross the general-purpose stack: firewall inspection, buffer churn and extra copies remain, and the batching itself adds receive latency. The vision driver addresses all four at once with camera-tuned settings. If you keep the stock driver, steering moderation toward fewer interrupts is the best single manual tweak.