Re: ACTS: client does not accept acts synchronized server

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@xxxxxxxx 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
.

Relevant Pages