[time-nuts] Cheap jitter measurements

Hal Murray hmurray at megapathdsl.net
Tue Apr 10 06:58:38 EDT 2018


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.


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



-- 
These are my opinions.  I hate spam.





More information about the time-nuts mailing list