Folkert van Heusden wrote:
Hi,
I've heard that NTP acts funny when it tries to sync over an ADSL line.
That seems to be the case indeed:
0 [EMAIL PROTECTED]:/home/folkert/www$ ntpq -c pe
remote refid st t when poll reach delay offset jitter
==============================================================================
GENERIC(0) .DCFa. 0 l 23 64 3 0.000 -17.386 26.356
<- dcf77 receiver
-keetweej.intran 130.149.17.8 2 u 810 1024 376 0.735 2.724 0.084
<- other server on my lan
<snip>
And there it is: 20ms offset. From what I've heard this is caused by
ADSL being asymetric.
Now I was wondering, can't this be fixed by telling the NTP daemon how
much asynchronous the line is? I mean: it can be easily measured what
the down- and upload bandwidth is.
I have a similar problem. I have a GPS reference clock. The network
servers I use as backup and sanity checks each have a unique systematic
offset from my GPS. These offsets range from +2 to +5 milliseconds.
There is clearly more going on here than mere asymmetry in my broadband
cable. There is no way to compensate for such a systematic offset on a
server by server basis. I would really like to see a new feature in
ntpd that would allow me to correct for these offsets. Without it, my
local clock is going to get jerked around every time a new
synchronization source is selected.
Even after allowing for the systematic offsets, it's also clear that
some of the servers out there in netland have serious problems of their
own! One of the servers I use is a true jewel; it agrees with GPS quite
closely showing only a +2 millisecond offset. It's as solid as a rock,
day in and day out. Of the others, perhaps the less said, the better;
I'm glad that I seldom need to rely on them.
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions
