[ntp:questions] Re: ntp & adsl

John Pettitt jpp at cloudview.com
Mon Jan 30 22:18:06 UTC 2006


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 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 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




More information about the questions mailing list