[time-nuts] Cheap jitter measurements
kb8tq at n1k.org
Sun Apr 8 20:37:05 EDT 2018
Without the ability to put out a “known good” time pulse there is no quick way to
check NTP. GPS modules suffer a similar issue. They put out a pulse and a
“correction” (sawtooth error) to tell you what they just told you. Doing the same
sort of thing with NTP may be possible.
Indeed the process of correcting this sort of data is open to a bit of debate. It does
give you a way to get around the “hey, all I can do is 300 ns” issue. With GPSDO’s
the correction is part of the standard firmware. It would be nice if one of the NTP
guru’s popped up with an equivalent process.
One *could* monitor various bits and pieces of the OS’s timing generation system.
Somehow that does not seem quite as much fun as looking at the whole result all
at once. Indeed it might be the only way to get it all worked out.
> On Apr 8, 2018, at 6:14 PM, John Hawkinson <jhawk at MIT.EDU> wrote:
> Tom Van Baak <tvb at LeapSecond.com> wrote on Sun, 8 Apr 2018
> at 12:36:52 -0700 in <55EB8D26CCDC4B1ABFBC53F95E4C0557 at pc52>:
>> My mental model of a black box computer running NTP
>> Imagine the black box has two BNC connectors; one accepts an input
>> pulse to be timed; one outputs a pulse at certain times.
> Theory runs into reality. The problem is that NTP is easy to set up to do the former, and hard to set up to do the latter. Where "easy" means "it's commonly done" and "hard" means "I'm not aware that it's ever done" (not that I'm so expert that I would necessarily know if it were).
>> To me this better than relying on NTP to tell you how NTP is doing,
>> which as far as I can tell from live plots on the web, is all that
>> most people do. Instead use real, external, physical
>> measurement. The internal NTP stats are fine for tracking the
>> performance of the PLL, but don't confuse that with actual timing.
> One of the things that NTP does is it reports on its status with respect to other NTP peers. Yes, this is still "internal" to the "NTP universe," but it's also external to the device you have in front of you.
> For instance, my ntp server currently reports that it is offset between .6 and 2.1 millisecon
> ds from 7 ntp peers it is talking to, and there's at least some reason to think these are not particularly correllated. That gives me reason to infer that my server's clock is probably not off by more than a few milliseconds. (This is not sub-ns timing, of course. It's intended to be illustrative. And for a variety of reasons this particular server's network connection is a bit unstable, so most NTP users can probably do a lot better.)
> Yeah, that's not truly reliable, like I was comparing it to a truly external reference, but it's also not as meaningless as staring at internal parameters.
> Indeed, one way in practice that ntp people measure ntp is to wire up an external reference to the "input BNC" of your black box, instruct the ntp server to monitor that PPS input but not use it in the clock monkeying algorithm, and then compare what NTP reports for the local clock with what it reports for other NTP peers.
> --jhawk at mit.edu
> John Hawkinson
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
More information about the time-nuts