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