Hi 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. Bob > On Apr 8, 2018, at 6:14 PM, John Hawkinson <[email protected]> wrote: > > Tom Van Baak <[email protected]> wrote on Sun, 8 Apr 2018 > at 12:36:52 -0700 in <55EB8D26CCDC4B1ABFBC53F95E4C0557@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. > > [email protected] > John Hawkinson > _______________________________________________ > time-nuts mailing list -- [email protected] > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
