Comments on: List process start dates http://boredzo.org/blog/archives/2008-02-08/list-process-start-dates The personal weblog of Peter Hosey. Fri, 05 Dec 2008 13:22:50 +0000 http://wordpress.org/?v=2.6.5 By: Peter Hosey http://boredzo.org/blog/archives/2008-02-08/list-process-start-dates#comment-163930 Peter Hosey Mon, 11 Feb 2008 16:53:35 +0000 http://boredzo.org/blog/archives/2008-02-08/list-process-start-dates#comment-163930 <p>Huh. I didn't know about the .15 part before; the <a href="http://developer.apple.com/documentation/Carbon/Reference/Memory_Manag_nt_Utilities/Reference/reference.html#//apple_ref/c/func/TickCount" rel="nofollow">Carbon TickCount documentation</a> says simply “approximately 1/60th”. Apparently it's an artifact of the original Macs' refresh rate being 60.15 Hz.</p> Huh. I didn't know about the .15 part before; the Carbon TickCount documentation says simply “approximately 1/60th”. Apparently it's an artifact of the original Macs' refresh rate being 60.15 Hz.

]]> By: Drew Thaler http://boredzo.org/blog/archives/2008-02-08/list-process-start-dates#comment-163923 Drew Thaler Mon, 11 Feb 2008 16:19:37 +0000 http://boredzo.org/blog/archives/2008-02-08/list-process-start-dates#comment-163923 Process Manager ticks are pretty large: 60.15 ticks per second = roughly 16.625ms each. So you're not going to get any more precise than that. There also aren't any APIs to do Ticks since any other reference point; Ticks overflowed too soon to be useful for anything else. TickCount() will return the number of ticks since system startup. You can use "now" as the common reference point to map ticks to a more precise date value like NSDate. Just call TickCount twice, once before and once after, and make sure you get the same value. Something like this: <pre>UInt32 tc = 0; NSDate *d = nil; do { tc = TickCount(); d = [NSDate date]; } while (tc != TickCount()); // try again if we've rolled over to the next tick</pre> After this code executes both tc and d will contain equivalent times: tc will be the time in Ticks since system startup, and d will be a corresponding NSDate (within the 16.6ms window). Since you know that the Tick frequency is 60.15Hz, a little math should do the trick from there. Note that if your machine's uptime is greater than the TickCount wrap time (about 27 months, iirc) then I think the values in processLaunchDate will start wrapping. Process Manager ticks are pretty large: 60.15 ticks per second = roughly 16.625ms each. So you're not going to get any more precise than that. There also aren't any APIs to do Ticks since any other reference point; Ticks overflowed too soon to be useful for anything else.

TickCount() will return the number of ticks since system startup. You can use "now" as the common reference point to map ticks to a more precise date value like NSDate. Just call TickCount twice, once before and once after, and make sure you get the same value. Something like this:

UInt32 tc = 0;
NSDate *d = nil;
do {
 tc = TickCount();
 d = [NSDate date];
} while (tc != TickCount()); // try again if we've rolled over to the next tick

After this code executes both tc and d will contain equivalent times: tc will be the time in Ticks since system startup, and d will be a corresponding NSDate (within the 16.6ms window). Since you know that the Tick frequency is 60.15Hz, a little math should do the trick from there.

Note that if your machine's uptime is greater than the TickCount wrap time (about 27 months, iirc) then I think the values in processLaunchDate will start wrapping.

]]>