Open brettle opened 5 months ago
The rate restriction is there to prevent overloading the wifi at events. We do not want to provide a standard way to bypass it. I would be open to figuring out a behind the scenes way that turns it off for non-Rio (eg simulation) NT servers (this could be done with an ifdef).
Ok to just ifdef the existing flush()
or do you want a separate flushNow()
?
Actually, I'd need it not just for servers, but clients as well. Is there an acceptable/recommended way that the client could determine that it is talking to a non-RIO server?
@PeterJohnson we could use really-flush-immediately too, because we use NT for perishable coprocessor-to-rio data, and we trust the coprocessors to manage their own rates. we completely don't care about wifi. is there a standard way to do immediate client flushes like that?
You can immediately client flush, but it’s rate limited. Are you really sending data updates from coprocessors more often than every 5 ms?
no, we're really only concerned with latency, which is already pretty high, so it if were easy to save a few ms, that would be good.
So if you call NetworkTableInstance.Flush(), it will immediately flush to network, assuming it’s been at least 5 ms since the last time the network transmit happened.
ohhhh. we'll try that.
Is your feature request related to a problem? Please describe. I'm using NetworkTables to step an external simulator. NetworkTables' current 5ms minimum between flushes to the network is the current bottleneck on the simulation frame rate.
Describe the solution you'd like
instance.flushNow()
(or something similar) should immediately writes any pending messages to the network.Describe alternatives you've considered We previously used HAL sim websockets instead of NetworkTables but it had issues when used in conjunction with
SimHooks.stepTiming()
.We could use an entirely separate communications channel, but since we are already using both NetworkTables and HAL sim websockets, that seems like overkill.
Additional context I do realize that this would not in and of itself ensure that the messages from one client are immediately relayed to other clients, but that is acceptable for my use case (just one client and one server), and if someone needs that capability I think they could add a listener on the server that calls
flushNow()
whenever a new value arrives (maybe?).Would a PR that implements
flushNow()
(with suitable warnings in the documentation to avoid abusing it) be considered?