[time] More Aggressive Server Prunning Redux
Tue Feb 26 16:50:49 UTC 2008
Ah, perverse time, you have to love it. Interesting find. I can't get it
to answer any NTP monitoring queries, how did you get it to divulge an
upstream time source?
I think what's most interesting about this is we've found a case where
the pool's simple scoring mechanism isn't enough to identify an
obviously bad server. It's been serving lousy time for at least 4 days,
but decaying at a rate that it's score is still above the cutoff. Not
sure what the solution for that is. OTOH, it's only 300ms off. For
casual users who ask one server for the time, this one's close enough to
be useful. And for the time nerds who really care about < 100ms
accuracy, they're going to have multiple sources and hopefully will
ignore this turkey. So the damage isn't that bad.
PS: those are some ugly opentpd bugs you're talking about.
Dag-Erling Sm?rgrav wrote:
> John Pettitt <jpp at cloudview.com> writes:
>> wow - that's quite a slope on that line.
> If my math doesn't fail me, ~100 ms / day is 1.15 ppm - well within what
> you'd expect of an uncalibrated crystal oscillator.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the pool