March 2008 - Darwin-dev - lists.apple.com

SHM_INFO and SHM_STAT
by Christof Rath 31 Mar '08

31 Mar '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tugraz.at; s=mailrelay; t=1206987820; bh=t4NZPhrz2vdIkZmuufo+/5SbDkyZqqWIi3MtX u61vsk=; h=Message-Id:From:To:Content-Type: Content-Transfer-Encoding:Mime-Version:Subject:Date:X-Mailer; b=nO +33RSET0Zdmqaag/cVBrvjEWAjIuM4fBB8ZjhE/acg5ym00YCk7Y6m3nZTDTrpCBVGB HbO95Dvb6vOYdcKiQMmKb7oZGgR47qscJuEd7G9U49HojSB7gW7xoOS21GDjy59IZs0 s+iUG141x2xfOdlTptHwyMnkyKD7N/hKTPw= The four commands in use: SHM_INFO, SHM_STAT, SHM_LOCK and SHM_UNLOCK a code fragment: [...] struct shmid_ds shm_info; max_id = shmctl( 0, SHM_INFO, &shm_info ); if (max_id >= 0) { for ( int i = 0; (_memptr == NULL) && (i <= max_id); ++i ) { shm_id = shmctl( i, SHM_STAT, &shm_segment ); if ( shm_id < 0 ) continue; [...] or: [...] if (swapable) { shmctl(__shared_mem_id, SHM_UNLOCK, NULL); } else { shmctl(__shared_mem_id, SHM_LOCK, NULL); } [...] Best wishes, Christof _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… Hey there, I try to compile a robot framework that is written for Linux. My problem is, that it uses shmctl() commands that aren't defined in shm.h (like on linux systems). is there a workaround? Can anybody tell me how to access this information? This email sent to site_archiver(a)lists.apple.com

1 0

Re: high accuracy timing options?
by Aaron Turner 30 Mar '08

30 Mar '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=odpqrW7NQzcxtoGVP3WzYkQW7zfoGqlxuLlpVhG45E0=; b=Q61rMSRlHveI34ADf8IV6j1i0MERxXcSBjErKS4cIhU09wZPrtnT5d++ajTnbieSrVUMtyC92cIt4KxWEn+3LiOSBH3Xg2xwagoUOHOhpoJVZLloXSIwrZIMzVGpLLxh1ydxVoZsdj3mqYvS7aIjd22DpZHVY+fV2nwbknTTuNU= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Unlin8fVSBmRCvzL0BB58f/U1W8bWjxCgb/f/ADIZcj/b00Q6eZ2470WBdA+S7az4BOIYFTOr/oHNlSi+k70XtwFrzpQWhgrV/EOyPWlbwaHz6T+UC8yYSkUxxJ9oesrnpUMFF4qMaU4XimQmqd49awP5ZGeplq1HgdfuZVEq60= On Fri, Mar 28, 2008 at 10:12 PM, Michael Smith <msmith(a)freebsd.org> wrote: > > On Mar 28, 2008, at 12:05 PM, darwin-dev-request(a)lists.apple.com wrote: > > >> If I understood what you were actually trying to do, I might have > >> some > >> better ideas... > > > > I'm not really sure what more I can say. I have a tight loop which > > sends packets at various user defined intervals. Speeds range from > > quite slow (a few packets/second) to quite fast (beyond 150K/sec). > > I'm hoping to send packets at equal distant intervals for an even > > distribution rather then time-slicing it (send a bunch of packets at > > once and sleeping for longer periods of time), but I suppose I may be > > asking too much. > > Given that the packets are going to be clustered up by the time they > hit the wire due to queueing and scheduling latencies in both the > network stack and the MAC, I believe you are trying a bit too hard. > > Pick a quantum that's not too coarse (a millisecond is probably a good > place to start) and barf out a bunch of packets each time it ticks over. Reasonable theory... Honestly, something I've given some thought to, but frankly, it's painfully hard to measure how much better/worse it would work. Putting a sniffer on the wire doesn't help since the receiving box is going to queue up the reads and I know pcap timestamps are inaccurate (It's not that uncommon to see sequential packet timestamps go backwards). At some point, you just have to do your best and be done with it. > You can tune the actual quantum number up or down based on a bunch of > factors, but bear in mind that you're talking to a networking stack > designed for user applications, not a SmartBits. 8) It would probably > be educational to watch the actual timing of the resulting wire > traffic (or if you're doing end-to-end work, timestamps on the > received packets) to see how adjusting the quantum affects what you're > actually trying to achieve. > > If you are worried about beat effects, consider using a balanced PRNG > to jitter your quantum around by a significant factor (I'd start at > maybe +/- 30%). Then you can either leave the ppq value the same and > get non-constant short term packet rates (but keeping the same long- > term rate), or scale the ppq with the jitter factor to keep the short > term packet rate constant but moving the bursts around to avoid e.g. > scheduling quantum boundaries in whatever you're talking to. One issue I'm dealing with is that I sometimes generate traffic *through* devices- meaning both client & server side of the connection. Beat effects are definitely an issue here and I'm not sure adding some jitter is a workable solution. Probably worth looking into sometime though. Using such a mechanisim could possibly allow higher packet rates. > If it's critical that your quantum be particularly small, you might > also want to consider using code inside the kernel; this can save you > on the per-packet overheads you're currently paying for pushing them > into the kernel. In the most extreme case, you could steal an > interface from the network stack completely, again depending on what > your ultimate goals might be. Cross platform is probably one of the biggest goals. I develop on OS X and most of my users use Linux, with some Solaris and *BSD thrown in for good measure. Maybe one of these days I'll do kernel modules, but for now I've got higher priorities. Right now my plan is to use weighted averaging to simulate sub 1usec accuracy. Ie, if the rate should be 7.7usec, I'll send 7 packets @ 8usec and 3 at 7usec. > HTH. Definitely... always appreciate some ideas. -- Aaron Turner http://synfin.net/ http://tcpreplay.synfin.net/ - Pcap editing & replay tools for Unix They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: dladdr
by Peter O'Gorman 29 Mar '08

