Tim Lundström wrote on 13-9-2007 19:35: > The score history for my NTP server (81.216.247.88) is starting to > behave weird. Take a look at: http://www.pool.ntp.org/scores/81.216.247.88 > > The score start dropping about the same time every evening and recovers > for a short time during the night and then drops again until the morning > or early day. during the drops the offset varies between 100-150 ms. I > monitor the server performance from my work (different ISP) and it shows > no degradation or higher network latencies during the nights. Is this > strange behavior caused by network congestion somewhere between my > server and the pool monitoring server or could there be any other > explanation? Can I do anything to correct this? A few days ago I > monitored my server during a Turk Telecom spike with about 400 > requests/s and it showed only a small bump in the offset history. > > My server is a Intel 2.6 GHz CPU with 512 Mbyte RAM running Linux > (Fedora Core 4 with kernel 2.6.17) and NTPD 4.2.4p0. I use a Garmin > GPS18 LVC PPS-signal and the ntp servers at the internet exchange points > in Sweden as time sources (network latencies to the ntp-servers are in > the 2-15 ms range).
Hi Tim, I happened to read the explanation of the score routine (tiny link below the graphs: http://www.pool.ntp.org/scores/81.216.247.88#graph_explanation ) just before your mail came in, and I believe the explanation is there. The scoring algorithm gives penalties to servers with an offset of more than 100 millisec. Take a good look at the correlation between the score history and offset history graphs. Do you agree that this is what's happening? You describe that your server is not trampoleening like this and you suspect the network path between the monitoring system and your server. I agree. The monitoring system (x3.develooper.com, 63.251.223.163) seems to be in Pasadena, California, and your server (81.216.247.88) looks like somewhere in Sweden. Now that's quite a network path. I'm playing around with ntp for some years now, and in my experience ntp works fine over long distance, as long as the delay is symmetric. Congestion is unlikely at night, but think of a transatlantic link taken out at nighttime for maintenance. Consequently there is nothing one can do, except carefully shrug... This only demonstrates the limitations of monitoring over long distance. Well, that's in the explanation too. By the way, I'm a newbie in the pool, I added my server (82.95.234.3) yesterday after reading this list for a few months, and I survived my first Turkish spike (175 kb/s) this afternoon around 15:00 UTC :-) Hello pool members, nice to meet you! Looking forward to the good and bad things we will share. best regards, Jan Hoevers, Delft, the Netherlands. _______________________________________________ timekeepers mailing list [email protected] https://fortytwo.ch/mailman/cgi-bin/listinfo/timekeepers
