site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com User-agent: Microsoft-Entourage/10.1.0.2006 So if latency doesn't show anything worse than 200us and yet our time stamp has a delta off by 5+ ms, any ideas? Our PC developers say that this looks like a PCI controller issue that they've seen where the DMA requests from the card don't get honored. The card doesn't reissue the request (no buffer, if it doesn't get the data, it's too late to retry) causing the input and output DMA engines to get out of sync with each other. Since a fundamental assumption of our driver (and many CoreAudio applications) is that the input and output are locked together, we only have one time stamp, driven from the input interrupt. If the DMAs get out of sync, our time stamp will be wrong, and we're up the proverbial estuary without a means of locomotion. I've filed a Radar issue on this, but not gotten any response to it. Thanks, Mark -- Mark Cookson M-Audio, a division of Avid 225 Locust St. Hudson, WI 54016 On 12/3/04 1:14 PM, "Godfrey van der Linden" <gvdl@apple.com> wrote:
You could try latency -it, it will tell you if some other process is blocking interrupts for too long.
Godfrey
On Dec 3, , at 9:11, Mark Cookson wrote:
I'm trying to track down an issue where it appears that our PCI card's primary interrupt is delayed (in some cases more than 9 milliseconds) from when I would have expected to have seen it.
Since we make audio hardware, our driver needs to give accurate timing information to CoreAudio. We do that by calling clock_get_uptime() from our primary interrupt. More specifically, we check that it was our card generating the interrupt, if it was, call clock_get_uptime, then clear the interrupt, and return "true" so that our secondary interrupt handler gets called. The secondary interrupt is when we actually post the time collected by the primary interrupt routine.
We are logging the delta between these time stamps (via HALLab) and see them coming very regularly, as expected, except that on occasion on the new 1.8 GHz G5 with PCI slots (as opposed to the original 1.8 GHz G5 that had PCI-X slots) we see the delta grow by a very large amount, up to 9ms in one case.
I believe it is this rogue time stamp that is causing our problems, but since the time stamps are directly related to the primary interrupt, it seems that something is preventing our primary interrupt from running.
Any ideas about how I could track this down further?
_______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... This email sent to site_archiver@lists.apple.com