Using Go for NTPsec

[Eric S. Raymond]

Achim Gratz via devel <devel at ntpsec.org>:
> Eric S. Raymond via devel writes:
> > Talk to me about what you think the effect of very occasional
> > stop-the-world pauses of 600 microseconds or less would be on sync
> > accuracy. By "very occasionally" let's say once every ten minutes or
> > so, that being what I think is a *very* pessimistic estimate of GC
> > frequency for a program with NTP's memory-usage pattern.
> 
> It's hard to say what that will look like without having an actual
> statistics.  The trouble with stalls is that they introduce bias since
> they alway shift in the same direction.  Once every ten minutes would
> likely not make much of a difference for most systems even if you could
> not filter these events out.

That was my estimation.  It ceretainly is *not* the case that
occasuinal 600-microsecond stalls would cause a 600-microsecond
degradation in typical accuracy; rather, that would be a highly
unlikely upper bound on the loss.

> > What I want to understand - and have others understand - is whether
> > pauses of that size and frequency would mess with sync accuracy
> > enough that heroic measures are required to avoid them.  What kind
> > of distortion would they introduce in comparison with other
> > components of the error budget?
> 
> NTP already filters out values that fall out of the ordinary statistic.

Good point.  It's quite possible that samples distorted by
stop-the-world pauses would usually be thrown out by normal filtering!
Ironically this becomes less likely as GC times drop.

> For the control loop I tend to think that eventually it would make sense
> to drop the assumption of a regular interval at which the control
> interventions happen.

One of the things that's likely to happen if we move to Go is that
control-event scheduling becomes a forever-loop shipping wakeup
notifications to a channel. Each channel read would then start a
worker thread to do whatever the intervention requires.  In C this
would be brain-melting; in Go it's a few lines of simple code.

Once we have this kind of organization, dispensing with the
regularity assumption won't even be difficult.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>