Apparent protocol-machine bug, new top priority

[Achim Gratz]

Fred Wright via devel writes:
> But it can't "filter" the overall offset - it has no way to know what it
> is.

I never claimed that it does.  I lack an absolute time reference anyway
and have yet to splurge for a good enough frequency normal, so at the
moment all I care about is getting the three GPS disciplined ntpd to
agree on the time and minimize the (apparent) offset to my legal time as
served by the PTB.  The current status is that the local servers are
typically within a 50µs bracket (dominated by systematic offsets that I
have not yet compensated for) and about a 200µs bracket for the external
servers (dominated by a variability in the link most likely) as seen by
a separate box on my local net.

>> Again, that number isn't materially affecting the frequency stability,
>> only the time offset.  If you look at that, you will quickly find that
>> your assertion of thermal effects getting dominated by the interrupt
>> latency is wrong.
>
> Of course it has nothing to do with the frequency stability, but it
> directly affects the time offset.  And my assertion is based on the actual
> data.  See below.

The drift of the time offset over a day caused by just the normal
diurnal temperature cycle in the summer and the heating control in the
winter is larger than that offset, out-of-the-box, on a rasPi or
TinkerBoard.  The BeagleBoard might be a little bit more stable, but I
don't think by more than a factor of two.  Making the system oscillator
more stable improves that variability to below 1µs as long as the PPS
from the GPS is stable (your Rb disciplined PPS is much better than
that).  Only then I was able to consistently see the (expected)
differences between the three stratum 1 boxes, but they are still a tiny
bit larger than the interrupt latency.

> This is a day's data from my experimental time server:
>
> 	http://sonic.net/~fw/private/NTP/BB2-2017-09-24/
>
> The main timing reference is a rubidium oscillator, so frequency-related
> effects are essentially nonexistent.  In fact, the error in the Linux
> kernel's limited-precision *representation* of the frequency is about an
> order of magnitude larger than the typical actual frequency error.

Thanks for the data.  No wonder you belittle us poor souls trying to
make do with just the board and GPS module w/ PPS.  But getting the best
possible performance under that constraint is what I am
trying to do, at the moment at leaat.

> PPS(2) is the counter-capture PPS source, and is the primary timing
> reference.

Modulo a constant offset, I'm about a factor of 1.5 away with my best
box and not far behind with the other two.  Considering the price
difference, I'm pretty pleased with that.

> SHM(1) is the combined NMEA/PPS source from GPSD, which is
> configured to use the interrupt-based PPS driver, and hence illustrates
> the offset in the interrupt-based capture.  Between 2100Z and 2200Z I
> switched the governor to powersave (300MHz CPU clock instead of 1GHz), and
> you can see the effect on the latency (but negligible effect on the actual
> timing accuracy).

The jitter figures for the same time period tell a different story.  If
you'd actually lock to that source and monitor PPS(2) instead, you would
likely get some extra time wander due to the not-quite-white jitter
statistics.

>> If you wanted to eliminate that, you'd better use an FPGA or some other
>> microcontroller that has capture units and hardware timestamps for the
>> NIC.
>
> The Beaglebone chipset already has the hardware, it's reasonably well
> documented, and there's driver support for it in Linux.

When I was considering the BeagleBoard, I couldn't find anyone who was
able to deliver it, so that opportunity passed.  I have both some FPGA
and µC hardware available that I could use for a better time server (and
still below the BeagleBoard cost), but I'm constantly out of round tuits
to have an actual go at that.

> The biggest source of inaccuracy is that the generic timekeeping code
> in Linux provides no way to convert a *supplied* counter value to a
> timestamp.

I'd have a long hard look at the RADclock patches from a few years ago.
They will certainly need some porting forward to the modern kernel, but
I still think the approach was sound and I would love to see that
resurrected in the kernel.

> BTW, the Beaglebone chipset also has hardware timestamping in the NIC, and
> I believe there's kernel support for it, but one can't take full advantage
> of that without solving the "send timestamp problem".

Maybe, although it seems more likely that only the general timestamp
support is compiled in, with the peripheral driver support missing.  Try
ethtool to see if the NIC driver actually recognizes that support.  IF
it does, then PTP should also work.


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