[ntp:questions] Re: Asymmetric lines

Richard B. Gilbert rgilbert88 at comcast.net
Sat Feb 5 03:48:57 UTC 2005


John Pettitt wrote:

>
>
> Richard B. Gilbert wrote:
>
>> John Pettitt wrote:
>>
>>>
>>> Hi all
>>>    I just put up a stratum 1 server (FreeBSD using the GPS18 with 
>>> PPS) on the end of a very asymmetric line (6000 kbps down 608 kbps 
>>> up).   When I look on the local machine 
>>> (gatekeeper.no-such-agency.net) I see this:
>>>
>>> ntpq> pe
>>>     remote           refid      st t when poll reach   delay   
>>> offset  jitter
>>> ============================================================================== 
>>>
>>> *GPS_NMEA(0)     .GPS.            0 l    8   16  377    0.000    
>>> 0.003   0.002
>>> LOCAL(0)        73.78.73.84      5 l    1   64  377    0.000    
>>> 0.000   0.002
>>> +[stratum1-a]    .GPS.            1 u   29   64  377   21.147    
>>> 2.068   9.112
>>> +[stratum2-b]    .CDMA.           1 u   51   64  377   17.442    
>>> 2.019   6.896
>>> +time.sr.sonic.n 63.192.96.10     2 u   37   64  377   10.896    
>>> 0.891   0.579
>>>
>>>
>>> note: names of the stratum 1 servers edited
>>>
>>> However when I look from one of my other boxes 
>>> (eschelon.no-such-agency.net in a server farm connected by multiple 
>>> OC12's) I see
>>>
>>> ntpq> pe
>>>     remote           refid      st t when poll reach   delay   
>>> offset  jitter
>>> ============================================================================== 
>>>
>>> LOCAL(0)        73.78.73.84      5 l   57   64  377    0.000    
>>> 0.000   0.002
>>> *gatekeeper.no-s .GPS.            1 u  777 1024  377   21.392   
>>> -1.933   0.098  <- my S1 server
>>> +[stratum1-a]    .GPS.            1 u  791 1024  377    7.456   
>>> -1.524   0.421
>>> +[stratum1-b]    .CDMA.           1 u  789 1024  377    3.446   
>>> -1.171   0.216
>>>
>>>
>>> Again the names of the stratum 1's edited but they are the same 
>>> servers as above.
>>>
>>> So I'm seeing a 2ms offset on the box itself and about 600ms from 
>>> the outside world.     I probably wouldn't care about this except 
>>> that the offset seems to be stopping ntpd on my S1 from backing off 
>>> it's poll intervals (it's been stuck at 64 for 12 hours).
>>>
>>> I seem to recall an asymmetric fudge patch being discussed but I 
>>> can't find it.  Does anybody have a copy?  (or other suggestions for 
>>> tweaking the setup)
>>>
>>> John
>>> P.S. both gatekeeper and eschelon are part of pool.ntp.org
>>
>>
>>
>> I don't see the 600ms!   Gatekeeper differs from its reference clock 
>> by 3 microseconds and from its upstream network servers by  1 -- 2 
>> milliseconds.   Eschelon is seeing a -1.9 millisecond offset from 
>> gatekeeper and -1 to -1.5 millisecond offsets from its upstream 
>> networks servers.   What am I missing?
>>
> Typo 600us not 600ms - (it's been one of those days) - the 600us being 
> as viewed from Eschelon - I guess I'm just being pick but it would be 
> really nice if my S1 actually matched everybody elses :)
>
> John
>
Your numbers look pretty good to me!  I don't think it's realistic to 
expect less than 600us error over a network link, particularly a WAN 
link!   Have a look, for example, at time-a.nist.gov and 
time-b.nist.gov.   Two stratum 1 servers at the same site, over the same 
or similar network links probably do not agree with each other by the 
time  the signals get to your site.  Part of the problem is that the 
whole bleeping world is climbing all over those two servers and they are 
usually staggering.   Another part of the problem is the vagaries of 
network propagation; you are not guaranteed a "clear channel" from here 
to there and back nor are you guaranteed the same path going and 
coming.  You are not even guaranteed the same path right now as the path 
you had ten minutes ago.  You are not guaranteed that a packet will 
reach its destination or that the reply will ever reach you!    It's a 
small miracle that it works as well as it does!



More information about the questions mailing list