> I said I'm curious, not worried. :) Is there any good method I can measure > this offset with higher accuracy? I know I know, a man with one clock knows > what time it is, a man with two clocks is never sure. But I want to be at > least hmm... a little convinced, maybe.
I suspect you are seeing asymmetries in network routing. If you know the network delays, you can measure the clock offset between two systems. If you know the clocks on both systems are accurate, you can measure the network delays. Of course, you don't really know the network delays and you aren't sure about the clocks on any of the systems. About the best you can do is to compare your system with several "good" systems and see how well it agrees. In this context, good means both an accurate clock and also a nearby and stable network connection. Do you like making graphs? ntpd can generate lots of statistics. Look in the monopt web page. Beware, it can be a time sink. If you watch the round trip time, most/many samples will be in a clump at the low end. (I'm assuming your link isn't overloaded.) Those are the good ones. Some will have longer times. Those are samples that were delayed behind other packets. ntpd does a pretty good job of filtering out the ones that get delayed. You can compare rawstats with peerstats to see if it's working right. In my case, it gets confused if I do a long download. My DSL line gets queuing delays up to several seconds. :) If you watch over days/weeks, you will probably see some jumps in the minimum/normal round trip times. Those correspond to a routing glitch somewhere between those two systems. -- These are my opinions, not necessarily my employer's. I hate spam. _______________________________________________ pool mailing list [email protected] http://lists.ntp.org/listinfo/pool
