ntpd: program structure

[Achim Gratz]

Eric S. Raymond via devel writes:
> I have, unsurprisingly, spent a lot of time thinking about how to partition
> the existing code into smaller pieces.  I had a strong incentive; reducing
> global complexity would ipso facto choke off attack vectors.

Well, others have been at the same junction and came up with some ideas
that you can actually look at.  For instance PHK has split ntimed into
three binaries: client, refclock/master, delegate (serving clients from
a master), ostensibly so that each would have less LOC.

> Some of you may recall that my original project plan included a
> project named REFCLOCK - breaking up ntpd into a pure network service
> daemon talking to a local refclock manager.  This is a slightly
> different partitioning from Hal's proposal here, but raises many of
> the same design issues.
>
> The biggest problem with any attempt to break up ntpd into multiple
> separate programs is that it would almost necessarily force changes in
> the way NTP configuration works that would be (a) user-visible, and
> (b) not backward compatible.  The only ways around having such a
> configuration break I was able to think up were so complicated and
> ugly that they seemed like non-starters in themselves.

Again, if you DJB the whole thing, then interpreting the configuration
is just another low-privilege process that leaves some data around for
the other processes to pick up.

> Given what we believe about the conservatism of our current and
> potential userbase, a compatibility break in configuration would be a
> hell of a major cost and not to be undertaken without a really
> compelling reason.

It would be quite possible to keep a suitable interpretation of old
config files around, preferrably while providing guidance on how to
rewrite it.

> Then there is, as Hal notes, the fact that ntpq has a unitary
> client/server assumption built in.  I would not consider this a
> compelling strike against breaking up the ntpd monolith by itself;
> people sophisticated enough to use ntpq in anything other than
> peer-listing mode would also be sophisticated enough to understand
> whatever changes we made to it.  But it certainly adds to *our*
> expected complexity cost for breaking up the code in any significant
> way.

Whether ntpq communicates with a single process or several or maybe even
some sort of relay that gathers and scatters among multiple processes
doesn't really need to change the way it's going to present the result
to the user.

> Improving performance on busy servers is *not*, in my judgment, a
> compelling reason.  NTP simply doesn't load a modern processor very much; I
> know this from paying careful attemption to load averages on my RasPis
> and from profiling to locate hotspots in the code.  And if we want to
> reduce load, the low-hanging fruit is getting rid of the
> once-per-second tick handler.
>
> Enforcing separation of functions in order to harden the code would be
> a better reason. The reason that never happened is that the cost and
> payoff gradients changed as I was successfully ripping out 75% of the
> old code.  There are so few refclocks left that isolating them no longer
> looks like as big a win as it used to.

What you may be missing is that the whole "let's look at a bunch of
system on the internet and figure out what time it most likely is on
their side", i.e. the whole NTP client part (sans actually changing the
sytem time) can be treated like just another refclock.  You'd end up
with an architecture in which refclocks of any sort collect statistics
about time that the component that adjusts the system time is then using
without any need to care about how they've been obtained.  The server
component on the other hand just deals with requests from the net in
this architecture and only uses the time and quality information it gets
from the component dealing with the system time.  I think that such a
partition would also split nicely along the required capabilities.

> I think Hal's ideas about using multithreading are quite sound, but
> that C is not the language to do them in.  We've been kicking around
> the idea of a move to Go; better, I think, to defer more exploitation
> of multithreading until and unless we make that jump and the primitive
> set we have available is more tractable, less likely to introduce subtle
> defects.
>
> I've gone through several rounds of looking at the repartitioning
> problem, mentally trying different ways to carve ntpd apart, and every
> time around I've reached the same conclusion: it's too complicated to
> be worthwhile.

Well, even if you don't actually split it up into processes or threads
it is still a good idea to compartmentalize the separate concerns.

> On the other hand, I can also imagine how this might change.
>
> If we keep stripping down and simplifying the ntpd internals, we may
> reach a point at which the internal data flows between different
> pieces are so narrowly and clearly defined that the codebase begs to
> be carved apart into symbiont processes at the implied joints.
>
> I am keenly aware that part of my job as the sysarch is to *know if and
> when this happens* and to keep pushing us towards where it might.
>
> One such obvious cutpoint is the interface from the configuration
> parser to everything else.  If we could get all that packaged into a
> single context structure, eliminating all globals, some possibilities
> would open up.  In fact I'd have done this already if I hadn't judged it
> better to not do anything potentially destabilizing while we were waiting
> on Cisco.
>
> Actually I think the really hard part in any repartition is going to be
> prying the refclocks loose from the loopfilter code. *That* is a headache
> and a half, and eliminating the once-per-second tick in favor of a
> demand-paced request que should definitely happen sooner.

The loopfilter just needs the vetted time statistics and nothing else.
It doesn't care if it comes from a refclock or something else.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds