Re: dtrace users opinion solicited (timestamps)

From: Henri Hennebert <hlh_at_restart.be>
Date: Thu, 09 Jul 2009 20:19:00 +0200
Andriy Gapon wrote:
> As you might be aware DTrace timestamps right now are derived from TSC value.
> http://en.wikipedia.org/wiki/Time_Stamp_Counter
> 
> DTrace timestamps are measured in nano-seconds and the formula similar to the
> following is used for calculations:
> rdtsc() * 1000000000 / tsc_freq
> where rdtsc is a function that returns current TSC value and tsc_freq is a
> frequency of TSC.
> 
> This formula is supposed to produce proper results if tsc_freq stays constant.
> But there are environment where this might not be the case.
> If a CPU has a non-invariant TSC and processor's clock frequency changes (e.g.
> because of powerd), then tsc_freq changes too.
> As a result, the formula would produce wildly different values and, most
> importantly, was values would non be monotonic. Timestamp values that jump back
> and forth would not only be useless for a user, they would also confuse DTrace
> internal logic.
> 
> There are at least the following two alternatives:
> 
> 1. Keep things as they are and warn users not to change CPU clock frequency when
> they use DTrace and the CPU doesn't have invariant TSC. I think that this should
> cause only minor inconveniences to a portion of DTrace users.
Im absolutely for this solution with a warning in the doc. It seems to 
me that when you use dtrace, you don't try at the same time to be power 
efficient... except if you want to dtrace powerd, of course.

henri
Received on Thu Jul 09 2009 - 16:19:05 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:51 UTC