[ntp:questions] Time server question

Chris xxx.syseng.yyy at gfsys.co.uk
Wed Jul 17 11:48:17 UTC 2019


On 07/13/19 16:38, Chris wrote:
> On 06/20/19 23:39, Chris wrote:
>> Have a couple of surplus gps based ntp servers that have been
>> used for time sync in the lab for few years. They are on a UPS
>> with several hours backup and seems like a good idea to use
>> them to contribute to the ntp global network.
>>
>> Don't want to expose them directly to the net, so plan to
>> isolate them, either via a Solaris zone or
>> FreeBSD jail. This will have 2 network interfaces, ntp subnet
>> facing and the other to internet via the firewall. The ntp
>> side will run ntp client, internet side runs ntp server.
>>
>> Question is, will such an intermediate machine degrade the
>> time served, or will it still be reported as a stratum 1
>> source. Seems a waste otherwise.
>>
>> ntpq -p currently reports:
>>
>> remote refid st t when poll reach delay offset disp
>> =============================================================
>> *chronos .GPS. 1 u 23 64 377 0.18 -0.018 0.03
>> +nts100 .GPS. 1 u 21 64 377 0.46 -0.071 0.08
>>
>> Thanks,
>>
>> Chris
>
> Got back to this project and have what seems to be at
> last partially working system. FreeBSD 12 on a minix
> mini pc with 2 network ports. Also 3 network ntp servers,
> collected over the years, each with a 1pps output.
>
> Rebuilt the kernel with the pps support and added the 1pps
> hardware wiring. The 1pps from a timeserver has a positive
> edge, which then goes to an rs232 converter, an inversion,
> which is then connected to the dcd line on the mini pc
> serial port, also an inversion, so the leading edge of the
> 1pps signal to the dcd line is a positive edge.
>
> Initially, was getting a false ticker flag on the 1pps, but
> did a bit more digging and found that at least one of the
> time sources needs to have the prefer keyword. Chose the
> .168 source,as that provides the 1 pps. Restart ntpd
> and get the following:
>
> remote refid st t when poll reach delay offset jitter
> =====================================================================
> oPPS(0) .PPS. 0 l 3 8 17 0.000 -0.993 0.316
> +192.9.200.167 .GPS. 1 u 31 64 1 5.131 4.095 1.533
> *192.9.200.168 .GPS. 1 u 30 64 1 0.174 4.467 0.475
> +192.9.200.169 .GPS. 1 u 29 64 1 0.516 4.242 0.583
> -ntp0.uk.uu.net .GPS. 1 u 32 64 1 33.061 9.896 0.248
>
> After 24 hours or so:
>
> remote refid st t when poll reach delay offset jitter
> =====================================================================
> oPPS(0) .PPS. 0 l 5 8 377 0.000 0.001 0.000
> +192.9.200.167 .GPS. 1 u 12 64 377 5.156 4.584 1.049
> *192.9.200.168 .GPS. 1 u 1 64 377 0.178 5.007 0.054
> +192.9.200.169 .GPS. 1 u 7 64 377 0.393 4.982 1.791
> -ntp0.uk.uu.net .GPS. 1 u 19 64 177 31.756 9.495 0.084
>
> So it looks like it's working. The only other question relates
> to the 1pps signal. Depending on the time server in use, the
> pulse may be positive or negative going, but the leading edge
> is the timing point, not the trailing edge some time later.
> There's a fudge factor to define the edge in use and have that
> set for a rising positive edge, but can't find anything in the
> docs that discuss that. If the wrong edge is used, the 1pps
> would be out by the width so assume that needs to be right.
>
> At present, am using the serial port for the 1pps, but have
> some differential driver / receiver devices that will be
> tested on the parallel port some time next week hopefully.
> Meantime can anyone suggest other tests to check accuracy,
> correct operation, statistics etc ?...
>
> Thanks,
>
> Chris

A bit more experimentation, the offset from pps for the network
time server suggested wrong polarity edge was being used.
Measured the pps pulse width, which turned out to be around
5mS, which more or less confirmed it. Selected the other edge
and after 24 hours, get the following:

root at ntp-host:/etc # ntpq -p
remote         refid   st t  when poll reach   delay   offset  jitter
=====================================================================
oPPS(0)          .PPS. 0  l    -    8  377    0.000   -0.001   0.001
+192.9.200.167   .GPS. 1  u   55   64  377    5.103   -0.390   0.359
*192.9.200.168   .GPS. 1  u   40   64  377    0.181   -0.002   0.060
+192.9.200.169   .GPS. 1  u   65   64  377    0.373   -0.008   0.054
-ntp0.uk.uu.net  .GPS. 1  u   27   64  377   31.394    3.272   0.244

The .168 server offset from pps is almost zero, so wrong polarity
was selected. Originally thinking with hardware hat on, the rs232
receiver on the uart dcd input is an inversion and had assumed that
the input to the uart itself defined the edge, when in fact, the edge
is defined by the rs232 input side. I guess that makes sense.

Next thing to try is the parallel port ack line pps and would be
interesting to add a second pps signal to see how that affects the
result. Interesting project for the summer anyway...

Chris



More information about the questions mailing list