lockclock

[Eric S. Raymond]

Hal Murray <hmurray at megapathdsl.net>:
> 
> Eric said:
> > Heh.  I've been pretty ruthless about dropping every line of code I could.
> > Did it occur to you to wonder why I hadn't already nuked this?
> 
> > It's because the only way this code makes any sense to me is if at one point
> > NIST was running NTP Classic on the master fountain clock. For all we know
> > they might still be doing that.
> 
> I expect the lockclock code is a partnership between Dave Mills and Judah 
> Levine at NIST.

I didn't have a name at the NIST end but, yeah, I was expecting something
like that.

> Suppose we split the client/server parts of ntpd.  We need some way to get 
> info from the client to the server.  I was assuming that pathway could handle 
> the lockclock case too.

You're advocating heroic measures - a major refactor - to address
something I very strongly doubt is an actual problem.  Recall that the
first set of hard figures we were able to get was these for a major
public server in Asia:

Sanjeev Gupta via devel <devel at ntpsec.org>:
> Interface is 100Mbps
> ntpsec is the only network service on the machine.  gpsd runs locally
> CPU load is under 3%
> Hardware is a dual-core Pentium 4, 2800MHz, from about 2006
> Network traffic is under 100kbps
> PPS is about 500/s, RX is 10% more than TX
> 
> Current client count is 18071

18K clients.  3% utilization.  On a 10-year-old 2.8Ghz system - that
probably means DDR2 latency at best.  We could expect that hardware to
easily handle an order of magnitude increase in client count without
saturating - linearly that would be 30% load but let's be
pessimistic/conservative and call it 50%.

Scaling up to a 3.5GHz processor I think we can expect a clean factor
of 12.5 improvement in client count for around the same 50%
utlization. That's 225K clients without even collecting on the
improvement in DRAM latency! Up to somewhere around 450K clients if
we're willing to let the processor run at peak load.

What this tells me is that NTP service even at NIST volume is *stupid
cheap* even on decade-old hardware.  And really, why would we expect
otherwise when the typical per-client load is one small packet at
intervals much longer than a second?

Under the circumstances, even *thinking* about performance-seeking refactors
seems like a misallocation of effort to me. There might be other reasons to
break the code into smaller pieces - reducing global complexity and attack
surface is what leaps to my mind - but speed isn't it.

If you want to persuade me otherwise, I'm going to see NIST load
figures that indicate a processor utilization at least an order of
magnitude higher than 3% on *current* hardware.  Otherwise the clear
minimax is for us to write a check to NIST for $500 with a note that
says "Here, kid, get yourself a real computer."

We have other problems.  Like NTS. And moving the whole suite to Go so we
can banish buffer overruns forever.  And eventually NTPv5.

> If we are serious about supporting lockclock, we have to figure out a way to 
> test it.  We can probably make something that supports GPSDOs with PPS.

That, on the other hand, seems to me like a good idea. But I don't have
the domain expertise to do it.
-- 
		<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.