Dumb ntpd server

[Eric S. Raymond]

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.

Agreed.
-- 
		<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.