[time-nuts] Cheap jitter measurements
kb8tq at n1k.org
Mon Apr 9 18:24:53 EDT 2018
> On Apr 9, 2018, at 4:53 PM, Hal Murray <hmurray at megapathdsl.net> wrote:
> kb8tq at n1k.org said:
>> Somewhere in the NTP algorithm, there is a “zero error” estimate. GPS
>> modules have the same thing buried in them. A GPS module (like NTP as
>> described above) can only *express* a PPS modulo some clock rate. GPS
>> modules get around this with a firmware hack. They simply tell you what the
>> error was. It is a simple way to get out of the “I need a 10 GHz clock
>> source” problem. No need for FPGA’s or any other guck. You just do an
>> estimate and report it. It then would work on any hardware and let you do
>> the sort of measurements we’re talking about.
> The GPS offset is a kludge to work around not being able to control the local
>> Now - *can* that be done with NTP?? Who knows….
> The kernel clock has a knob so the same concept doesn't apply.
The kernel clock comes from the CPU clock. That CPU clock is phase locked
to a crystal. If you have a CPU that is driven by a VCXO that is a *very* unusual
CPU board. The crystal runs at an arbitrary frequency. That gives you edges that
are unlikely to happen “right on the second”.
> The API for the kernel clock can be read to a ns. I don't see ntpd having
> much use for finer grain than that. I should look at the source to see what
> the internal details look like.
> If ntpd decides the clock needs correcting, it tells the kernel to do the
> work. The kernel offsets the clock rate knob by 500 PPM, so it takes 2000
> microseconds to adjust the clock by 1 microsecond. It would be possible to
> read the correction-left and adjust the time by that amount.
And the kernel does the “adjust” by dropping or adding clock cycles to the count.
The result is still modulo the hardware clock period as conveyed to the kernel through
a timer. Dig into the timer architecture and it has it’s limitations. What they are is
very much a “that depends” from this CPU to that CPU.
Being able to read the kernel time is only part of the process. You need to generate
an edge. That gets you into timers and (likely) a different set of limitations as the
edge makes it’s way to get to a pin.
> I think it would be possible to make similar adjustments by post processing
> the data. I'd have to double check to make sure I understand what is in
> loopstats. If now, we could fix it.
The idea is to get a second by second update of what is going on relative to an edge
that comes out of the computer. Effectively you:
1) need to generate that edge
2) track it back to the NTP internals
3) turn that track into a message that tells the user what the offset is
Now, if indeed you *can* generate edges to within 1 ns of an arbitrary point in time, then
yes - the message probably has no value. I have yet to see a normal computer that is set
up to do that. Putting a GHz clock into a modulo divider or 32 bit comparator apparently
isn’t something there is much call for …..
> These are my opinions. I hate spam.
> 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