29 Mar '08

site_archiver(a)lists.apple.com Delivered-To: Darwin-dev(a)lists.apple.com User-agent: Thunderbird 2.0.0.9 (X11/20071115) James W.Walker wrote: > > On Mar 26, 2008, at 10:17 PM, James W. Walker wrote: > >> I tried using backtrace_symbols from a framework of mine, and the >> function names were wrong. They were names that were probably in the >> framework somewhere, but not code that was actually being used. This >> was a debug build, full debug symbols, not optimized, not stripped. I >> tried changing the debug info format from Dwarf to Stabs and it made >> no difference. What might I be missing? > > Having received no response to that question, I looked a little deeper. > I see that the key is dladdr, which backtrace_symbols uses to get the > symbols. And I find that dladdr starts working the way I expect when I > uncheck the "Symbols Hidden by Default" code generation option for gcc. > So, is that just the way it works - that when the dladdr docs say it > finds the "nearest runtime symbol", that means exported symbol? Yes, it only finds global symbols. Peter -- Peter O'Gorman http://pogma.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

dladdr (was: backtrace_symbols not giving right symbols)
by James W.Walker 29 Mar '08

29 Mar '08

site_archiver(a)lists.apple.com Delivered-To: Darwin-dev(a)lists.apple.com On Mar 26, 2008, at 10:17 PM, James W. Walker wrote: I tried using backtrace_symbols from a framework of mine, and the function names were wrong. They were names that were probably in the framework somewhere, but not code that was actually being used. This was a debug build, full debug symbols, not optimized, not stripped. I tried changing the debug info format from Dwarf to Stabs and it made no difference. What might I be missing? Having received no response to that question, I looked a little deeper. I see that the key is dladdr, which backtrace_symbols uses to get the symbols. And I find that dladdr starts working the way I expect when I uncheck the "Symbols Hidden by Default" code generation option for gcc. So, is that just the way it works - that when the dladdr docs say it finds the "nearest runtime symbol", that means exported symbol? _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: high accuracy timing options?
by Michael Smith 29 Mar '08

