MTU stuck at 1500 for camera streaming: get jumbo frames working

You set the camera up for jumbo frames and run ifconfig enp6s0 MTU 9000 on the controller. The answer comes back ifconfig: SIOCSIFMTU: Invalid argument, and values below 1500 are the only ones the port ever accepts. That refusal is the diagnosis: the port's driver carries a hard cap at the standard Ethernet frame size, so no config-file edit, kernel argument or retry will lift it. This page gives you the two-minute test that proves the cap, the packet arithmetic that says whether 1500 actually hurts your stream, and the hardware paths that put jumbo frames on the camera link.

What an SIOCSIFMTU refusal means

The kernel hands every MTU change to the interface's driver through the SIOCSIFMTU request, and the driver checks the value against its own maximum before touching hardware. Invalid argument means the driver refused the value outright — the setting never reached the cable.

The command line itself is innocent, and the ladder below proves it in two minutes: an interface that accepts MTU 1300 and refuses MTU 3000 has localized its limit to exactly 1500. Two causes cover nearly every refusal, in order of likelihood:

1. The port's driver caps frames at 1500 bytes. Controller-class and embedded boards often expose Ethernet through drivers built for the board's own switch fabric rather than a desktop NIC, and several of those drivers accept nothing larger than the standard frame. Vendors of real-time control hardware state the same boundary in their knowledge bases: jumbo frames are supported only where the controller provides a gigabit Ethernet port with driver support behind them, and not at all otherwise.
2. The interface is not the physical port. A bridge, VLAN or switch user port sits in front of the hardware and imposes its own limit; boards that expose internal switch ports as interfaces reject larger frames on the user side even when the silicon could carry them.

A limit you configured yourself (a bridge or bond you created) can be undone; a cap built into the board's driver cannot.

The two-minute ladder test

1. ifconfig enp6s0 MTU 1500 — accepted: the port handles the standard frame.
2. ifconfig enp6s0 MTU 3000 — refused: the cap sits at or below 1500 bytes.
3. ifconfig enp6s0 MTU 9000 — refused: the driver will not carry jumbo frames at all.

Accepted values below 1500 confirm the tool and syntax work, so no more retries are needed. The limit lives in the driver, and the fix is hardware, covered below.

The packet arithmetic at MTU 1500

An MTU counts the whole frame, not the image data inside it. About 52 bytes of IP, UDP and GigE Vision stream headers ride in every packet, so a 1500-byte MTU delivers roughly 1448 bytes of image payload per packet and a 9000-byte MTU roughly 8948 bytes. (1 MB = 1,000,000 bytes throughout.)

The link itself also caps packet count. A gigabit link moves 125,000,000 bytes per second, and a 1500-byte frame occupies about 1538 bytes on the wire once preamble and inter-frame gap are counted, so the port tops out near 81,300 packets per second — about 118 MB/s of image data. With 9000-byte frames the wire carries about 13,800 packets per second, about 124 MB/s of image data.

Put the two ceilings side by side and jumbo frames fall into perspective: they raise the link's data capacity by about 5 percent. What they really buy is a 6-times-smaller packet count — 6 times fewer interrupts and memory copies on the host CPU, which is the resource a small embedded controller runs out of first.

Worked example: a 2.5 MP camera at 30 fps into a port capped at 1500

Inputs, and where each comes from:

• Frame size: 2,500,000 bytes — 2.5 megapixels at 8 bits per pixel, the class of camera shown below.
• Frame rate: 30 frames per second, the case being sized.
• Payload per packet: 1448 bytes at MTU 1500, 8948 bytes at MTU 9000, from the 52-byte header overhead above.
• Wire ceiling: about 81,300 packets per second at MTU 1500, from the gigabit arithmetic above.

Arithmetic:

• Packets per frame: 2,500,000 ÷ 1448 = 1727 (the last packet carries the remainder, so round up).
• Packets per second: 1727 × 30 = 51,810, call it 51,800.
• Share of the wire ceiling: 51,810 ÷ 81,300 = 64 percent.
• The same stream at MTU 9000: 2,500,000 ÷ 8948 = 280 packets per frame, × 30 = about 8400 packets per second — 6.2 times fewer.

