This is the mail archive of the mailing list for the systemtap project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Out of order timings of gettimeofday_us()

On Tuesday, January 23, 2007 2:34 PM, Nathan A. Debardeleben wrote:
> I have a very simple script which seems to demonstrate time values
> coming out of gettimeofday_us() being out of order.  I believe this
> function I am probing is extremely fast - but, regardless, it
> shouldn't take negative time to complete. :)
> [...]
> Is the us() timing just too fine grained?  If it's acting like this
> here I question its values in other places.

The short answer is that I'm not too surprised that you got negative
values, and I'm not sure we can do anything about it.  If you need
fine-grained measurement, perhaps get_cycles() would work better for

The time functions are really a "best estimate" -- see this bug for a
little history:

We can't use the kernel's gettimeofday, because it grabs xtime_lock --
our functions must be callable from ANY context, and they'll deadlock if
that lock is already held.

So, our time functions make an estimate based on get_cycles(), the
current frequency, and the kernel's gettimeofday from the last time we
synced (every jiffies tick).  This is imperfect, but safe.  I would
welcome any different designs that still meets our needs though --
perhaps we can give LKML a gettimeofday variant that avoids the lock?

Inaccuracies will arise if your measurement straddles the sync-point,
especially if the frequency we're using isn't quite correct.  If we
underestimate the frequency, then we'll overestimate how much time has
elapsed, so when the sync happens it might backtrack a bit.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]