Quote:
Originally Posted by Alan Anderson
During the past two years, the "saturation" issues I have seen have never been shown to be due to WiFi bandwidth limitations. In every case where I watched a dropped-packet problem being fixed by reducing camera frame rate and/or pixel count, it was because the computer running the Driver Station program was unable to keep up with the incoming packets. The packets themselves were obviously being delivered just fine by the network.
In my experience, the CPU usage of the Driver Station computer is more important to the performance of the robot than the bandwidth usage of the WiFi network.
|
I have seen Intel Core I7 laptops have this problem.
In my ISP days such readily available CPU would be considered crazy powerful.
I've had whole ATM backbones running with proper interfaces saturating
DS3 with less CPU.
I've had the Windows performance counters on these laptops open before and not seen such an indication but via WMI all of that data can be logged into the DS log viewer if one wants. There are plenty of PowerShell examples around for this and via .NET there are plenty of MSDN examples. I do stuff like that all the time on enterprise networks.
Also if this was the case why do these teams often not experience this issue when tethered or in their private networks?
Then there's the before and after Einstein to consider. Before you could pump data as hard as you pretty much liked till something refused. Now the load balancing will cap you before you can do that and potentially steal opportunity from other teams to use the network. So in theory if teams could use a combined 20Mb/s before over the field why are these laptops so pegged now that they are capped at less?
I think these might be relevant:
DAP-1522 performance test from IEEE
CISCO 1250 performance test from TI