dtrace users opinion solicited (timestamps)

[Thomas Backman]

On Jul 9, 2009, at 20:20, Andriy Gapon wrote:

> on 09/07/2009 21:00 Thomas Backman said the following:
>> On Jul 9, 2009, at 19:31, Andriy Gapon wrote:
>>> 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.
>> Hmm, but "things as they are" causes an overflow about every 10  
>> seconds,
>> so the value is quite useless now (which, of course, you know about,
>> having written a patch for it :)
>
> This is because of a deficiency in the implementation of the  
> formula, not because
> of the formula itself.
>
>> Is scenario #1 after the patch (PR kern/127441 for the rest of you)  
>> or not?
>
> Yes, after the patch :)
In that case, I too strongly prefer alternative #1. It keeps the  
timestamp *time*-based, and not tick-based (thus not breaking Solaris/ 
OS X etc. compatibility), for one. It also makes it a whole lot easier  
to actually *time* things - is it even possible for a non-kernel- 
programmer DTrace user to easily convert the ticks to nanoseconds  
somewhat accurately?
I think that's as good a reason as any (the first one, that is). If  
ZFS is kept as compatible as possible between OSes, then so should  
DTrace, IMHO.

Regards,
Thomas