Quote:
Originally Posted by Jaci
As I've discussed here, I feel that NetworkTables needs to change. Not only is it inefficient on the network, it's inefficient on the processor, both of which are royalties when we're talking about the RoboRIO and FRC's field bandwidth limit. I'd like to see everyone else's opinions on NetworkTables, and see if we can get it to change before next year's game.
Regards,
~Jaci R |
It has actually had a complete rewrite this summer. There is now a C++ library that all languages will use as the backend, instead of different implementations for the 3 official and many unofficial languages. It should be much better now.
I read through your blog as well. One thing is it doesn't send all messages every 100ms. It only sends a keep alive flag, and then any entries that have been updated.
In addition, there's a good reason why writes are limited to 100ms on a separate clock. Back in 2012, when the first implementation of NetworkTables was out, if I recall correctly there was no write limit, and it would write data as soon as you entered it to the table. This caused many more issues with lag, because teams would use SampleRobot, run the teleop loop as fast as possible, and then write to the SmartDashboard, which would bring code to a halt. By writing to a local store, and only updating the clients every 100 ms, you make sure even in that situation the robot will not start lagging. The time to write a new entry to the local store is orders of magnitude faster then writing to the network, so holding back data is the write option.
Anything written for FRC needs to be designed for teams with no programming experience or mentors to use. For many teams 100ms update times for the dashboard is more then fast enough, and if that helps reduce network and cpu load, which can make up for inefficient team code, its the far better choice.
Some of the powerhouse teams in FIRST do write their own communication code that runs faster, but those are also the teams that have the mentorship to do this. For 99% of FRC teams, you need something as simple and easy to use as NetworkTables and SmartDashboard.
Also, Cameras are a much bigger killer to the network then NetworkTables could even hope to be. At events, I've seen teams run probably 50 SmartDashboard variables, plus the Driver Station, and this only uses about 1.5 MBps of bandwith, whereas even a 320x240 camera uses close to 2 MBps.
One more thing is that NetworkTables really isn't designed for control packets, and shouldn't be. It should be designed for sending information. Robot control data like Joysticks through the DS are not sent using NT, and are heavily prioritized by the FMS and field networking system.