29 Mar '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Mar 28, 2008, at 12:05 PM, darwin-dev-request(a)lists.apple.com wrote: I'm not really sure what more I can say. I have a tight loop which sends packets at various user defined intervals. Speeds range from quite slow (a few packets/second) to quite fast (beyond 150K/sec). I'm hoping to send packets at equal distant intervals for an even distribution rather then time-slicing it (send a bunch of packets at once and sleeping for longer periods of time), but I suppose I may be asking too much. HTH. = Mike _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… If I understood what you were actually trying to do, I might have some better ideas... Given that the packets are going to be clustered up by the time they hit the wire due to queueing and scheduling latencies in both the network stack and the MAC, I believe you are trying a bit too hard. Pick a quantum that's not too coarse (a millisecond is probably a good place to start) and barf out a bunch of packets each time it ticks over. You can tune the actual quantum number up or down based on a bunch of factors, but bear in mind that you're talking to a networking stack designed for user applications, not a SmartBits. 8) It would probably be educational to watch the actual timing of the resulting wire traffic (or if you're doing end-to-end work, timestamps on the received packets) to see how adjusting the quantum affects what you're actually trying to achieve. If you are worried about beat effects, consider using a balanced PRNG to jitter your quantum around by a significant factor (I'd start at maybe +/- 30%). Then you can either leave the ppq value the same and get non-constant short term packet rates (but keeping the same long- term rate), or scale the ppq with the jitter factor to keep the short term packet rate constant but moving the bursts around to avoid e.g. scheduling quantum boundaries in whatever you're talking to. If it's critical that your quantum be particularly small, you might also want to consider using code inside the kernel; this can save you on the per-packet overheads you're currently paying for pushing them into the kernel. In the most extreme case, you could steal an interface from the network stack completely, again depending on what your ultimate goals might be. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Kernel Debug Kit for 10.5.2 build 9C7010 ?
by Woojung.Huh＠smsc.com 28 Mar '08

28 Mar '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com kernel debug kit 10.5.2 build 9C7010 is posted on ADC site. Garth Cummings <gcummings(a)apple.com> Sent by: To darwin-dev-bounces+woojung.huh=smsc Rob Cas <sacbor(a)gmail.com> .com(a)lists.apple.com cc Darwin Dev <darwin-dev(a)lists.apple.com> Subject 03/27/2008 07:27 PM Re: Kernel Debug Kit for 10.5.2 build 9C7010 ? Please respond to Darwin Dev <darwin-dev(a)lists.apple.com> Hi Rob, On Mar 27, 2008, at 4:07 PM, Rob Cas wrote: Hi, The build number for 10.5.2 appears to have changed from 9C31 to 9C7010 with (I'm assuming) some of the Apple Software Updates. The kernel debug kit posted at: http://developer.apple.com/hardwaredrivers/download/kerneldebugkits.html is for build 9C31. My early installations of 10.5.2 (with no subsequent software updates, xnu-1228.3.13~1) match this build number, but my current installations (after applying all Software Updates) have build number 9C7010 (xnu-1228.4.31~1). Can Apple please post an updated 10.5.2 Kernel Debug Kit? (I'm currently finding my various kgmmacros do not work.) Thanks, Rob. Thanks for bringing this to our attention. Let me check into this--it's unusual for a software update to change the installed build number like this. There shouldn't be any problem posting an updated Kernel Debug Kit, but it might take a couple of days. Thanks, --gc ____________________________________________________________________ Garth Cummings gcummings(a)apple.com Sr. Software Engineer Apple Developer Technical Support <http://developer.apple.com/technicalsupport> WWDC 2008 • June 9-13 • Moscone West • San Francisco, CA <http://developer.apple.com/wwdc/> _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/woojung.huh%40smsc.com This email sent to woojung.huh(a)smsc.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: high accuracy timing options?
by Jonas Maebe 28 Mar '08

