[ntp:questions] Time server question

Chris xxx.syseng.yyy at gfsys.co.uk
Sun Jul 21 17:31:36 UTC 2019


On 07/21/19 15:02, Terje Mathisen wrote:
> William Unruh wrote:
>> On 2019-07-19, Chris <xxx.syseng.yyy at gfsys.co.uk> wrote:
>>> On 07/18/19 11:13, William Unruh wrote:
>>>
>>>>
>>>> Sure, but I do not have faith in the "averaging" If one is always 30us
>>>> after the other, then the average will always be out by 15us.
>>>
>>> One would expect a difference, but how can you tell which one is right
>>> using just 2 pps ?. With three, you could choose the closest to average
>>> and discard the outlier, or if it was outside a defined window. Ok,
>>> it's a bit nitpicking, but would still be interesting to try it.
>>
>> No. The mechanism is clear. While one is answering its interrupt the
>> other gets to wait. So, it is the earliest one that is closest to
>> "right" Ie, do not try to use more than one interrupt on the same
>> computer. It does not work
>
> A good timing-optimized gps unit, like the original Oncore, have a sw
> mechanism to offset the PPS event away from the actual top of the
> second, as well as a way for the sw protocol that numbers the PPS
> signals to also specify how far away this particular pulse is from the
> actual event.
>
> I.e. with an internal 10 MHz clock, PPS signals will be synced to one of
> those 100 ns-wide periods, so it can/will be at least up to +/-50 ns
> away from the proper moment, but when the driver knows about this, it
> can adjust perfectly for that effect.
>
> Terje
>

Some of the vendors of more modern ntp servers
make the point of saying that the 10MHz reference
output is synchronised  (phase locked ?) to the
pps leading edge, but not sure about older units.
What is clear is that the ntp is a very smart piece
of code under the hood. Am reading the docs, but
haven't looked the code yet, so only scratching the
surface as far as understanding how it all works.

The main interest is to get the system in a state
accurate and consistent enough to join an ntp pool,
but also satisfy the need for a 10MHz standard for
the the lab test gear, which is where the gps do
journey started.

At present, the experimental setup consists of three
older network time servers, collected over the years,
spares or repairs state, all needing work. There's
a Datum TS2100, a time tools 9860D and a Truetime
nts-100. The server host is an intel atom box, mini
itx with two network ports, one that will be internet
facing and the other for the time server subnet.
Running FreeBSD 12 with the current ntp package. PPS
is currently to the serial port dcd, but will change
to the parallel port ack once the driver and receiver
hw are in place. Other ideas include using a stripped
down kernel FreeBSD like nanobsd, to minimise cpu load.

Typical output from ntpq is:

root at ntp-host:/ # ntpq -p -c readvar -c clockvar
remote           refid  st t when poll reach   delay offset jitter
====================================================================
oPPS(0)          .PPS.  0 l    5    8  377    0.000  0.000  0.002
+192.9.200.167   .GPS.  1 u    -   64  377    5.145 -0.412  0.349
*192.9.200.168   .GPS.  1 u   29   64  377    0.175  0.001  0.025
+192.9.200.169   .GPS.  1 u   33   64  377    0.361  0.001  0.042
-ntp0.uk.uu.net  .GPS.  1 u   36   64  377   32.104  3.624  0.691

Datum = .167, time tools = .168 and nts-100 = .169. The last item
is to provide at least 1 external source. The .168 is prefer to
the pps source

associd=0 status=011d leap_none, sync_pps, 1 event, kern,
version="ntpd 4.2.8p12-a (1)", processor="amd64",
system="FreeBSD/12.0-RELEASE-p6", leap=00, stratum=1, precision=-21,
rootdelay=0.000, rootdisp=1.075, refid=PPS,
reftime=e0df1ca6.6e8d1281  Sun, Jul 21 2019 18:17:26.431,
clock=e0df1cac.2997c50c  Sun, Jul 21 2019 18:17:32.162, peer=42481, tc=3,
mintc=3, offset=-0.000270, frequency=-49.547, sys_jitter=0.001526,
clk_jitter=0.002, clk_wander=0.001, tai=37, leapsec=201701010000,
expire=201712280000

associd=0 status=0000 no events, clk_unspec,
device="PPS Clock Discipline", timecode="", poll=86832, noreply=0,
badformat=0, baddata=0, stratum=16, refid=80.80.83.0, flags=6

Thanks for all the feedback on this, any suggestions welcome...

Chris





More information about the questions mailing list