On Aug 16, 2005, at 6:48 AM, [EMAIL PROTECTED] wrote:
This thread brought up a few separate issues; I'll reply to them
individually.
I looked carefully at the logs from the monitoring over the last
couple of months and adjusted the scoring algorithm a little. It's now:
If the offset is < 0.1s then the score is adjusted + 1. (before this
limit was 0.5s)
If the offset is between 0.1s and 1.5s the score is adjusted ($offset
* -2 + 1).
If the offset is > 1.5s then -2
If the offset is > 3s then -4
If the server is unreachable then -5
(Remember, the score is adjusted down 5% at each measurement).
I'll consider making the limit tighter than 100ms (or have the
penalties get harsher faster) after watching the patterns for a
little longer (that's why I added the offset RRD graph). In
particular of course if we can get ntpd working as a monitoring
system again.
Also, keep in mind that this is monitored with a very unsophisticated
client and network lag and such have an impact too.
As Wayne said: The accuracy is relatively unimportant right now
compared to making sure we have enough servers. I'm worried that if
we don't add servers fast enough the traffic will increase and start
pushing servers out... (it's already happening, but slowly). SNTP
clients should be "good enough" even with a 100ms or 300ms offset and
properly configured ntpds will throw out the less accurate servers.
- ask
--
http://askask.com/ - http://develooper.com/
_______________________________________________
timekeepers mailing list
[email protected]
https://fortytwo.ch/mailman/cgi-bin/listinfo/timekeepers
