ntpq, refclocks

Hal Murray halmurray at sonic.net
Mon Jun 28 02:52:01 UTC 2021


Does anybody have any good ideas on a modern way to handle ntpq/mode 6?

Background...

We could split the server side out into a separate process.  That leaves a 
very tiny attack surface from the network.  I think I could do that now except 
for mode 6.

Does anybody have any good ideas on how to replace the current ntpq 
functionality?

Handwave.  My straw man would be to put all the counters into shared memory.  
Then a local-only version of ntpq seems reasonable.  If SSH isn't good enough, 
we could add a TCP or TLS wrapper.

I also want to be able to quickly add more counters.  That gets into a version 
control tangle.  Would it work to have 2 version numbers?  (maybe call them 
version and sub-version)  One for the base/stable counters and another for the 
new/experimental ones?  The idea is that the new ones get folded into the base 
at release time.


Similarly, it would be nice to split the refclocks out into a separate 
process.  We need something better than the current shared memory approach.  
Read only SHM would be OK for data, but we need a clean way to wake up the 
receiving side so it can process the data promptly.

More background...

I'd like to move the current kernel mode PLL to user space.  I think modern 
CPUs are fast enough for that to make sense.  I haven't done any 
experimentation.


-- 
These are my opinions.  I hate spam.





More information about the devel mailing list