[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