🚀 go-pugleaf

Scott,

I concur with your feeling that the NCAR fuzzball should be protected from
cycle stealers as much as possible, but maybe you are missing something.
First, application-level services, including NTP, are run at the lowest
priority level in the multi-level scheduler, so that packet-forwarding
functions always take precedence. Furthermore, the memory allocations
are disjoint, so that even relatively large numbers of UDP users do
not impact the resources used by packet-forwarding functions.

Notwithstanding the above, I would very much recommend the use of the
backbone fuzzies to provide time service directly to their Ethernet
population simply to avoid those time-service packets transiting the
seriously overloaded backbone links to other time servers removed from
the backbone. As you know, the fuzzballs are carefully synchronized
to various radio clocks using their local-net routing protocol, so
there is no need for time-service packets between them or for timewatchers
to chime any but the nearest fuzzball as the ethernet flies.

What I think is a much more productive strategy is to suggest to your
timewatchers to avoid the urge to chime any particular fuzzball with
multiple hosts on the same network. Far better to chime with one host
using NTP and then redistribute time locally. It would seem that each
backbone fuzzball could serve as chimee for any or all the nets it
normally serves in its respective configuration. This would avoid
the chimepackets even coming near the overloaded serial lines.

Dave