Hal Murray via devel writes: You should look at the statistics from the MONOTONIC_RAW clock if available, that one doesn't get manipulated by the frequency correction that NTp applies, so it should reveal the (nominal) cycle time more easily.
> This is typical of a reasonably modern Intel CPU > model name : Intel(R) Core(TM) i3-2120 CPU @ 3.30GHz SandyBridge, should be using an invariant TSC for this measurement, which means that it's using a fixed clock locked to the 100MHz master reference. > Pi 2, Linux > Note the big steps between the buckets. That's not the time to read > the clock, it's a quirk of the measurement system. The clock is > ticking in big steps and that shows up here. All timers run directly off the 19.2Mhz system clock. > Note that clock_getres() on NetBSD and FreeBSD (below) return the tick > size rather than the resolution of timespec. Anybody know where the > language lawyers for this stuff hang out? > > Pi 2, NetBSD: > res avg min dups CLOCK > 52 676 572 CLOCK_REALTIME > 52 655 572 CLOCK_MONOTONIC That is the correct granularity rounded to integer. But only CLOCK_MONOTONIC can possibly tick at exactly that granularity, so I'd say it's somewhat of a gray area what to report as resolution. > Pi 1, Linux: > The min column filters out the dups that would be 0. > Looks like it is using a 1 microsecond clock. > The average time to read the clock is a lot slower than on a Pi 2. The Pi 1 uses a software defined 1MHz counter (run on the VC4 side, not ARM), so it only ever ticks in µs increments. > model name : Intel(R) Atom(TM) CPU 230 @ 1.60GHz That's a failry old Diamondville Atom. > Note the gaps from 122-126 and 128-134. The clock is ticking over > that. I haven't figured out what the actual rate is. It's somewhere > close to 7 ns. I think it should be running the timer from the FSB clock, which I think is either 100MHz or 133MHz (depending on the DRAM, I think). Your's seems to run at 133Mhz, then. > The clock is ticking in 69-70 ns ticks. Same hardware as above. ??? It may just use a different timer, the HPET most often runs at 14.318MHz. > This is the same core as above, but 2 cores in the package rather than > 1. Note the average time is much slower. I'd guess that's the time > for some sort of coordination with the other core. I think the timer read on this older platform needs to be serialized, so yes. > Interesting that it is so much faster than Linux or FreeBSD. Again, they may be using a different timer that doesn't need serialization (or else they just skip it or use opportunistic locking). Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
