On Thu, 2007-12-20 at 13:28 -0800, Bryan Cantrill wrote: > > >> Given the documentation I would consider this to be a bug. And a > > >> pretty nasty one at that. I think if the consensus is that it is, indeed > > >> a bug, the least we can do is to put a note on our Wiki. > > >> > > >> Would anybody from team DTrace care to comment? > > > > > > This is not a bug at all -- this is the difference between gethrtime(3C) > > > and gettimeofday(3C). (If you write a program that does gethrtime() and > > > gettimeofday() for extended periods of time, you should see the same > > > degree of divergence as the D program. If you don't, then that is a bug.) > > > In terms of the difference here, I think the documentation is actually > > > reasonably clear on this; from > > > http://wikis.sun.com/display/DTrace/Variables: > > > > > > timestamp The current value of a nanosecond timestamp counter. > > > This > > > counter increments from an arbitrary point in the past > > > and should only be used for relative computations. > > > > > > walltimestamp The current number of nanoseconds since 00:00 Universal > > > Coordinated Time, January 1, 1970. > > > > I think after reading this, a reasonable expectation would be that these > > two increment "in lockstep" most of the time > > I disagree; I don't think that is a resonable expectation -- it's certainly > not supported by the documentation anyway. (If anything the warning next to > timestamp should dissuade such expectations.)
Perhaps if we designate walltimestamp as a manifestation of the kind of functionality that gettimeofday(3C) provides I would completely agree with your viewpoint and my only concern will be reduced to the documentation issue. That, however, doesn't really help in solving the problem that I have on my hands -- how do I determine the lifetime of the process that was started before the D script? Granted, I'm not a kernel developer so it could be that there's such a way and I would love to be educated on what it is. At the moment, however, I'm really stuck :-( Thanks, Roman. _______________________________________________ dtrace-discuss mailing list [email protected]
