> Clearly I need to fudge a time offset for the gps, corresponding to > mean hardware and os delays. My goodish servers are showing offsets of > between -6ms -- +4ms and it is unclear which one I should choose as a > base: this approach may not even be sensible. It may well be that I > must be content with accuracy of around the ms level, even though the > gps is potentially 100 times more accurate.
I'm not sure you need to fudge anything. > This must be a common problem. Where do I go from here? Turn on the statistics collection and make some graphs. loopstats shows you ntpd's view of your local clock. peerstats shows you ntpd's view of the servers you are using. I use an awk script to split peerstats into a file per server. >From the loopstats, graph offset, jitter, and drift. On a good system, drift tracks temperature. >From the peerstats info, I make 2 graphs per server. One is offset and rtt vs time. If the offset and rtt step in sync that's probably showing changes in the network load between you and the server. The other graph is offset vs rtt. It should be a big wedge pointing left. The blob at the left point is what happens with no network load. It should be small if your clock and the server clock are both good. Points along the edges of the wedge are due to network load - top is one direction, bottom is the other direction. Points in between the top/bottom edges are network load in both directions. Sometimes it's interesting to overlay offset from several sources. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam. _______________________________________________ timekeepers mailing list [email protected] https://fortytwo.ch/mailman/cgi-bin/listinfo/timekeepers
