GigE Vision for a high speed camera: how much frame rate fits?

A high speed camera on GigE Vision hits a wall that no driver removes: the Ethernet link itself. One gigabit moves about 100 MB/s of image payload, so whether your frame rate is reachable is a division problem — frame size times frame rate against link bandwidth — and it has an answer before any software enters the picture. This explainer gives the payload numbers for 1, 2.5, 5 and 10 GbE plus USB3 and CoaXPress, shows the packet-size effect that moves them, and commits to a transport decision for each case. Sometimes the right call is not more bandwidth at all, but a smaller region of interest or a hardware trigger.

How much image data fits on a GigE Vision link?

Plan on 100 MB/s of image payload through a 1 GbE GigE Vision link, 280 MB/s at 2.5 GbE, 560 MB/s at 5 GbE and 1,100 MB/s at 10 GbE. The raw line rates are 125, 312, 625 and 1,250 MB/s. GigE Vision streams frames as UDP packets under the GVSP protocol, so every packet carries headers, the physical layer adds a preamble and an inter-frame gap, and the host stack takes its share as well.

Multiply the line rate by about 0.8 and you have a planning number that holds on a healthy link. Treat the last 10% as burst headroom, not as capacity to book. For the same arithmetic carried through a concrete case, the walkthrough of 4K machine vision at 60 fps: bandwidth and interface limits is a good cross-check.

How do I calculate the data rate my camera will produce?

Multiply pixel count by bytes per pixel by frame rate: a 5 MP mono camera at 30 fps sends 5,000,000 × 1 × 30 = 150 MB/s and already overloads a 1 GbE link.

Mono8 and 8-bit Bayer RAW cost 1 byte per pixel, YUV422 costs 2, RGB8 costs 3, and packed 10- or 12-bit data lands between 1.25 and 2.

Here is the worked example with a 20 MP camera. The IMX183 sensor is 5472 × 3648 pixels, so one Mono8 frame is 5472 × 3648 × 1 = 19,960,000 bytes — call it 20 MB. Now divide:

• 1 GbE: 100 ÷ 20 = 5 fps ceiling
• 2.5 GbE: 280 ÷ 20 = 14 fps
• USB3, planning on 400 MB/s: 400 ÷ 20 = 20 fps
• 10 GbE: 1,100 ÷ 20 = 55 fps

If the task needs 25 fps, the stream is 20 MB × 25 = 500 MB/s. Gigabit and 2.5 GbE are out, USB3 is at its edge, and 10 GbE carries it at 500 ÷ 1,100 ≈ 45% occupancy. That is the decision: 10GbE.

The link is only one ceiling, though. The sensor has its own readout limit, and exposure time caps frame rate at 1 ÷ exposure — 4 ms of light means at most 250 fps whatever the pipe. The piece on RGB camera frame rate limits: pixel format and exposure covers the camera side of that equation.

What frame rate does each link deliver at my resolution?

Divide the link payload by your Mono8 frame size: 100 MB/s on 1 GbE, 280 MB/s on 2.5 GbE and 1,100 MB/s on 10 GbE give the ceilings below, with the sensor usually capping you first above roughly 100 fps.

Double the frame size for YUV422 or unpacked 10-bit, triple it for RGB8. Above roughly 100 fps the sensor, not the cable, sets the ceiling; for genuine high speed work, the guide to machine vision sensor selection for high speed inspection picks up where this table stops.

Do jumbo frames raise the bandwidth limit?

Only by 5–15% in throughput, from roughly 95 to 100 MB/s on 1 GbE — but they cut the packet rate sixfold, which usually matters more than the bandwidth. A standard 1,500-byte IP packet carries 1,500 − 28 (IP + UDP headers) − 8 (GVSP header) = 1,464 bytes of pixels. Moving 100 MB/s that way takes 100,000,000 ÷ 1,464 ≈ 68,000 packets per second. A 9,000-byte jumbo packet carries 8,964 bytes of pixels, so the same stream takes ≈ 11,000 packets per second — six times fewer interrupts for the NIC and the CPU, which is where most of the benefit lands.

On the wire the payload share rises from about 95% to about 99%, worth a few percent of throughput. Set the packet size on the camera, on the NIC, and on every switch between them. At 68,000 packets per second, interrupt handling is real work; GigE camera interrupt moderation: balance latency and CPU load explains the knob that trades a little latency for a lot of CPU.

When does a high speed camera outgrow 1 GbE?

Above roughly 100 MB/s of sustained image data — 20 fps at 5 MP mono, 8 fps at 12 MP, 5 fps at 20 MP — the 1 GbE link is full, and no driver or camera setting will lift it. From the outside the clamp looks like this: the sensor datasheet promises a frame rate, the delivered rate pins at a constant value just below the link limit, and the counter never moves again. The camera is fine; the pipe is full.

The step-up ladder is short. Up to 100 MB/s, stay on 1 GbE. Up to 280 MB/s, 2.5 GbE runs on the same Cat5e plant. Up to 560 MB/s, 5 GbE wants Cat6. Beyond that it is 10 GbE, or leave Ethernet: USB3 for one camera close to the host, CoaXPress when the rate or the timing demands a frame grabber.

