[time-nuts] Cheap jitter measurements

Bob kb8tq kb8tq at n1k.org
Tue Apr 10 09:48:41 EDT 2018


> On Apr 10, 2018, at 6:58 AM, Hal Murray <hmurray at megapathdsl.net> wrote:
> kb8tq at n1k.org said:
>> 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”.  
> I was assuming the CPU clock was fast enough that reading a cycle-count 
> register and converting to ns would be within a ns which is the resolution of 
> the clock.
> That's obviously not true for low end SOC type setups.  A Pi-1 runs at 700 
> MHz.  The Pi 3 is up to 1.4 GHz.

Except that’s not the way most timers run. The silicon needed to get a programable 
divider to work at 2.4 GHz is expensive. If you dig into the hardware descriptions, 
the clock tree feeds something much slower to the “top end” of the typical timer
in a CPU or MCU. The exception is the high perf timers in some of the Intel chips. 
There the issue is getting them to relate to anything “outside” the chip. 

>> And the kernel does the “adjust” by dropping or adding clock cycles to the
>> count.
> I was expecting the kernel to do the clock arithmetic with lots of fractional 
> bits.
> You get things like:
>  This is a 2.4 GHz system.  That's 0.416666666 ns per cycle
>  But the crystal is 12 ppm fast, so we actually use 0.416661666
>  It's been 123456 cycles since we last checked.
>  That's 51439.382637696 ns

That may be what the kernel does, but it implements the result as a drop / add
to a counter. 

> Internally, the current time has to remember the fractional bits.
> If anybody is looking carefully, most PC clocks are spread spectrum.  We 
> should do some back-of-envelope work on how significant that is.
>> 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 
> If you want an output pulse, I was thinking of generating it from userland at 
> roughly the right time but recording the actual time.  That would require a 
> fixup pass in software before analyzing the data recorded by traditional 
> hardware approaches.

…… and it would require some sort of correction message out to the user to
tell them how far off that edge that just went out was ….


> -- 
> These are my opinions.  I hate spam.

More information about the time-nuts mailing list