28 Mar '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com One thing to keep in mind about MacOSX is that the sleep is *really* accurate compared to Linux, BSD and Solaris. Please read the referenced web page. This has nothing to do with small delays. Jonas _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… On 28 Mar 2008, at 13:24, Andrew Gallatin wrote: Jonas Maebe writes: On 27 Mar 2008, at 22:25, Andrew Gallatin wrote: See http://www.dragonflybsd.org/docs/nanosleep/index.shtml And also that this is mainly because for very small delays, Darwin You're right, the "that this is mainly because" should have been "note that" (which may be important for the OP's situation, where his delays may become quite small when he tries to throttle his network output). This email sent to site_archiver(a)lists.apple.com

1 0

Re: high accuracy timing options?
by Andrew Gallatin 28 Mar '08

28 Mar '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Jonas Maebe writes: > > On 27 Mar 2008, at 22:25, Andrew Gallatin wrote: > > One thing to keep in mind about MacOSX is that the sleep > > is *really* accurate compared to Linux, BSD and Solaris. > > > > See http://www.dragonflybsd.org/docs/nanosleep/index.shtml > > And also that this is mainly because for very small delays, Darwin Please read the referenced web page. This has nothing to do with small delays. What this test is doing is setting a wakeup time once per second, and seeing how close the OS gets to waking up at exactly the requested time. Most *nix OSes stink at this kind of thing, as they'll wake processes up once per clock tick, or every 10ms or so. Worse, if your desired wakeup time straddles a clock tick, you might be off by as much as 2 clock ticks (reference the 19ms in the article). The nice thing about Darwin is that it tries to wake you up at exactly the time you requested. > lets the "waiting" thread simply burn cpu cycles until the delay is > over (at least when I looked into this a couple of years ago). The > result is that very small delays are (were) quite inefficient from a > multi-processing perspective on Darwin (with the mentioned upshot that > they're pretty accurate). FWIW, the referenced program is mostly idle: % /usr/bin/time ~/tmp/wakeup_latency.intel_mac 21.000000 21.000000 21.000000 20.000000 20.000000 ^CCommand terminated abnormally. 4.62 real 0.00 user 0.00 sys We actually had a daemon that needed an accurate sleep period between 1 and 60 seconds. On other OSes, we had to wake it up a few 100ms early and busywait. On Darwin, we were able to ifdef out that code and sleep for the desired amount of time. Drew _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: high accuracy timing options?
by Aaron Turner 28 Mar '08

28 Mar '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=lVFBpzld9F/UD6eKWqQt6ADXsCVfNJbyStc23VdW490=; b=lb3lI+0jcB7UOaJA5mMBnfygAomqqVPCbecKeLS9ZDnd47ZkDpN7lqfDNTxzfoBHTEGieO0rNM9GpeVsK6hjqLUFZf8wZKHZxJ74edjX0FAlJEmemnH7BU6v47oj7fzQpRg9T0cnYiRiqEiXMGHIUBf/Ac3Pi/fiW/o1Z7ckGF4= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=kVPzfiReEfYA7D7cDAifirUt7xloSb77j2jI5bDbMwBrlNW3JAVI2JDPAvCXLQQS1N6kPaJCZDsSJmhXQ2L2Lp5Kw6KpDErJIMFoPxiMjFZ1AITfVjuCT6vWjJLwNglM2t2gl5f8z1QIbsldto3vd10SqLiZEOzxknpBEqGVD60= On Thu, Mar 27, 2008 at 8:56 PM, Michael Smith <msmith(a)freebsd.org> wrote: > > On Mar 27, 2008, at 12:04 PM, darwin-dev-request(a)lists.apple.com wrote: > [snip] > > Very interesting results: > > > > Ran gtod() 68160730 times in 5 seconds. > > 13.632146 gtod()/usec > > Failed to increment 63197136 times > > > Back in time 0 times > > [...etc...] > > > > Interesting how gettimeofday() fails to increment around 90% of the > > time. I guess technically incrementing 1/10 times while requiring > > > ~13 times to measure a usec is good enough, but it's not giving me a > > warm & fuzzy feeling. > > I don't exactly know what you expect here. > > % expr 68160730 - 63197136 > 4963594 > > Of the 5 million unique microsecond values to be experienced in your > five second test, you saw all but about 36,000 (0.07%) of them. > > Or are you dissatisfied that an iteration of your loop takes nearly > 80ns to run? Yeah, I realized that after I sent that email.... obviously gettimeofday() only has usec resolution, so expecting better then that is a bit silly. Unfortunately the 80ns/loop iteration is very hardware dependent. I suppose I could try calculating this on a per system level, but it's a bit of a hack. > > May just be one of those things where a RTOS is necessary to get > > any improvement. > > In what direction are you looking for "improvement"? It's a common > mistake to think that RTOS' have better resolution; typically what you > get from an RTOS is determinism, often achieved at the cost of peak > performance. Well going back to my previous email about 125K vs 130K pps, I think I've figured out my problem. Basically as my packet rate increases, the necessary resolution is better then 1usec. 125Kpps is 8usec, but 130Kpps is 7.7usec. I've been trying to hit 130K but seeing much higher rates (around 143K) which is ~7usec delay. Looks like I'm blocking short. > > > Anyone know if OS X/Darwin has the equivalent of Linux's > > RT scheduler extensions? > > Darwin has a fairly modest but effective set of RT-like scheduling > capabilities. What is it exactly that you are trying to achieve? > It's very hard to get any sort of "RT" in a system where you have any > sort of competition, and a desktop Darwin system is very competitive. I was guessing that part of my problem is that I'm trying to monopolize the CPU for relatively long periods of time and I'm being put to sleep while other processes are being serviced. I was hoping/guessing that trying some RT features might help with being scheduled accurately when calling nanosleep(). Probably not going to help since I'm blocking short though. > > Anyways, I'm going to try to dig around some more and try to find the > > HPET timer API. Theoretically, that should be more accurate then what > > I'm seeing with gtod(). > > What do you mean by "accurate"? Your test above has demonstrated that > gettimeofday is returning unique microsecond values; it has no greater > resolution. If you were truly pedantic you could add roughly half > another significant figure (on your test system) by counting the > number of iterations since you last saw gettimeofday() wrap, but even > then the question around that sort of timing resolution is - what do > you expect it to tell you? Doing any sort of real work takes orders > of magnitude longer than that... Well my packet sending code is pretty well optimized... I'm bypassing the IP stack completely, so it's basically a memcpy() from user space to the NIC driver to send. But point well taken. > If you think that the HPET will help you, I'm sorry; it's too slow, > it's too far away (the connection is highly latent, you can be held > off talking to it for milliseconds in pathalogical cases), and the > Darwin kernel owns it entirely. Really? Suck. > If I understood what you were actually trying to do, I might have some > better ideas... I'm not really sure what more I can say. I have a tight loop which sends packets at various user defined intervals. Speeds range from quite slow (a few packets/second) to quite fast (beyond 150K/sec). I'm hoping to send packets at equal distant intervals for an even distribution rather then time-slicing it (send a bunch of packets at once and sleeping for longer periods of time), but I suppose I may be asking too much. -- Aaron Turner http://synfin.net/ http://tcpreplay.synfin.net/ - Pcap editing & replay tools for Unix They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: high accuracy timing options?
by Michael Smith 28 Mar '08

28 Mar '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Mar 27, 2008, at 12:04 PM, darwin-dev-request(a)lists.apple.com wrote: So I decided to do some benchmarking: ---- code ---- int main(int argc, char *argv[]) { u_int32_t count = 0, fail = 0, back = 0, i; struct timeval sleep_until, now, last; printf("Ran gtod() %lu times in 5 seconds.\n", count); printf("%f gtod()/usec\n", (float)count / 5000 / 1000); printf("Failed to increment %lu times\n", fail); printf("Back in time %lu times\n", back); printf("-------------\n"); count = 0; fail = 0; back = 0; } exit(0); } ---- code ---- gcc -O3 -o gtod gtod.c Very interesting results: Ran gtod() 68160730 times in 5 seconds. 13.632146 gtod()/usec Failed to increment 63197136 times Back in time 0 times [...etc...] Interesting how gettimeofday() fails to increment around 90% of the time. I guess technically incrementing 1/10 times while requiring ~13 times to measure a usec is good enough, but it's not giving me a warm & fuzzy feeling. I don't exactly know what you expect here. % expr 68160730 - 63197136 4963594 Anyone know if OS X/Darwin has the equivalent of Linux's RT scheduler extensions? Anyways, I'm going to try to dig around some more and try to find the HPET timer API. Theoretically, that should be more accurate then what I'm seeing with gtod(). = Mike _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… for (i = 0; i < 5; i ++) { gettimeofday(&sleep_until, NULL); sleep_until.tv_sec += 5; gettimeofday(&last, NULL); do { count++; gettimeofday(&now, NULL); if ((now.tv_sec == last.tv_sec) && (now.tv_usec == last.tv_usec)) fail ++; else if (timercmp(&last, &now, >)) back ++; last.tv_sec = now.tv_sec; last.tv_usec = now.tv_usec; } while (timercmp(&now, &sleep_until, <)); Of the 5 million unique microsecond values to be experienced in your five second test, you saw all but about 36,000 (0.07%) of them. Or are you dissatisfied that an iteration of your loop takes nearly 80ns to run? May just be one of those things where a RTOS is necessary to get any improvement. In what direction are you looking for "improvement"? It's a common mistake to think that RTOS' have better resolution; typically what you get from an RTOS is determinism, often achieved at the cost of peak performance. Darwin has a fairly modest but effective set of RT-like scheduling capabilities. What is it exactly that you are trying to achieve? It's very hard to get any sort of "RT" in a system where you have any sort of competition, and a desktop Darwin system is very competitive. What do you mean by "accurate"? Your test above has demonstrated that gettimeofday is returning unique microsecond values; it has no greater resolution. If you were truly pedantic you could add roughly half another significant figure (on your test system) by counting the number of iterations since you last saw gettimeofday() wrap, but even then the question around that sort of timing resolution is - what do you expect it to tell you? Doing any sort of real work takes orders of magnitude longer than that... If you think that the HPET will help you, I'm sorry; it's too slow, it's too far away (the connection is highly latent, you can be held off talking to it for milliseconds in pathalogical cases), and the Darwin kernel owns it entirely. If I understood what you were actually trying to do, I might have some better ideas... This email sent to site_archiver(a)lists.apple.com

1 0