kb...@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.
_______________________________________________ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.