[time-nuts] Cheap jitter measurements
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
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
I was expecting the kernel to do the clock arithmetic with lots of fractional
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
These are my opinions. I hate spam.
More information about the time-nuts