Pity the poor man who has (n>1) clocks, for he knows not what time it is.
On Sun, Apr 8, 2018 at 4:29 PM, John Ackermann N8UR <j...@febo.com> wrote:
> I want to jump on Tom's post, and Bob's note at 1:14 on Saturday (that
> begins with "Just to be very clear..." They both raise an important point
> about measurements.
> With both NTP and GPSDO measurements a lot of folks focus heavily on what
> the "black box" is reporting about itself. But self-contained measurements
> are really unrelated to actual performance.
> As Bob mentioned, in a GPSDO you can look at tempco, humidco, voltageco,
> and all sorts of other things but the overall point of the system is to
> make those meaningless: the control loop(s) compensate for them. If those
> internal error generators are reduced, it may make the system's work
> easier, but that improvement will have no effect on the quality of the
> output if the control loop is already properly compensating for it.
> And in NTP, the software reports all sorts of interesting measurements,
> but none of them really tell you how close the computer's clock is to a
> local reference. As Tom said, the real test is how the time tick coming
> out of the box compares with the time tick going into it.
> The bottom line is that no self-contained measurement can tell you actual
> performance. The *only* way to do that is to compare your box with an
> external reference whose error bounds are known.
> After all, this is why we're time-nuts -- every time you acquire a clock,
> you also need to acquire a better clock to test it with. :-)
> On 04/08/2018 03:36 PM, Tom Van Baak wrote:
>> What do you mean by "jitter" and what do you really want to do?
>>>> I mean jitter as NTP defines jitter. Whatever that is.
>>> I think you need to figure out what you want to do so you don't fool
>>> ntpd is a PLL. There is a low pass filter in the control loop. It will
>>> track the low frequency wander of the source.
>> Gary, Hal, Leo,
>> My mental model of a black box computer running NTP is that I should be
>> able to give it a pulse (e.g., via parallel, serial, GPIO) and it tells me
>> what time it was. Use a GPSDO / Rb / picDIV to generate precise pulses.
>> Compare the known time of the pulse with the time the box says it was.
>> Repeat many times, collect data, look at the statistics; just as we would
>> for any clock.
>> Similarly, the box should be able to give me a pulse at a known time. In
>> this case it records the time it thinks the pulse went out, and your GPSDO
>> / Rb / TIC makes the actual measurement. Again, collect data and look at
>> the statistics; just as we would for any clock.
>> Imagine the black box has two BNC connectors; one accepts an input pulse
>> to be timed; one outputs a pulse at certain times. This allows a complete
>> analysis of NTP operation. Should be true for both client or server. If you
>> get down to nanosecond levels make sure to use equal length cables.
>> 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.
>> So this is why I'm excited to hear Gary wants a Rb timebase and a sub-ns
>> counter. Someone will finally measure NTP for real, not rely on the
>> internal numbers of NTP measuring itself. Or at least I hope that's what
>> Gary is up to.
>> time-nuts mailing list -- firstname.lastname@example.org
>> To unsubscribe, go to https://www.febo.com/cgi-bin/m
>> and follow the instructions there.
> time-nuts mailing list -- email@example.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/m
> and follow the instructions there.
time-nuts mailing list -- firstname.lastname@example.org
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.