On 22-09-07 15:18, Guillaume Filion wrote: > It seems that my local server is wrong by a few ms, and when I look at > ntpq it's fairly obvious that the selection algorighm selected a server
The reference NTPd has some special thoughts about measurement and errors implemented that makes it less obvious to NTPd. By looking at the (not so clear) documentation some time ago, I got the impression that NTPd is more concerned about servers providing you wrong time on purpose than eliminating normal distributed measurement errors. But that's just my opinion. > that is off by 8 ms. I added another statum 1 server (204.123.2.5) but > ntpd insists on choosing the one that is 8 ms off. > > Any idea what's going on? I'm wondering if there's something basic that > I don't understand in the algorithm. > > [EMAIL PROTECTED]:~$ ntpq -pn > remote refid st [...] delay offset jitter > ================================================================== > -132.214.200.120 18.26.4.105 2 [...] 20.217 -5.729 0.877 > +132.246.168.164 132.246.168.2 2 [...] 16.983 -5.172 0.058 > *208.184.49.9 .ACTS. 1 [...] 41.468 4.369 0.477 > +204.123.2.5 .GPS. 1 [...] 99.864 -4.133 0.098 > 127.127.1.0 .LOCL. 13 [...] 0.000 0.000 0.001 > 192.168.0.255 .BCST. 16 [...] 0.000 0.000 0.001 > 10.10.16.255 .BCST. 16 [...] 0.000 0.000 0.001 IIRC: besides offset the algo takes the total round trip to the 'ultimate' source into account (look at rootdelay in output from "ntpq -c rv"). The selected st1 server has low delay compared to 204.x.x.x. I'm not sure how it uses the stratum and other parameters in voting. Arnold _______________________________________________ timekeepers mailing list [email protected] https://fortytwo.ch/mailman/cgi-bin/listinfo/timekeepers