Sharing changes the arithmetic, not the rule — several full gigabit cameras can ride one 10 GbE uplink, and GigE camera network planning: switch ports and bandwidth works out how many. Once the wire is wide enough, the host becomes the next bottleneck, and acquisition faster than processing: fix the frame rate gap is that conversation.

10GigE, USB3 or CoaXPress: which transport do I choose?

Choose 10GigE for sustained streams up to about 1,100 MB/s over 100 m of Cat6a, USB3 for one camera within a few metres of the host, and CoaXPress-12 when you need 1,200 MB/s per coax with grabber-side buffering and deterministic triggering. The decision list, committed:

• One camera, up to 100 MB/s, copper runs to 100 m: 1 GbE GigE Vision. Done.
• One camera, 100–400 MB/s, within about 5 m of the host: USB3 Vision — no NIC, no grabber, power over the cable.
• Ethernet distances, 100–560 MB/s: 2.5 or 5 GbE.
• 400–1,100 MB/s, several cameras to one host, 100 m on Cat6a or fiber beyond: 10 GbE.
• Above 1,100 MB/s, or microsecond trigger-to-exposure timing with card-side memory: CoaXPress-12, about 1,200 MB/s per coax and near 4,800 MB/s across four, at the cost of one of the CoaXPress frame grabbers in the host.

Camera Link still earns its keep on legacy line-scan racks at up to about 850 MB/s (80 bits at an 85 MHz pixel clock); Camera Link frame grabber compatibility for line scan covers that retrofit path.

The same 20 MP IMX183 sensor ships on two transports:

All 2 share: Sensor type CMOS, rolling shutter; Sensor model Sony® IMX183; Pixel size 2.4 μm × 2.4 μm; Sensor size 1"; Resolution 5472 × 3648; SNR 41.5 dB; Gain 0 dB to 24 dB; Binning Supports 1 × 1, 2 × 2, 4 × 4. Values as printed in each product's data sheet; open a part for its drawing and full specifications.

On the wire, the GigE body tops out near 5 fps at full resolution, while the USB3 body clears 20 fps because its pipe is about four times wider. The GigE body earns its keep where long copper runs and switch infrastructure matter; the USB3 body wins on frame rate next to the machine.

For streams that genuinely fill a 10 GbE link, the MV-CH250-25TC-F-NF pairs a 25 MP PYTHON25K sensor with a 10GigE interface and an F-mount.

A 25 MP Mono8 frame is about 26 MB, so 40 fps is 26 × 40 = 1,040 MB/s — 95% of a 10 GbE link, exactly the occupancy this camera class is built for. Over CoaXPress-12 the same sensor class moves onto a card: the MV-CH250-90YC-M58S-NN is a 25 MP CXP-12 camera with an M58 mount.

CoaXPress gives you about 1,200 MB/s per coax and trigger timing driven by the grabber hardware, with image memory on the card absorbing bursts the host cannot.

What should I check before ordering the chain?

Check five things in order — camera payload rate, NIC or grabber bandwidth, switch capacity, cable category and host CPU — because the chain runs at the speed of its weakest member. Any one of them can clamp you below the link rate you paid for.

1. Camera: data rate at the target fps at or below 90% of the link planning number. Write the two figures on the spec sheet.
2. NIC or grabber: a dedicated card, not the motherboard port sharing traffic. A dual 10GigE frame grabber such as the MV-GT1102P carries two heavy cameras; a dual-port PoE NIC like the MV-GE2002P feeds and carries gigabit cameras.
3. Switch: non-blocking backplane, jumbo frames enabled end to end, cameras on their own switch or VLAN with no office traffic on the path.
4. Cable: Cat5e for 1 and 2.5 GbE, Cat6 for 5 GbE, Cat6a for 10GBase-T to 100 m, fiber SFP+ beyond. Moving gantries need drag-chain rated cables — a 3 m high-flex GigE cable such as the LS-CBL-0199 sets the pattern.
5. Host: receive buffers sized for bursts, and a CPU that survives the packet rate. GigE camera buffer timeouts on embedded Linux: socket buffer tuning covers the buffer side.

Software is the last check, and it is a standard, not a driver hunt: GigE Vision plus GenICam means any compliant library enumerates the camera — camera compatibility with vision software: what GigE Vision guarantees sets out exactly what that guarantee covers.

When is more bandwidth the wrong answer?

When you need the precise instant, not the movie: a hardware-triggered camera that timestamps its exposure answers most requests for 10,000 fps with a few frames and a microsecond clock, at a fraction of the data. Laser beam alignment is the classic case — you need to know when the spot crossed the sensor, and one triggered frame carries that answer at 2 MB instead of 2 GB. Trigger on the event, gate the exposure, ship the frames afterwards.

Region of interest is the second lever. The wire rate scales with pixels sent, so a 2048 × 2048 window of that 20 MP sensor is 4.2 MB instead of 20 MB — and 24 fps fits back onto gigabit. Binning 2 × 2 divides the data by four. Before paying for any of it, know your minimum pixel count:

Run your frame rate and resolution through the division once, write the two numbers down, and the transport picks itself. The camera finder filters area scan cameras by interface, and the configurator walks the whole chain — camera, lens, light, controller — with the bandwidth budget in hand. If your numbers land on a boundary, contact us and we will run the arithmetic with you.