[time-nuts] Cheap jitter measurements

John Ackermann N8UR jra at febo.com
Sun Apr 8 17:29:22 EDT 2018


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. :-)

John
----
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 yourself.
>>
>> 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.
> 
> /tvb
> 
> _______________________________________________
> 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 mailing list