Decision: the stream fits the link at MTU 1500, at 64 percent of the packet ceiling, so on paper the port can carry it. The cost is per-packet work: 51,800 interrupts-and-copies per second is what pushes a small controller's CPU past its limit, and the visible symptom is a dropped-packet counter that climbs during streaming. We size camera ports to stay under about 65,000 packets per second at MTU 1500 — roughly 80 percent of the wire ceiling — and treat a climbing drop counter as the signal that the receive path is out of headroom. Here, with the driver refusing 9000 anyway, the decision is to move the camera to a port whose driver carries jumbo frames rather than to keep tuning at 1500.

The camera behind these inputs is a 2.5 MP color GigE model on a 1/1.7" sensor with a global shutter:

When MTU 1500 is genuinely enough

A 1500-byte cap limits packets per second, not resolution. A sub-megapixel stream sits well inside the budget: a 900,000-byte frame costs 900,000 ÷ 1448 ≈ 622 packets, and at 60 frames per second that is about 37,300 packets per second, or 46 percent of the ceiling. That stream belongs at MTU 1500; if it still misbehaves on a capped controller, the receive path is dropping packets under load — watch the dropped counter climb into the thousands — and the cure is tuning or hardware, not a different pixel count. Torn or half-delivered images point specifically at a driver and NIC MTU mismatch, which GigE incomplete frames from a driver and NIC MTU mismatch walks through.

The budget runs out on frame size and rate together. At 30 frames per second, MTU 1500 carries at most about 3.9 MB per frame (118 MB/s ÷ 30); jumbo frames lift that only to about 4.1 MB (124 ÷ 30). A 5 MB frame at 30 fps needs 150 MB/s of image data, past either ceiling, and the answer there is a faster transport — a 10GigE or CoaXPress camera on a matching port from the frame grabbers range — not a bigger MTU. Between those extremes, the packets-per-second formula tells you which side of the line you are on.

Getting jumbo frames end to end

1. Give the camera its own jumbo-capable port. Desktop PCIe NIC drivers almost always include jumbo-frame support, with maximums of 9000 bytes or more; the printed maximum transfer unit is the number to order against. A desktop NIC also brings a driver whose receive path has headroom of its own — GigE Vision high performance NIC driver: how much you gain measures it. The part that adds this to a controller with a free slot is a dual-port PoE gigabit NIC on a full-height card:

2. Spread multiple cameras across ports. Each gigabit port owns its own roughly 118 MB/s image budget, so one port per camera beats sharing, on the same arithmetic as Two GigE cameras on one host: NIC ports and bandwidth budget. A multi-port frame grabber holds four cameras on four independent gigabit ports in one card:

3. Pick a controller whose ports match the packet plan. If the built-in ports are capped, a controller with PCIe expansion accepts the NIC from step 1, and PoE camera ports cut cabling at the same time — browse vision controllers for multiple LAN ports and PCIe expansion. This model pairs five-plus LAN ports and four built-in light channels with 8 GB of memory and PCIe expansion supported:

4. Raise the camera's packet size to match. Set the GigE Vision packet size to the largest value the whole path accepts; at a 9000-byte host MTU each packet then delivers roughly 8948 bytes of image payload. A camera set above what the path carries fails acquisition setup instead, and GigE Vision packet size exceeds MTU: cap auto-negotiation covers that case.
5. Carry the frame size on every port in between. One switch port left at 1500 bytes silently drops the big frames. Enable the larger size on each switch port in the path, as GigE camera network planning: switch ports and bandwidth lays out.
6. Re-check drops after the move. If packets still go missing at 9000 bytes, the remaining causes are socket buffers and NIC tuning, best applied in a fixed order: Packet missing from image: NIC tuning in the right order. Where the link still times out, the GigE Vision stream timeout checklist walks the packets-buffers-MTU sequence, and GigE Vision packet loss: horizontal lines in live images maps tear patterns to causes.

Keeping it fixed on the next build

• Ladder-test every camera port at commissioning — 1500, then 3000, then 9000 — and record the accepted value on the build sheet.
• Persist an MTU line only for a value the port has already accepted at the command line.
• Order camera ports against the packet plan: a maximum transfer unit of 9000 bytes or more, whether the port is onboard, on a NIC or on a frame grabber.
• Keep image traffic on dedicated ports at the working MTU and leave the management port at 1500 for everything else.
• Re-check the interface drop counters after a week of production; a counter that creeps upward is the packet budget asking for headroom before it becomes a line stop.

The decision in one pass: prove the cap with the ladder, check your packet budget, then either stay at 1500 with headroom or move the camera to hardware that carries jumbo frames. If you want the receive path sized against a specific camera list, send the frame rates through the contact page, or read the neighboring systems guides for the rest of the stream pipeline.