Quote:
Originally Posted by DareDad
I worked as scorekeeper last year which meant that I was watching the bandwidth during matches. Last year, the stated limit was 7 megabits/sec. Very few teams reached that but there were several who went over 8 and one or two teams I saw that could suck down 20 Mbits/sec.
All other things being equal, even with 6 teams each consuming 20 Mbits/sec that shouldn't saturate the WiFi network. That much traffic would barely register as a blip at the Cisco box that's managing the routing. In all cases when I brought up excessive network usage, simply asking the team to adjust their camera settings brought the usage down. Just because your camera can transmit at 1080p 60fps doesn't mean that your display can even manage to show you that.
|
If adjusting their cameras to send less data is reducing the missing packet count the I propose team links are saturated.
The ideal bandwidth of a WiFi network does not apply in a situation where the robots are mobile (actually it doesn't usually apply in a situation where the radios are stationary either). The links actual bandwidth will change based on the ability of the radios to deliver the data.
The only way you can know for sure what the actual bandwidth to your radio is to try it and once you do with TCP you will hit the congestion control of the protocol which in many cases will magnify the saturation because the goal is reliable delivery not worrying about your link's issues. Now where are you going to try from and in what orientation to measure the bandwidth since the robots move around and are all constructed differently?
Order of falsehood: lies, statistics and datasheets.
Just because your Cisco/D-Link box says a bandwidth does not mean you have that bandwidth it's just a 'datasheet'.
It falls on the reader of the data sheet to understand the implications and criteria of that performance.
Also with respect to barely registering a blip. I own a police package Chevy Caprice LT1.
That car has a digital dashboard with three digits and a theoretical maximum display of 999MPH.
At 140MPH if the windows are open the car might catch air (there is a sticker on the dash board from GM).
At 180MPH you are playing with fire and I have been over 150MPH on a track with that car.
Just because the top of the scale is somewhere does not mean the scale represents realistic expectation.
This would be interesting:
Let's take some FIRST robots and drive them around using 2.4GHz like they are not on the field using on D-Link.
However these robots really will be on a field.
Let's put the another D-Link and DC/DC converter on 5GHz and drive these robots on the field.
Don't even worry about the FMS system.
Have a device on each of the 6 robots blast sequentially tagged UDP packets to the driver's stations over 5GHz.
Have a device on each of the 6 driver's stations blast sequentially tagged UDP packets to the robots over 5GHz.
Turn off the load balancing on the field and track to see how many of the packets you sent around you really got.
While all that is going on - drive the robots around.
Now there's no magic. No congestion control. Just raw bandwidth use as long as the devices are each capable of sending packets at a respectable rate and that can be easily tested by wiring them on a switch before hand.
So how many packets do you think will not survive this test?
Now change the packet payload in increments up the MTU for a few tests.
Graph the results and see how the network responds.
Let's make this even easier - start with an application like iperf on Linux (because it can pthread).
It could be a little more custom for this application but it already produces the sequence and the data.
Can probably graph the results with jperf or some VBA.