Two GigE cameras on a Jetson Orin AGX, one small switch between them and the host. The vendor's viewer shows both cameras streaming at once, your ROS 2 driver finds both serials, and then the console prints in 10.0 out 0.00 drop 0% INCOMPLETE 100% on one camera. The launch file looks right, and both cameras were already proven at reduced rate and size. This guide walks the diagnosis in the order that finds the fault fastest on an embedded host: what INCOMPLETE means at the SDK layer, why the MTU you requested is not always the MTU the interface applied, and why a switch with five 1 GbE ports caps both cameras at one 1 Gbit path no matter what sits behind it. You finish with the applied-MTU check, a bandwidth budget for the uplink you really have, and the fix for each case.
What INCOMPLETE means at the driver
The stat line separates two failure layers. drop 0% says every frame that reached your software was consumed — no host-side queue loss. INCOMPLETE 100% says the SDK never reassembled a single frame: the camera transmitted it, and at least one packet vanished between the camera and host memory. The ROS 2 layer is the messenger here, not the fault.
Two mechanisms make this signature: the camera sends packets larger than the host interface will carry, or the path discards packets under load. The first is an MTU mismatch between driver and NIC, the second an incomplete-frames bandwidth problem. On a shared switch you can have both at once.
The likely causes, in order
Work down this table; the first two rows cover nearly every case where the vendor viewer works and only the driver fails.
| # | Cause | Why it fits here | Test | Fix |
|---|---|---|---|---|
| 1 | Camera packet size above the applied MTU | The launch file requests 9000; the interface came up lower | Read ifconfig, compare |
Set the camera packet size to the printed value |
| 2 | Both cameras share one 1 GbE uplink | Five 1 GbE ports funnel into one 1 Gbit path |
bmon with one camera at full rate |
Budget the fps or split the paths |
| 3 | Launch file sets no packet size | Multi-camera examples often omit the jumbo settings | Query the camera while streaming | Set it explicitly before acquisition starts |
| 4 | A host core is saturated | Embedded cores plus per-packet interrupt load |
top during streaming |
Bigger packets, free a core |
Step 1: read the applied MTU, not the requested one
Your launch file says 9000. That is a request. On Jetson modules the interface can accept the command and still come up at a different value, so read what actually applied: ifconfig on the streaming interface, before touching the driver. The camera transmits packets up to its configured packet size, and when that exceeds the interface MTU the packets are fragmented or dropped. The SDK then reports every affected frame as incomplete. The camera side must come down to the interface, never the other way round.
Set the camera's GigE Vision packet-size setting to the exact number ifconfig prints. If the interface holds 9000 but incomplete frames persist, drop the camera to 8966 and retest; embedded interfaces that sit just under 9000 are common. Restart acquisition after each change: the packet size is applied when the stream starts. That is why setting the packet size before acquisition is its own step, and it is how a negotiated value can quietly exceed the link — the packet size versus MTU cap case. An interface that refuses jumbo sizes entirely is the MTU stuck at 1500 problem, and that article walks getting jumbo frames working.
Step 2: measure what the uplink really carries
A Jetson Orin AGX gives you one user-facing interface for this job: the 10 GbE port. The module's second, 1 GbE interface is usually not brought out on the carrier, so everything enters through that one port. A switch with five 1 GbE ports gives each camera a private 1 Gbit port and then funnels both through a single 1 Gbit uplink. The 10 GbE side idles; the switch, not the host, sets the ceiling. And if the switch is rated 5 Gbit, that is its switching fabric, not the speed of the port facing your host — the uplink port speed is the number that counts.
Watch the interface with bmon while one camera streams full frames at full frame rate. That reading is the real per-camera ceiling through this switch. Two numbers frame it: 1 GbE carries 125 MB/s raw, and a GigE Vision stream sustains about 110-118 MB/s of that with jumbo frames — plan on 110 MB/s, or 880 Mbit/s — falling to roughly 60-70 MB/s at the standard 1500-byte MTU, because per-packet overhead and interrupt load eat the difference. Sharing one link between cameras is exactly the two cameras on one host budget, and planning six cameras across one switch scales the same arithmetic.
Step 3: prove each camera alone through the driver
Before blaming the multi-camera launch file, run each camera by itself in single-camera mode at full frame size, and raise the frame rate until INCOMPLETE appears. That crossing point is the per-camera ceiling through this path. If camera A dies at 9 fps and camera B sails past 30, you have a cable or port fault, not a budget fault. If both cross where the uplink math says, the budget is the fault. The test needs no special hardware — any GigE camera on the bench will saturate a shared gigabit path, including a 6 MP GigE mono model:
- Sensor format
- 1/1.8"
- Lens mount
- C-mount
- Interface
- GigE
- Resolution
- 6-10 MP
Run top while streaming. A core pinned near 100% means packets are not being drained from the interface fast enough: too many packets, too few buffers, no free core. Bigger packets are the direct cure, which is another reason row 1 of the table comes first. Bad frames under heavy multi-camera use covers that host-side budget. And if the pair must run hardware-synchronized, move to the synchronized multi-camera driver once the link is clean — the budget does not change.
Worked example: two 5 MP mono cameras at 10 fps on one 1 GbE uplink
Inputs: two cameras at 2448 × 2048 pixels, mono 8-bit, target 10 fps each; both on 1 GbE ports of the switch; one 1 Gbit uplink to the Jetson's 10 GbE port. Ceilings from Step 2: about 110 MB/s with jumbo frames, about 65 MB/s at a 1500-byte MTU.
The arithmetic, written out:
- frame = 2448 × 2048 × 1 B = 5,010,048 B, or about 5.0 MB per frame
- per camera = 5.0 MB × 10 fps = 50 MB/s = 400 Mbit/s
- both cameras = 50 MB/s × 2 = 100 MB/s = 800 Mbit/s
- against the jumbo ceiling: 800 Mbit/s / 880 Mbit/s = 91% of the path, 10 MB/s spare
- against the 1500-byte ceiling: 100 MB/s of demand on a 65 MB/s path is 54% over, so loss on every frame
- packets per frame: 5,010,048 / 8966 is about 559 with jumbo frames; 5,010,048 / 1500 is about 3,340 without — six times the interrupt load for the same pixels
Decision: through this switch, cap both cameras at 8 fps. That is 5.0 MB × 8 fps × 2 = 80 MB/s = 640 Mbit/s, or 73% of the jumbo ceiling, which leaves the headroom a shared uplink needs for bursts and resends. Above 8 fps each, change the hardware, not the driver: a 10 GbE uplink from the switch into the Jetson's 10 GbE port, or one 1 GbE path per camera.
The fix for each case
The interface will not hold 9000. Set the camera packet size to the number ifconfig prints, retest one camera to full rate, then add the second. If the interface reads 9000 but frames stay incomplete, 8966 on the camera is the standard fallback. Retest after every change.
The launch file sets no packet size. The multi-camera example you started from often omits the jumbo lines the single-camera example carries. Copy the packet-size settings across so both cameras start inside the interface's real MTU.
The uplink is the ceiling and you need full rate. On the Jetson, the practical route is a switch with a 10 GbE uplink into the 10 GbE port. On a PC host, ports are the direct fix, and the frame grabbers category lists them:
- Interface
- GigE
- Ports
- 4 ports
The MV-GE1104 is a 4-port GigE frame grabber. One port per camera removes the shared uplink entirely. When the path grows past gigabit, the host side has to grow with it:
- Interface
- 10GigE
- Ports
- 4 ports
The MV-GT2104 is a quad-port copper 10GbE NIC for the 10 GbE switch case.
A core is pinned. Get the packet size up first, because fewer and larger packets cut the interrupt load directly, then free a core for the driver and retest.
The physical layer. Reseat and lock every connector, and use drag-chain-rated cables wherever anything moves:
A 3 m high-flex GigE camera cable with screw locks holds a moving run where a patch cable works loose.
Checklist before you call it solved
-
ifconfigon the streaming interface prints a value at or above the camera packet size, read after the last change. - The launch file sets the packet size explicitly for every camera; nothing relies on a default.
- With both cameras at full rate,
bmonshows the total under 80% of the uplink ceiling. - Each camera alone reaches full rate through the driver before you combine them.
-
topshows no core pinned at 100% during streaming. - The switch uplink speed matches the host port; a 1 GbE uplink into a 10 GbE port still caps the path at 1 Gbit.
- Every connector is locked, and moving runs use high-flex cable.
If the budget still does not close on paper, send the ifconfig output, the bmon reading at full rate and the camera resolutions to our applications team — free expert support comes with every order. To re-spec the link instead, start from the GigE camera finder or the system configurator, and the systems topic collects the related guides.
Questions
Why does the vendor viewer show both cameras while the driver reports INCOMPLETE?
The viewer applies its own packet-size negotiation when it opens a camera, so it streams within whatever MTU the interface actually has. The multi-camera launch file often sets no packet size at all, so the camera falls back to large default packets that no longer fit. Viewer testing also tends to run at reduced fps and ROI, which can sit under the uplink ceiling while full frames do not. Set the packet size in the launch file, then retest at full size.
What packet size should the camera use when the Jetson interface will not hold 9000?
Whatever `ifconfig` prints on the streaming interface, and never a byte more. If the interface holds 9000 but frames still come back incomplete, drop the camera to 8966 and retest; embedded interfaces sometimes accept an MTU command yet sit just under it. Prove the path with a don't-fragment ping sized to the payload before restarting acquisition, because the packet size only takes effect when the stream starts.
How much bandwidth do two cameras really get through a 5x1 GbE switch?
One 1 Gbit uplink, shared. A GigE Vision stream sustains roughly 110 MB/s (about 880 Mbit/s) with jumbo frames and closer to 65 MB/s at the standard 1500-byte MTU, so plan about 50 MB/s per camera once jumbo frames work. In fps, divide 50 MB/s by your frame size in megabytes: a 5.0 MB frame caps near 10 fps per camera, so run 8 fps to keep headroom.
The 10 GbE port is free, so is the problem solved?
Not through a switch with 1 GbE ports. The port facing the host runs at 1 Gbit, so the Jetson Orin AGX's 10 GbE interface changes nothing until the uplink is 10 GbE too; a switch rated 5 Gbit is quoting its switching fabric, not that port. To use the 10 GbE side, put a switch with a 10 GbE uplink between the cameras and the host, or give each camera its own 1 GbE path.
ifconfig shows zero errors and zero drops, so is the link cleared?
No. Those counters only see packets that reached the interface. A switch that discards traffic ahead of its uplink never delivers it, so the loss surfaces as incomplete frames at the SDK and nowhere else. Read throughput with `bmon` instead: if both cameras together pull far less than the streams should need, the switch is dropping packets upstream of your counters.