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. > 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. 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. > Mind you, heroic measures are available. The simplest would be to > run with GC off by default and schedule times to perform a GC when it > can reasonably be expected not to collide with the next polling > action. I tend to organize timer triggered code in a way that any computations that take a long or indeterminate time happen after the time-critical section that uses either very short computations or precomputed values from the last period. That assumes that the resulting lag until the next timer invocation can be taken into account (which should usually be possible). So if things get organized like that, as long as whatever GC does is done until the next trigger would not matter at all. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf microQ V2.22R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
