New toy: attic/clocks.c - time sink warning

[Achim Gratz]

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