Hal Murray <hmur...@megapathdsl.net>: > > All ARM processors back to the ARM6 (1992) have one as well. A little web > > searching finds clear indications of cycle counters on the UltraSparc (SPARC > > V9), Alpha, MIPS, PowerPC, IA64 and PA-RISC. > > On ARM, you can't read it from user land unless a mode bit is set.
That's OK, for our purpose only the implementation of clock_gettime(2) meeds to see it. > > Reading between the lines, it looks to me like this hardware feature became > > ubiquitous in the early 1990s and that one of the drivers was > > hardware-assisted crypto. It is therefore *highly* unlikely to be omitted > > from any new design, even in low-power embedded. And if you have a TSC, > > sampling it is a trivial handful of assembler instructions. > > What does that have to do with crypto? Generation of unique nonces, for starters. > Just to make sure we are all on the same wavelength... > > User code never reads that register. Modern kernels use it for timekeeping. Right, that's why I'm not worried about not being able to see it from userland. > I think kernels went through 3 stages: > > Old old kernels were very coarse. They bumped the clock on an interrupt. > End of story. > > Old kernels use the TSC (or equivalent) to interpolate between interrupts. > (A comment from Mills clued me in. I was plotting temperature vs drift. It > got a lot cleaner when I moved the temperature probe from the CPU crystal > over to the RTC/TOY clock crystal. I haven't looked for the code.) > > Current kernels don't use interrupts for keeping time. It's all done with > the TSC. This agrees with my understanding, though I'm not clear on when the transition from old old to old happened. One thing I don't know. It occurred to me yesterday that if I were implementing a POSIX-compliant OS today I would definitely write get_clocktime(2) so it does *not* surrender the running process's schedule slot. I don't know if it's done this way. > There is an interesting worm in this area. Most PCs fuzz the CPU frequency > to meet EMI regulations. There used to be a separate clock-generator chip: > crystal in, all-the-clocks-you-need out. It's all in the big-chip now, but > you can get specs for the old chips. The logic controlling the PLL > deliberately down modulated the CPU frequency by a 1/2% or so at a (handwave) > 30KHz rate. Sorry, I don't see the relevance. > Just because the hardware has a TSC (or equivalent), doesn't mean that the > software uses it. I wouldn't be all that surprised if the OS for an IoT size > device still had an old-old clock routine. I would be. A large and increasing fraction of these are running Linux, and it has been a long time since Linux was even "old". > We should write a hack program to collect data and make pretty histograms or > whatever. If we are smart enough, we can probably make it scream and shout > if it ever finds an old-old/coarse clock. If we are lucky, we can run that > early in the install path. Checking to see if back-to-back clock_gettime(2) calls yield a fuzz greater than or equal to 1/HZ seems like the obvious check, at least under Linux. We could log that where ntpd computes the fuzz. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel