[ntp:questions] Re: ntp & adsl
jpp at cloudview.com
Mon Jan 30 22:18:06 UTC 2006
Folkert van Heusden wrote:
> I've heard that NTP acts funny when it tries to sync over an ADSL line.
> That seems to be the case indeed:
> 0 root at muur:/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 126.96.36.199 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 188.8.131.52 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.
More information about the questions