[time] More Aggressive Server Prunning Redux

[Nelson Minar]

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.


http://www.pool.ntp.org/scores/63.240.161.99

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.
>
> DES
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://fortytwo.ch/mailman/pipermail/timekeepers/attachments/20080226/e26e241a/attachment.htm