Updated for GigE Vision 3.0 and IEC/IEEE 60802:2026
Industrial Ethernet for Machine Vision: LACP, TSN & GigE Vision Bandwidth
Industrial Ethernet for machine vision is not only a question of adding more network ports. A reliable multi-camera machine vision network must account for payload bandwidth, burst traffic, buffering, packet size, host load, synchronization and the full PCIe and memory path.
In short
Size a machine vision network from the camera traffic pattern, not the port count. Use dedicated 1/2.5GbE ports for a few cameras, LACP or a 10GbE uplink when many independent streams share a switch, and a faster physical link when any single stream exceeds one member link. Use hardware triggers or PTP for synchronization, and evaluate TSN only when vision, motion and best-effort traffic must share one Ethernet fabric. At 25/100GbE, GigE Vision 3.0 with RoCEv2 shifts the bottleneck to the host’s PCIe, memory and GPU path.
Account for
Camera payload · peak bursts · switch & NIC buffering · jumbo frames · host CPU & interrupts · timestamps · LACP behavior · OS & drivers · PCIe & memory · deterministic control traffic
Decide first
Define the workload and data path before choosing between dedicated NICs, LACP, 10GbE, TSN, EtherCAT, CAN FD or GigE Vision 3.0 / RoCEv2.
Looking for the application-level platform rather than the network architecture? See BITECH Machine Vision & AOI Industrial Computing Solutions.
Quick answer
Which machine vision network architecture should you start with?
| Requirement | Best starting architecture |
|---|---|
| 2–4 GigE cameras | Dedicated 1GbE / 2.5GbE NIC ports |
| Several independent camera streams through one managed switch | LACP or a higher-speed 10GbE uplink |
| One individual stream exceeds 2.5Gbps | 5/10/25GbE; LACP does not make one flow faster than one member link |
| Synchronized image acquisition | Hardware trigger, IEEE 1588/PTP, camera-specific synchronization or a combination |
| Vision + motion on separate networks | Dedicated vision Ethernet + EtherCAT / control network |
| Vision + time-critical control + best-effort traffic on one Ethernet fabric | Evaluate TSN |
| High-density 25/100GbE+ camera aggregation | Evaluate GigE Vision 3.0, RoCEv2/RDMA and the complete host data path |
| AGV sensors / BMS / distributed devices | CAN / CAN FD depending on protocol and topology |
| Legacy sensors / PLCs | RS-485 / Modbus or Modbus TCP as required |
The correct design depends on the traffic pattern, not only the nominal port speed.
01 · Beyond bandwidth
Industrial Ethernet for machine vision is not just about bandwidth
Machine vision systems often move large amounts of image data, but high line rate alone does not guarantee reliable acquisition. A network can show acceptable average bandwidth while still dropping packets during short bursts.
A real deployment may involve
- Several cameras triggered at nearly the same time
- GigE Vision packet bursts
- Switch uplink contention
- CPU-intensive inference running simultaneously
- NVMe recording
- PTP timestamping
- PLC traffic
- Remote diagnostics
- Motion-control data
Engineering should focus on
payload rate + burst behavior + buffering + host processing + synchronization + recovery behavior
…rather than a single “Gbps” number. This is why an industrial PC with four 2.5GbE ports is not automatically equivalent to a 10GbE machine vision computer, and why a TSN-capable NIC alone does not make an entire system deterministic.
02 · Calculation
How to calculate GigE Vision bandwidth
A useful first-order estimate for uncompressed GigE Vision image payload is:
Payload bandwidth ≈ Width × Height × Bits per Pixel × Frames per Second
Worked example
1920 × 1200 × 8-bit × 50 FPS= 921,600,000 bits/s≈ 922 Mbps of image payload
That is already close to the useful capacity of a 1GbE link before Ethernet, IP, UDP and GigE Vision protocol overhead.
The real requirement also depends on
Pixel formatPacket headersFrame metadataInter-packet delayPacket resend trafficCamera implementationSwitch bufferingTrigger behavior
GigE Vision bandwidth calculator · payload estimate
922 Mbps
Payload per camera
922 Mbps
Total payload, all cameras
92%
Of one camera’s link, before overhead
Payload only. Add margin for Ethernet/IP/UDP/GigE Vision overhead, metadata, resends and the camera’s burst pattern, then validate on the real camera.
Do not use a fixed assumption such as “one 4K camera equals 900Mbps.” Two cameras with the same resolution can have very different network requirements if bit depth, frame rate, compression or triggering differs.
Practical rule
When sizing a multi-camera machine vision network, calculate both (1) the sustained payload bandwidth and (2) the worst-case short-term burst bandwidth. The second value is often where real systems fail.
03 · Bursts
Average bandwidth is not enough: design for camera bursts
A common field problem is packet loss even when the average traffic appears to be below the NIC limit. Cameras do not always transmit image data evenly across the entire frame period.
Example: two cameras, one 1GbE uplink
Their long-term average may appear acceptable. But after both cameras finish exposure, each may try to transfer its image at close to the full link rate. If those transfers overlap, the uplink and receive queues can be oversubscribed.
Camera A ≈ 1 GbpsCamera B ≈ 1 GbpsShared 1GbE path → 2 Gbps demand
NI machine-vision engineering discussions have documented this exact failure pattern.
Symptoms
- Incomplete frames
- GVSP packet loss
- Image timeouts
- Resend storms
- Irregular frame rate
- CPU spikes
- Acquisition instability that appears only under synchronized triggers
Engineering implication
For synchronized or bursty cameras, use one or more of the following:
Dedicated NIC portsCamera bandwidth limiting / Stream Channel Packet DelayNon-blocking switch with sufficient uplink2.5/5/10GbE uplinksExplicit camera-to-port mappingValidated receive buffersTraffic scheduling where appropriate
This is more reliable than assuming that an average bandwidth calculation alone guarantees lossless acquisition.
04 · Architecture
Dedicated NICs vs LACP vs 10GbE for machine vision
There are three common ways to increase network capacity in a machine vision PC.
| Architecture | Nominal aggregate rate | Main advantage | Main limitation |
|---|---|---|---|
| 4 independent 2.5GbE ports | 10Gbps total across ports | Explicit camera-to-port mapping | More routing/configuration |
| 2×2.5GbE LACP | 5Gbps aggregate | Link aggregation + resilience | One flow normally stays on one member link |
| 4×2.5GbE LACP | 10Gbps aggregate | More aggregate host-to-switch bandwidth | Depends on traffic hashing and switch design |
| 1×10GbE | 10Gbps | Simple high-bandwidth uplink | Requires 10GbE NIC, switch and cabling |
| 25/100GbE | 25–100Gbps | High-density aggregation | Host PCIe, memory and processing become critical |
When dedicated NICs are easier
For many machine vision systems, multiple dedicated NIC ports are simpler to engineer than LACP. A camera or camera group is assigned directly to one physical interface, making bandwidth ownership explicit.
TroubleshootingPacket captureCamera discoveryRoutingFailure isolationDeterministic camera-to-port planning
When LACP makes sense
LACP is more attractive when many independent streams are already aggregated through a managed switch and the host requires additional aggregate uplink bandwidth or link redundancy.
BITECH platforms Dedicated ports: AX-320BT (8× 2.5GbE) or AX-134BT (4× independent GbE + Intel AMT). Mixed 2.5GbE + 10G uplink: AX-340BT (6× 2.5GbE + 4× 10G SFP).
05 · LACP
What LACP actually does in a machine vision network
Link Aggregation Control Protocol builds a logical link from multiple physical Ethernet links. Historically associated with IEEE 802.3ad, link aggregation is now standardized under IEEE 802.1AX. LACP can provide higher aggregate host-to-switch bandwidth, link resilience and load distribution across multiple independent flows.
It does not mean that every individual camera connection can use the sum of all member links. The Linux bonding documentation for 802.3ad notes that a single connection is normally limited to one physical interface’s bandwidth.
Example
4×2.5GbE LACP → 10Gbps aggregate
…but one individual flow is normally still limited to one 2.5GbE member link. This matters if one camera stream exceeds 2.5Gbps, one receiver session dominates traffic, the switch hash maps too many camera flows to the same member, or traffic is not sufficiently distributed.
LACP machine vision design checklist
- Managed switch supports the required LAG/LACP configuration
- All members use compatible speed/duplex
- Hash policy distributes camera flows effectively
- Redundancy behavior is tested
- Switch buffering is adequate
- Host driver and OS bonding configuration are validated
- Camera discovery and routing still behave as expected
What LACP does not guarantee
Deterministic latencyZero packet lossCamera synchronizationTSN behaviorOne-stream bandwidth above one member linkLossless failover under every condition
Treat LACP as aggregation and resilience, not as a replacement for end-to-end machine vision validation.
Need to aggregate several camera VLANs before they reach MES or storage? The AX-340BT network appliance combines 6× 2.5GbE (Intel i226-V) and 4× 10G SFP (Intel X553) for VLAN segmentation and aggregated 10G uplinks. Validate the LACP / bonding mode in your OS and switch before deployment.
06 · Port speed
2.5GbE vs 10GbE for machine vision
2.5GbE is a good fit for
- Multiple moderate-bandwidth cameras
- Distributed camera-to-port architectures
- Compact fanless industrial PCs
- Systems where 10GbE power or switch cost is unnecessary
2.5GbE provides more bandwidth than 1GbE while preserving relatively simple copper cabling and embedded-PC integration.
10GbE becomes more attractive when
- Many camera streams converge through one switch
- One uplink must carry several independent cameras
- Recording and AI inference share the network
- The camera count is expected to grow
- The architecture is moving toward 10GigE / high-resolution sensors
A multi-camera industrial PC may benefit from 4×2.5GbE for explicit camera segmentation plus 1×10GbE for aggregation, storage or upstream connectivity, rather than treating one architecture as universally superior. Base the decision on measured camera traffic and future headroom.
BITECH platforms AX-340BT: 6× 2.5GbE + 4× 10G SFP in one fanless box, for 0–40°C cabinets and racks. Factory floor or harsh site: AX-320BT, 8× 2.5GbE, 9–36V, -20 to +60°C. 10GbE NIC or frame grabber in a PCIe slot: AX-660EBT.
07 · Troubleshooting
GigE Vision packet loss: what to check first
Real-world GigE Vision packet loss is often caused by the complete host/network path rather than the camera alone.
Common contributors
- Insufficient NIC receive buffers
- Packet size mismatch
- Unsupported jumbo frames somewhere in the path
- CPU saturation
- High interrupt rate
- Switch congestion
- Camera burst overlap
- Inadequate inter-packet delay
- Low-quality or marginal cabling
- USB-to-Ethernet adapters for high-rate acquisition
- Acquisition software / driver overhead
Recommended troubleshooting sequence
- Verify negotiated link speed.
- Test one camera directly to the PC.
- Monitor camera lost-packet / resend counters.
- Check host CPU utilization during acquisition.
- Confirm NIC receive-buffer settings.
- Validate MTU end-to-end.
- Test at 1500-byte MTU if jumbo-frame behavior is uncertain.
- Increase packet size only after the full network path supports it.
- Adjust camera packet delay / bandwidth reservation.
- Add cameras one at a time and record the failure threshold.
This approach is more useful than simply enabling “jumbo frames” and assuming the problem is solved. Computer-vision community discussions repeatedly point to receive-buffer sizing, jumbo packets, CPU availability and NIC quality as practical troubleshooting steps.
08 · MTU
GigE Vision jumbo frames help, but only end to end
GigE Vision systems often use jumbo frames because a larger packet size reduces packet-per-second rate, interrupt frequency, protocol overhead and CPU work per byte. A common configuration is an MTU around 9000 bytes, but the exact supported value depends on the devices.
Every hop must support the selected MTU.
If one component does not, failures may appear as
- Missing test packets
- Intermittent frame loss
- Timeouts
- Camera discovery but failed acquisition
Jumbo-frame validation checklist
Camera packet sizeIndustrial switch maximum frame sizeNIC MTUDriver supportHost receive buffersCamera resend statisticsPacket captureCPU / interrupt load
NI troubleshooting guidance has long recommended testing at a standard 1500-byte packet size when jumbo-frame behavior is uncertain. If 1500 bytes works and 9000 does not, the path has an MTU-related problem. Jumbo frames are an optimization, not a substitute for sufficient bandwidth and buffering.
09 · Synchronization
PTP for multi-camera machine vision synchronization
Many machine vision systems need accurate timestamps or synchronized capture but do not need full TSN. Depending on the cameras and application, synchronization may use:
Hardware triggerIEEE 1588 Precision Time ProtocolgPTP / IEEE 802.1AS in TSN systemsVendor-specific synchronizationEncoder / line-trigger signals
Do you need TSN, or only PTP?
| Requirement | PTP / trigger may be enough | Consider TSN |
|---|---|---|
| Camera timestamp alignment | ✓ | |
| Multi-camera synchronized acquisition | ✓ / application dependent | Optional |
| AI image transfer only | ✓ | |
| Vision and motion on separate networks | ✓ | |
| Vision + motion + IT traffic on one Ethernet fabric | ✓ | |
| Scheduled traffic windows | ✓ | |
| Bounded latency under mixed network load | ✓ | |
| Network convergence across multiple industrial traffic classes | ✓ |
Industrial-automation community discussions reflect this distinction: many engineers see PTP as sufficient for timestamping and measurement workloads, while TSN becomes more compelling when deterministic and best-effort traffic must coexist on one converged network.
10 · TSN
TSN industrial Ethernet: determinism is different from bandwidth aggregation
Time-Sensitive Networking (TSN) is a family of IEEE 802.1 technologies for time synchronization, traffic scheduling, traffic shaping and reliability. TSN and LACP solve different problems.
LACP primarily addresses
- Aggregate bandwidth
- Load distribution
- Link resilience
TSN primarily addresses
- Time synchronization
- Bounded traffic behavior
- Scheduled access to Ethernet
- Traffic-class coexistence
- Selected redundancy mechanisms
A machine vision system may use LACP without TSN, TSN without LACP, both, or neither, depending on the architecture.
Important TSN mechanisms
- IEEE 802.1AS / gPTP
- Time synchronization for TSN networks.
- IEEE 802.1Qbv
- Time-Aware Shaper, allowing scheduled transmission windows.
- IEEE 802.1Qbu / IEEE 802.3br
- Frame preemption mechanisms used to reduce blocking by lower-priority traffic.
- IEEE 802.1CB
- Frame Replication and Elimination for Reliability (FRER) for selected redundancy architectures.
- IEEE 802.1Qcc
- Enhancements for stream reservation and configuration.
A TSN-capable endpoint is only one part of the system. The complete communication path must support the TSN functions actually required by the application.
11 · 2026 standard
IEC/IEEE 60802:2026, the industrial automation TSN profile
A major 2026 development is the publication of IEC/IEEE 60802-2026, Time-Sensitive Networking Profile for Industrial Automation, published on June 29, 2026. Industrial TSN should no longer be treated as a random checklist of individual IEEE features.
IEC/IEEE 60802 selects
Features, options, configurations, defaults, protocols and procedures for bridges, end stations and LANs used in industrial automation.
“This NIC supports PTP” or “This controller supports Qbv” does not by itself establish an interoperable industrial TSN system.
Why this matters for industrial PCs: validate
NIC capabilityDriver supportOS networking stackSwitch featuresClock architectureNetwork configurationPeer devicesApplication timing
For OEM projects, “TSN support” should be defined by the exact required profile and tested network architecture.
12 · TSN vs EtherCAT
TSN is not automatically a replacement for EtherCAT
TSN creates new possibilities for converged industrial Ethernet, but it should not be marketed as an automatic replacement for every established real-time network.
What the field is seeing
- Interest in OPC UA FX and TSN continues to grow
- Deployment in brownfield systems remains gradual
- EtherCAT remains effective for dedicated motion networks
- Ordinary Ethernet / OPC UA remains sufficient for many monitoring and MES workloads
- PTP alone can satisfy many timestamping applications
The real engineering question
Do we need deterministic traffic, best-effort traffic and synchronization to share the same Ethernet infrastructure?
If the answer is no, a separate motion network plus a dedicated machine vision network may remain simpler.
13 · GigE Vision 3.0
GigE Vision 3.0: RoCEv2 and RDMA change the host data path
The Association for Advancing Automation (A3) approved GigE Vision 3.0 in April 2026 and officially announced its release in May 2026. The major addition is support for RoCEv2 (RDMA over Converged Ethernet v2) through the new GVRSP (GigE Vision RDMA Streaming Protocol). It supplements the existing GigE Vision streaming architecture rather than simply replacing earlier cameras.
Why RDMA matters
Traditional high-rate camera streaming can consume significant host resources for packet processing, memory copies, interrupt handling and error management. RDMA can allow camera data to move more directly into system memory with much less CPU intervention.
A3 describes GigE Vision 3.0 as enabling:
Lower CPU utilizationHigh throughputLow latencyZero-copy image transferScaling toward 400Gbps-class architectures
Engineering implication
At 25/100GbE and above, the bottleneck may no longer be the Ethernet cable. The system architect must also evaluate:
PCIe link width & generationNIC DMA capabilityHost memory bandwidthNUMA topologyGPU data pathStorage bandwidthSwitch architectureCongestion control
This moves machine vision computer design closer to high-performance data-pipeline engineering.
14 · RoCEv2
RoCEv2 machine vision is an end-to-end architecture
A RoCEv2-capable NIC does not automatically create a production-ready RDMA machine vision network. The complete system may need validation of:
Switch bufferingQoSQueue mappingCongestion behaviorECN configurationPriority handlingNIC firmwareDriverOperating systemApplication RDMA stack
Depending on the network design, features such as PFC may also be evaluated, but they should not be treated as a universal checkbox.
RDMA performance is an end-to-end property. For GigE Vision 3.0 platforms, BITECH recommends treating the camera, switch, NIC, PCIe topology, memory architecture and GPU path as one system.
15 · 25/100GbE
25/100GbE machine vision: the host can become the bottleneck
As camera links move beyond 10GbE, the host architecture becomes increasingly important. A high-speed NIC may be capable of 25, 100 or more Gbps, but actual acquisition can still be limited by:
Insufficient PCIe bandwidthPCIe lane sharingChipset uplink limitsMemory bandwidthCPU packet-processing overheadGPU transfer pathStorage write speedThermal throttling
This is why “10GbE port available” or “100GbE NIC installed” should not be treated as proof of application throughput. For a high-density machine vision PC, validate the full path:
16 · Controller selection
Industrial Ethernet controller selection: what to validate
Industrial Ethernet controller selection should be based on the exact system requirement rather than a marketing label such as “TSN NIC.” Validate:
Number of physical ports1/2.5/5/10/25GbE line rateOperating temperatureHardware timestampingPTP / gPTP capabilitySelected TSN functionsDriver supportLinux kernel / Windows supportJumbo-frame supportReceive/transmit queuesSR-IOV or virtualization if requiredLifecycle and availability
If an Intel I225/I226-class controller is considered, use the exact controller SKU and Intel specification for temperature and feature confirmation. Do not assume all consumer and industrial variants have the same environmental or TSN capabilities.
17 · Control networks
EtherCAT, CAN FD and Modbus: keep vision and control roles clear
Machine vision Ethernet and machine-control communication often coexist in the same industrial computer, but the protocols solve different problems.
| Technology | Main strength | Typical role | Engineering dependency |
|---|---|---|---|
| GigE Vision | Image transport over Ethernet | Industrial cameras | Camera bandwidth, NIC, switch, host stack |
| TSN Ethernet | Converged time-aware Ethernet | Mixed OT/IT/time-critical traffic | End-to-end TSN ecosystem |
| EtherCAT | Deterministic distributed motion/I/O | Servo drives, motion, robot control | Master stack, topology, slave devices, cycle target |
| CAN / CAN FD | Robust distributed device communication | AGV, BMS, sensors, drives | Bitrate, bus length, termination, protocol layer |
| Modbus TCP | Simple Ethernet device integration | SCADA, PLCs, instruments | Polling model and network loading |
| RS-485 / Modbus RTU | Simple robust serial communication | Legacy sensors and controllers | Isolation, termination, serial timing |
Avoid assigning fixed “universal” cycle-time numbers to a protocol without defining the complete system. EtherCAT can support very fast control loops, but achievable cycle time still depends on frame size, device count, master implementation, slave hardware, application processing, topology and synchronization requirements.
18 · Physical layer
CAN isolation and termination: keep the physical layer correct
Galvanic isolation can reduce ground-loop and common-mode problems in industrial CAN networks, especially when devices are powered from different domains or cable runs are exposed to noisy machinery. But isolation does not replace correct bus design.
For Classical CAN or CAN FD
- Use a linear bus where possible
- Minimize stubs
- Match bitrate to bus length and transceiver capability
- Validate common-mode voltage
- Place termination at the two physical ends of the bus
The 60Ω check
With two 120Ω termination resistors installed at the physical ends, a powered-off healthy bus normally measures approximately:
60Ω between CAN_H and CAN_L
Do not describe “60Ω termination” as a single built-in resistor value.
19 · Decision table
Machine vision network architecture decision table
| System requirement | Recommended starting point | Key validation |
|---|---|---|
| 1–2 moderate GigE cameras | Dedicated 1GbE / 2.5GbE | Payload + burst bandwidth |
| 3–4 cameras | Multi-port industrial PC | Camera-to-port allocation |
| Several cameras through managed switch | 10GbE uplink or LACP | Switch fabric + hash distribution |
| One stream >2.5Gbps | 5/10/25GbE | NIC and host throughput |
| Synchronized cameras | Trigger / PTP | Clock accuracy + acquisition timing |
| Camera bursts cause packet loss | Bandwidth shaping / packet delay / faster uplink | Lost packet counters + queues |
| Mixed vision + control Ethernet | Separate networks first; TSN if convergence is required | Timing under worst-case load |
| Servo / high-speed motion | EtherCAT / appropriate motion network | Measured cycle time + jitter |
| AGV/BMS/sensor network | CAN/CAN FD | Termination + isolation + Linux/driver support |
| 25/100GbE+ imaging | GigE Vision 3.0 / RDMA evaluation | PCIe + memory + NIC + switch + GPU path |
20 · Hardware
Selecting the machine vision industrial PC
The network is only one part of the machine vision computer. For multi-camera industrial AI, also evaluate:
CPURAM channels & capacityGPU / NPUPCIe lane availability2.5/10/25GbE interfacesPoE requirementUSB3 Vision interfacesFrame grabber expansionNVMe write bandwidthIsolated DIOWatchdog24V / wide-voltage powerOperating temperatureLifecycle & BOM control
A machine vision PC that receives eight cameras, writes image data and performs TensorRT inference may fail because of memory, storage or thermal limits even when the Ethernet architecture is correct.
Matched BITECH platforms
8× 2.5GbE · -20 to +60°C
Dedicated camera-to-port mapping for multi-camera cells on the factory floor.
View AX-320BT →
6× 2.5GbE + 4× 10G SFP
VLAN segmentation and 10G uplinks to MES and storage in cabinets and racks.
View AX-340BT →
4× GbE · Intel AMT · dual CAN
Separate camera, PLC and uplink networks with out-of-band management.
View AX-134BT →
PCIe 3.0 x4 · dual isolated CAN
Add a 10GbE NIC, frame grabber or GPU when onboard ports are not enough.
View AX-660EBT →
Go deeper
Solution
Machine Vision & AOI Computing
Application-level platforms for inspection and multi-camera vision.
Explore →
Products
Multi-LAN fanless x86 platforms for camera aggregation and control.
View range →
Products
RK3588, Jetson and RTX MXM platforms for vision inference.
View range →
21 · Checklist
Machine vision network validation checklist
Before releasing a machine vision network architecture, verify the exact deployment.
Camera
- Model
- Quantity
- Resolution
- Bit depth
- Pixel format
- Frame rate
- Trigger mode
- Packet size
- Peak bandwidth
- Resend behavior
- Synchronization method
Network
- NIC controller
- Port speed
- Switch model
- Switch fabric capacity
- Uplink speed
- LACP hash policy
- MTU
- Receive buffers
- Packet delay
- PTP / gPTP
- TSN features if used
Host
- CPU utilization
- PCIe topology
- Memory bandwidth
- GPU transfer path
- Storage write throughput
- Interrupt behavior
- Driver
- OS / kernel
- Thermal limits
Validation
- Packet loss
- Incomplete frames
- Packet resend count
- CPU utilization
- NIC queue drops
- Switch queue drops
- Timestamp offset
- Sustained full-load test
- Link-failure behavior
- Restart / recovery behavior
Validate the final architecture under the worst simultaneous load, not only with one camera running.
22 · Field patterns
Real-world machine vision network failure patterns worth testing
“Average bandwidth looks fine, but frames still drop”
Likely causes
Simultaneous camera bursts; insufficient uplink; receive-queue overflow
Test
Synchronized triggers; peak packet rate; per-port switch statistics
“Jumbo frames are enabled, but acquisition is unstable”
Likely causes
One device in the path does not support the selected MTU; NIC buffer behavior; switch configuration
Test
Fall back to 1500-byte MTU; validate each hop; increase packet size incrementally
“Frame rate drops when AI inference starts”
Likely causes
CPU starvation; memory contention; interrupt processing; storage load
Test
Acquisition-only baseline; inference-only baseline; simultaneous acquisition + inference + recording
“Adding a second or third camera suddenly causes failures”
Likely causes
Burst overlap; switch uplink saturation; camera bandwidth not shaped
Test
Add cameras one at a time; reduce DesiredPeakBandwidth / add inter-packet delay; compare dedicated NIC vs shared switch
The most useful machine vision benchmark is often not the maximum camera count. It is the maximum camera count under the actual full application workload with zero unacceptable frame loss.
Glossary
Key terms: GigE Vision, LACP, TSN and RDMA
- GigE Vision
- A machine vision camera interface standard from A3 for transporting images and controlling cameras over Ethernet.
- GVSP
- GigE Vision Streaming Protocol, the established UDP-based image streaming protocol used by GigE Vision cameras.
- GVRSP
- GigE Vision RDMA Streaming Protocol, added in GigE Vision 3.0 to stream images over RoCEv2.
- RoCEv2
- RDMA over Converged Ethernet version 2, which lets a NIC place data directly into host memory with little CPU involvement.
- LACP
- Link Aggregation Control Protocol (IEEE 802.1AX) for combining physical links into one logical link; one flow normally uses one member link.
- TSN
- Time-Sensitive Networking, a family of IEEE 802.1 mechanisms for time synchronization, scheduling, shaping and reliability on Ethernet.
- PTP / gPTP
- IEEE 1588 Precision Time Protocol and its TSN profile IEEE 802.1AS, used to align clocks and timestamps across devices.
- IEC/IEEE 60802
- The 2026 TSN profile for industrial automation that selects the features and defaults bridges and end stations should use.
- Jumbo frame
- An Ethernet frame larger than the standard 1500-byte MTU, often around 9000 bytes, that every hop in the path must support.
- Stream Channel Packet Delay
- A camera setting that inserts delay between image packets to limit peak bandwidth and avoid burst overlap.
FAQ
Industrial Ethernet for machine vision: frequently asked questions
Can LACP combine four 2.5GbE ports into one 10Gbps camera connection?
No. A 4×2.5GbE LACP group can provide approximately 10Gbps of aggregate link capacity across multiple flows, but one connection normally remains limited to one member link. If one individual camera stream needs more than 2.5Gbps, use a faster physical interface such as 5/10/25GbE.
Is LACP the same as TSN?
No. LACP is primarily used for link aggregation, load distribution and resilience. TSN is a family of Ethernet mechanisms for time synchronization, traffic scheduling and bounded behavior of selected traffic classes. They solve different engineering problems.
How do I calculate GigE Vision bandwidth?
Start with Width × Height × Bits per Pixel × FPS, then add margin for protocol overhead, packet behavior, resends and the actual camera transfer pattern. For multi-camera systems, also evaluate peak burst traffic rather than only the average rate.
Why does a GigE Vision system lose packets when average bandwidth is below the NIC speed?
Because cameras can transmit images in bursts. Several cameras may simultaneously use close to their full physical link rates after exposure. If the shared uplink or receive queues cannot absorb the combined burst, packets can be dropped even though the long-term average is below the nominal link rate.
Should I enable jumbo frames for GigE Vision?
They can help reduce packet-processing overhead, but the entire path must support the selected MTU. Validate the camera, switch, NIC, driver and OS. If acquisition fails, testing again at 1500-byte MTU is a useful diagnostic step.
Should I use 4×2.5GbE LACP or 1×10GbE?
Use LACP when multiple independent flows need aggregate bandwidth and link resilience. Use 10GbE when you want a simpler high-speed uplink or when traffic distribution across LACP members is uncertain. For some machine vision systems, multiple dedicated 2.5GbE ports are easier to validate than either approach.
Does a TSN-capable NIC make an industrial PC TSN compliant?
No. TSN is an end-to-end network property. The NIC, driver, OS, switches, clocks, peer devices and application configuration must support the TSN functions required by the project.
What is IEC/IEEE 60802:2026?
It is the industrial automation profile for Time-Sensitive Networking published in June 2026. It defines selected features, options, configurations, defaults, protocols and procedures for bridges, end stations and LANs used in industrial automation.
What changed in GigE Vision 3.0?
GigE Vision 3.0 adds a new RDMA-based streaming option called GVRSP, using RoCEv2. The goal is to reduce host CPU involvement and memory-copy overhead while enabling very high-throughput imaging architectures. Existing GVSP-based systems remain relevant; GigE Vision 3.0 adds new capability rather than making every existing camera obsolete.
Do machine vision systems always need TSN?
No. Many systems work well with dedicated camera Ethernet, PTP or hardware triggers, and a separate EtherCAT motion network. TSN becomes especially interesting when multiple time-critical and best-effort traffic classes must share a converged Ethernet infrastructure.
Does CAN isolation make CAN deterministic or safety-rated?
No. Isolation improves electrical robustness against ground loops and common-mode disturbances. Determinism depends on the protocol, bus load, timing and system design. Functional safety requires separate safety analysis and appropriate safety-rated components.
Engineering review
Design the data path before choosing the port count
BITECH can review the complete camera → network → industrial PC → GPU → storage path and recommend the appropriate multi-LAN, 10GbE, PCIe, GPU and isolation architecture.
CameraNetworkIndustrial PCGPUStorage
A robust architecture starts with
- Camera quantity
- Resolution / bit depth / FPS
- Synchronized or free-running acquisition
- Switch topology and expected bursts
- PTP / TSN requirement
- AI inference and storage workload
- Motion-control interface
- Environmental conditions