[ntp:questions] Time server question

Chris xxx.syseng.yyy at gfsys.co.uk
Sat Jul 13 15:38:44 UTC 2019


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



More information about the questions mailing list