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

mills at udel.edu mills at udel.edu
Wed Apr 25 17:31:51 UTC 2007


In trying to track down the 51-ms discrepancy, I stunbled on 
http://www.heret.de/radioclock/ptb.htm#K5. Apparently, PTB does 
something similar to NIST. It can measure and correct for the 
propagation delay. However, while the NIST correction is automatic, the 
PTB correction must be enabled by a special sequence, as quoted below.


The communication parameters are: CCITT-V.22 modem, 1200 baud, 8 ASCII 
data bits, one stop bit, no parity. The change from CR (carriage return) 
to LF (line feed) indicates the beginning of each transmitted second. 
The information transmitted before this time marker (leading edge of the 
start bit of the LF) refers to the next
following second.

In order to correct for the propagation delay time, the code 
transmission is stopped by the command "//" (two slashes), the incoming 
CR-LF time markers are echoed back, and the time code generator is set 
by the command "GDM" (do generator delay time measurements) into the GDM 
mode. In this mode, the time code generator measures 8 round-loop 
delays, calculates the mean value and the standard deviation and 
advances the time marker for half the mean value determined. If the GDM 
has been successful, the visible time marker will change from "*" to "#".

The result of the delay time determination is reported in the time


It is not clear that services other than PTB have this feature. The code 
now echoes all timecode characters by default. It would be easy to 
transmit the // characters on initial startup. To do so, after line 408 
in the driver code refclock_acts.c add the line

	write(pp->io.fd, "\\", 2);


mills at udel.edu wrote:
> 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