[ntp:questions] ACTS: client does not accept acts synchronized server

Heiko Gerstung heiko.removethistext.gerstung at meinberg.de
Thu Apr 26 08:44:08 UTC 2007


Dave,

again: thanks for your support. I would not have a big problem with the 
51ms offset, since this is pretty static and could be fudge'd to stay 
below 15ms. It might be a delay due to ISDN / phone network 
infrastructure issues.

The one thing I wonder about is why the ntpd on my PC does not accept 
any replies from this ACTS synchronized server (stratum is reported as 
16, reach stays 0).

At the moment I do not care for the calling costs, that is why I use 
shorter call intervalls (if you try to test this and it start with only 
calling every  hour or so, this takes too much time).

I would like to sort out the problem that my client ntpd seems to 
completely reject this server even if it considers itself being 
synchronized to acts (* tally code), advertises stratum 0 and has a 
reach of 377.

Here is the tcpdump content from a server reply:
User Datagram Protocol, Src Port: ntp (123), Dst Port: ntp (123)
Network Time Protocol
     Flags: 0x24
         00.. .... = Leap Indicator: no warning (0)
         ..10 0... = Version number: NTP Version 4 (4)
         .... .100 = Mode: server (4)
     Peer Clock Stratum: primary reference (1)
     Peer Polling Interval: 6 (64 sec)
     Peer Clock Precision: 0,000002 sec
     Root Delay:    0,0000 sec
     Root Dispersion:    0,0115 sec
     Reference Clock ID: PTB (Germany) modem service
     Reference Clock Update Time: Apr 26, 2007 08:38:00,1376 UTC
     Originate Time Stamp: Apr 26, 2007 08:38:57,2209 UTC
     Receive Time Stamp: Apr 26, 2007 08:38:57,1766 UTC
     Transmit Time Stamp: Apr 26, 2007 08:38:57,1831 UTC

Does not look too bad for me, but I might be just blind :-)

Best Regards,
Heiko


mills at udel.edu schrieb:
> Heiko,
> 
> While this has nothing to do with the second server you cite, the 51-ms 
> discrepancy between the PTB and GPS time is rather large. Either the 
> telephone or modem delay is unexpectedly large or the timecode timestamp 
> is at the wrong on-time character.
> 
> Also, I see the PTB polling interval is 1024 s, which leads me to 
> suspect you have not specified minpoll 12 maxpoll 17. Assuming you pay 
> for telephone calls, the poll interval should quickly climb over 1024 s 
> and ramp up to 36 h eventually.
> 
> Also, it is advised that when starting for the first time, remove the 
> frequency file. This causes ntpd to initially estimate the frequency 
> directly, then switch to tracking mode. This dramatically reduces the 
> time to converge the frequency estimate and increase the poll interval.
> 
> As I have no way to test the driver with European formats, I welcome 
> advice on how to determine the on-time character or event.
> 
> Dave
> 
> Heiko Gerstung wrote:
> 
>> Hi!
>>
>> Despite the fact that my ACTS synchronized time server seems to be 
>> working fine, my client does not accept it.
>>
>> Any other parameters I have to change?
>>
>> "ntpq -p" on server
>> (the GPS/PPS sources are noselect and only used for measuring the 
>> accuracy of the ACTS source)
>>
>>      remote           refid      st t when poll reach   delay   offset 
>>  jitter
>> ============================================================================== 
>>
>>  server          .INIT.          16 l    - 1024    0    0.000    
>> 0.000   0.000
>>  GENERIC(0)      .GPS.            0 l    5   64  377    0.000   
>> 47.289   0.391
>>  PPS(0)          .PPS.            0 l   36   64  377    0.000   
>> 47.228   0.341
>> *ACTS_MODEM(1)   .PTB.            0 l  127 1024  377    0.000   -4.530 
>>  4.289
>>
>>
>> "ntpq -p" on client
>> (the server is the second association)
>>
>>      remote           refid      st t when poll reach   delay   offset 
>>  jitter
>> ============================================================================== 
>>
>> *gateway.py.mein .GPSi.           1 u    3   64  377    0.131    3.278 
>>  0.042
>>  rsvd-heiko-229. .INIT.          16 u   50 1024    0    0.000    
>> 0.000   0.000
>>
>>
>> Best Regards,
>> Heiko




More information about the questions mailing list