5

I have a 100 Mbit switch connected to three 100 Mbit cameras and 100 Mbit computer. The bandwidth limitation comes from the cables in use and cannot be altered to solve the problem because i am working in an industrial/automotive enviroment.

                ┌------------ Camera
Computer-----Switch---------- Camera
                └------------ Camera

The cameras stream RTP via UDP. All cameras are configured to use constant bitrate with 24 Mbit/s each.

Taskmanager confirms that the expected bandwidth is used: enter image description here

When I run a Wireshark IO analysis I can see that while the average bandwidth is under 100 Mbits, there are spikes exceeding 100 Mbits, causing packet loss, and the stream not to be decodable. These spike come from the cameras which capture an image every 33 ms and send it. Then they stay silent until the next image is captured.

enter image description here

In the red box we can see the 100 Mbit limit is reached and packages are lost. We cant see that here but, RTP stream analysis shows it.

All cameras, and the switch support flow control (https://en.wikipedia.org/wiki/Ethernet_flow_control). I would expect the switch to use flow control to "smoosh" out network traffic, avoiding this problem.

  • Is my understanding of flow control wrong?
  • Is there a different mechanism that might help?

Altering the transport protocol from RTP to something else is not possible. Switching to Gigabit is not possible.

Denis Schaf
  • 153

1 Answers1

2

there are spikes exceeding 100 Mbits, causing packet loss

Yes, that is quite possible. To avoid, you'd require a gigabit link (next step greater than 300 Mbit/s) between the switch and the PC. Alternatively, you could use multiple links between switch and PC dedicated to specific cameras (especially using VLANs, but just IP subnet splitting would suffice).

I would expect the switch to use flow control to "smoosh" out network traffic, avoiding this problem.

Yes and no. The switch would try to throttle traffic from the source but would drop excess traffic all the same. The PC trying to throttle the switch is moot as the switch sees its egress capacity exceeded anyway. Whether pause frames actually work on the source, it is a real-time source and most likely cannot delay transmission. Run a test, I wouldn't put my money on it though.

You could get some relief by installing a switch with a larger buffer (at least with those low-bandwidth flows) - some queueing should improve traffic distribution, equalize burstiness and perhaps solve your problem. A rough calculation of the bursts: 60 Mbit/s * 40 ms * 3 = 0.9 MB as the minimum buffer capacity of the switch (port group) - not really much for a decent switch, but not always a given.

The better solution is to increase bandwidth between PC and switch as above.

Zac67
  • 5,130
  • 1
  • 13
  • 22