Achim Gratz via devel <devel@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>
_______________________________________________
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
