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@ntp-host:/etc # ntpq -p
remote refid st t when poll reach delay offset jitter
=
oPPS(0) .PPS. 0 l-8 3770.000 -0.001 0.001
+192.9.200.167 .GPS. 1 u 55 64 3775.103 -0.390 0.359
*192.9.200.168 .GPS. 1 u 40 64 3770.181 -0.002 0.060
+192.9.200.169 .GPS. 1 u 65 64 3770.373 -0.008 0.054
-ntp0.uk.uu.net .GPS. 1 u 27 64 377 31.3943.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
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
