Dumb ntpd server
Eric S. Raymond
esr at thyrsus.com
Sun Nov 5 04:58:45 UTC 2017
Hal Murray <hmurray at megapathdsl.net>:
> >> Write a dumb NTP server in Go. The idea is to move ntpd
> >> to a different port number so the new code can answer
> >> client requests. This assumes that a server can get all the
> >> info it needs from the kernel. That may be bogus, but
> >> I think it's worth a try. We could write similar code in
> >> c and compare performance.
> > Don't we already *have* similar code in C, namely ntpd itself? I guess I'm
> > not grasping what you mean by "dumb".
> The main idea is to develop a high performance server. That means a thread
> per CPU. I'm happy working with lots of threads, but the current ntpd code
> is not setup to help with that.
> My strawman dumb server would have none of the ntpd complexity. If we can
> get everything from the kernel, it's only a page or two. Then we can add
> crypto and the mrulist statistics.
What you say sounds like it would be very interesting if I understood your
assumptions. I don't. How do we get from 65KLOC to a page if it's
doing the Byzantine-algorithm thing on multiple peers and clock sources?.
> > I don't think the Go/C performance difference will matter under *any*
> > plausible scenario, not given what I've read about Go oerformance and
> > reasonable inferences about how its internals work.
> Sounds good. Measuring is half an excuse to make some simple tools to
> measure things so we can see where the cycles are going and get actual
> measurements on how many packets per second we can support.
> Besides, Trust but verify. This seems like a good test case.
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.
More information about the devel