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

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

mills@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.
It's all ISDN and digital transfer in the Xchange?
( I get around 35/45 ms roundtrip delay via ISDN raw IP )

uwe

Uwe,

I checked NPL telephone and found it uses the * and # as per PTB. The 
exisitng driver code captures a timestamp at the beginning of the 
timecode message and at the * and # characters at the end. According to 
the NPL, the * or # is transmitted as the last character of the message, 
which is within one character (CR) of the first bit of the LF on-time 
event. However, the reported PTB timestamp is in error much more than that.

Question about the baud rate. NPL does not specify the baud rate; PTB 
specifies 1200 bps. At 1200 bps a 10-bit characgter takes 8.33 ms, so 
the 78-character message takes 650 ms. If the * or # was not found, the 
error would be near 650 ms; however, if it was found the error should 
depend only on the ISDN delay, which in your case is about the same 
here. In other words, the 51-ms error is probably due to the ISDN delay 
and the \\ scheme would compensate for that.

Dave

Uwe Klein wrote:
> mills@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.
> 
> It's all ISDN and digital transfer in the Xchange?
> ( I get around 35/45 ms roundtrip delay via ISDN raw IP )
> 
> uwe

Heiko,

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.

quote

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
  protocols

\quote

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);

Dave

mills@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

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

Ok, I found it. Gosh, do you know this situation, you tell your 
customers all day long to check their restriction settings and then find 
yourself running into exactly the same config error? Thank god its 
(almost) Friday and we are approaching a long weekend ..

Sorry to have bothered you,

kind regards,
Heiko



Heiko Gerstung schrieb:
> 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