Using Go for NTPsec

[Achim Gratz]

Matthew Selsky via devel writes:
> On Tue, Jun 29, 2021 at 04:41:30PM -0400, Eric S. Raymond via devel wrote:
>
>> Well, first, the historical target for accuracy of WAN time service is
>> more than an order of magnitude higher than 1ms.  The worst-case jitter
>> that could add would be barely above the measurement-noise floor at worst,
>> and more probably below it.
>
> Our target is < 1 us, even for WAN time service. We would want to
> keep/improve this accuracy target.

Assuming you really talk about accuracy of the time transfer (i.e. the
maximum time difference between any two systems) that is impossible
given the principle that NTP uses.  This error bound can't become
smaller than RTT/2 between any pair of systems.  The assumption that NTP
optimizes for is that the connection has symmetrical delay (in which
case the offset would asymptotically converge to zero given totally
stable clocks on all systems involved), but that isn't even remotely
true for many systems these days.  DSL has anywhere between 4 and 12ms
of difference between up and downstream, cable even more.  These delays
are also not constant, so you can't compensate them easily.

Even on LAN you will not be able to get there in most cases.  This is
what my net currently looks like:

version="ntpd ntpsec-1.2.0+66-gfa74bdc67", clk_wander=74ppt, mintc=0
     remote            refid      st t when poll reach   delay   offset   jitter
================================================================================
oNMEA(0)          .NavS.           0 l    5   16  377      0ns    -76ns    258ns
 raspberrypi1     192.168.178.20   2 u    4   16  377 506.80us  9.557us 93.780us
+raspberrypi2     .NavS.           1 u    3   16  377 386.16us -6.713us  7.171us
+raspberrypi3     .NavS.           1 u    2   16  377 401.01us   -245ns  6.622us
-raspberrypi4     .NavS.           1 u    1   16  377 274.55us -27.51us 27.824us
+tinkerboard1     .NavS.           1 u    -   16  377 233.58us -9.908us 34.483us
-tinkerboard2     .NavS.           1 u   15   16  377 303.05us 11.148us  5.473us
 ptbtime1.ptb.de  .PTB.            1 u   46   64  377 22.182ms 941.23us 150.90us
 ptbtime2.ptb.de  .PTB.            1 u   11   64  377 23.415ms 1.6410ms 151.07us
 ptbtime3.ptb.de  .PTB.            1 u   33   64  377 23.473ms 1.5728ms 158.41us
-router.dsl       194.25.134.196   3 u   30   64  377 402.20us 4.3084ms  7.627us

All the local boxes except raspberrypi1 run their own GPS PPS refclock
via GPIO, have self-ovenized temperature stabilization so their drift
rate is well below 0.1ppm/day and are as close to the GPS time as NTP
can possibly determine given the underlying hardware and are connected
to the same fast-forward ethernet switch.  Yet they will see each other
in roughly a 100µs wide window randomly.  Here's what the last two days
look like:

-------------- next part --------------
A non-text attachment was scrubbed...
Name: NTP_2_days.png
Type: image/png
Size: 59242 bytes
Desc: not available
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20210630/fb80e6e0/attachment-0001.png>
-------------- next part --------------

The two excursions are two of the GPS temporarily losing lock due to a a
thunderstorm.  While the offsets look stable in this plot, if you view
that sort of data over a (much) longer time span you will see them
moving around randomly, sometimes there is an event (like a reboot) you
can correlate to, but mostly not.

The three PTB servers are currently offset about 1.5ms on an RTT0 of
20ms (the offset is removed in the plot to just show the jitter).  The
RTT to these three servers has changed between 18…30ms over the years
and the offset (caused by asymmetry) has been all over the place between
1…5ms.  These changes always happen in discrete jumps, again sometimes
they can be correlated to the DSL modem retraining the line, but mostly
seem to be related to changes in routing further upstream.



Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds