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 > thegateap.intra .STEP. 16 u - 1024 0 0.000 0.000 > 4000.00 <- other server on my lan > +auth1.xs4all.nl 131.188.3.220 2 u 973 1024 377 8.421 1.179 > 0.024 <- ntp server of my ISP > -ntp1.nl.uu.net .GPS. 1 u 943 1024 377 19.800 4.600 2.127 > +ntp3-rz.rrze.un .DCFp. 1 u 837 1024 377 29.495 0.022 0.091 > *sombrero.cs.tu- .PPS. 1 u 856 1024 377 30.856 1.031 0.530 > +chime1.surfnet. .GPS. 1 u 757 1024 377 13.889 2.078 0.005 > chime2.surfnet. .STEP. 16 u - 1024 0 0.000 0.000 4000.00 > > 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. > >
My experience is that ADSL causes much smaller than 20ms delays. If you do the math for NTP packets which take two ATM frames you'll find it comes out to between 1 and 2 ms depending on how fast and how asymmetrical your line is (mine is 6000/608 yielding 1.281 ms offset). Unless your line is very odd the 20ms your are seeing is far more likely to be from having the wrong propagation delay in the DFC77 driver. Patching for the ADSL offset is not as easy as it sounds. If you just want to appear to be in sync you could fudge the local refclock. However to have the local time correct you'd need to apply an offset to the timestamps to/from all non-local servers. This gets much more complicated when you consider the fact that the path to and from most servers is also asymmetrical in ways you can't reasonably factor out. After a lot of experimenting on my part I decided to give up on factoring out the DSL offset and live with the slight perceived error. john _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
