From: Tomas Tuma1 <UMA@zu...> - 2008-04-20 17:50:48
some new observations to my previous message:
> * Do you think method b) can be better than a) in some
> circumstances? I haven't found a "timer tick" event in pfmon, so I
> would use the count of instructions. It is then clear that different
> cores will process different amount of instructions per-second, so I
> loose the time semantics, however I should still have relative
> timing to the one core.
Well, there are some time-tick events. E.g. Intel Core 2 has the
CPU_CLK_UNHLATED:REF event, that is described by Intel in the following
This event is not affected by core
frequency changes (e.g., P states, TM2
transitions) but counts at the same
frequency as the time stamp counter. This
event can approximate elapsed time while
the core was not in halt state.
But when I try to use interval sampling in pfmon, with sample period set to
the counts of this event oscillate, sometimes with differences even 100x -
How can this be explained?
Thank you very much!
> Well, there are some time-tick events. E.g. Intel Core 2 has the
> CPU_CLK_UNHLATED:REF event, that is described by Intel in the following
> But when I try to use interval sampling in pfmon, with sample period set to
> 100 ms,
> the counts of this event oscillate, sometimes with differences even 100x -
I'm not sure if it's causing this particular problem for you, but check
the intel errata. There's one for this perf counter that makes the count
vary with system frequency on some machines. A core2 machine we have
exhibits this erratum.
I don't think that would cause a 100x difference though.
See the document here:
especially #ah99 though there are many other perf counter issues in that