Hal Murray via devel writes: > The current code is a combined client and server. I think we should split > that into separate programs. Maybe not right away, but we should at least > start thinking that way.
If you're going to give ntpd the djb treatment (ref. qmail) then that split is the most obvious one, but I suspect you shouldn't stop there. > The server side is simple. It gets time from the system. There are a few > other parameters that either need to come from the system (via ntp_adjtime?) > or from the server via shared memory or similar. That's been done already as a POC, written in Rust: https://github.com/mlichvar/rsntp > We should be able to run multi-threaded with only minimal changes. It would > need locks for updating various statistical counters. There are probably > others, but I can't think of them. > > We would probably want to restructure things a bit. For example, a thread > (or > several) would be associated with a socket rather than going through a layer. It seems that as with all multi-client IO-bound and latency sensitive code you should employ just enough CPU cores to be able to saturate the interface. Actually I think that most of the NTP server on a Linux box should be done by the kernel, optimally via XDP / eBPF programs. > The client is pretty much what we have. Just ignore the small amount of > server code. If we run it on another port, we can run it at the same time as > a server. There is most of what a client needs already in Go: https://github.com/google/gopacket/blob/master/layers/ntp.go A client not using this layer is here: https://github.com/beevik/ntp > I'm not sure what to do with ntpq. Most of what I use it for (peers, -p) is > talking to the client but the server would be listening on port 123. > > Anyway, I think that thinking about them as separate parts will help our > discussions. > We should be able to improve performance on busy servers. It's been decades since I looked at an NTP server that has enough clients to make me wonder about performance, so I'd like to see actual numbers for a busy NTP pool server w/ a fast connection for a baseline. Here's some code to test with synthetic load: https://github.com/mlichvar/ntpperf Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
