View Single Post
  #5   Spotlight this post!  
Unread 28-03-2014, 05:54
Greg McKaskle Greg McKaskle is offline
Registered User
FRC #2468 (Team NI & Appreciate)
 
Join Date: Apr 2008
Rookie Year: 2008
Location: Austin, TX
Posts: 4,752
Greg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond repute
Re: Real time versus normal timing

The SD writes do not immediately do TCP. They are already amortized. When you write to an SD variable, it needs to map the name to a storage location, update the storage locally, compare it to the current value to see if it is truly an update, and possibly mark it for replication. Every 100ms by default, the library accumulates the marked element and sends them to the other participants.

So, by all means, remove the elements you do not need to update, but I don't think you need to change things to make them hard to use.

As a test, you want to eliminate the overhead of synchronizing them by commenting out just the NT Server in Robot Main. Another test is to run it normally, but close your dashboard and other clients and see how much the CPU drops. This test will still include overhead of the local name lookup and local storage. When SD clients and servers aren't communicating, they still function al local storage, essentially late-binding globals, but they do no networking.

One other clarification -- the compressor start doesn't block, but the Compressor Control function has the loopy border, and will not return as long as the compressor refnums are still good. But Start just sets state and returns.

Greg McKaskle
Reply With Quote