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 _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel