site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Date: Wed, 7 Feb 2007 09:58:18 -0800 From: "CJ Bell" <siegebell@gmail.com> Subject: Reducing interruption latency for feedback-loop To: darwin-dev@lists.apple.com Message-ID: <64e20a610702070958r3c7624cjdb4ad1502f05ee17@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed I'm trying to get a feedback-loop for a digital-analog converter running at 40 kHz (or faster). Ideally, I would like to respond to each sample as it comes and not let any back up. This is essentially what I have so far: thread_priority_set(...) start while(running) { if(sample is ready) { read/write usleep(0); } } stop I have been able get it to run for 24 sec with only 100 to 200 interruptions that, each time, cause roughly 4 samples to back up -- on a 1.17 GHz dual-core G4, using a 3rd-party driver which communicates via PCI. Since the device-manufacturer doesn't yet provide PCI Express cards, I am unable to upgrade computers at this time. Using a multi-core computer, can I tell the scheduler to ensure that the thread runs uninterrupted (well, with interruptions limited to 30 or 40 usec in latency) on a CPU at all times? No. Yes. = Mike _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... I'm a little unclear as to what you're describing here, and particularly what you mean by "not let any back up". This implies that you are running in userspace, and since there are no hard realtime guarantees available to you, you must be prepared to tolerate delays of tens or hundreds of milliseconds. Any suggestions on how to reduce the interruption latency? Do your work at primary interrupt time, in the device driver's interrupt filter method. Is it necessary to work in the kernel to achieve what I'm looking for? Can I increase the granularity of usleep()? I'm not sure what you mean by "increase the granularity". As has been pointed out, usleep() is typically as precise and reliable as it can be on a given system. I don't think that's really relevant here though. This email sent to site_archiver@lists.apple.com