Re: Pinning IO Thread to a particular processor
Re: Pinning IO Thread to a particular processor
- Subject: Re: Pinning IO Thread to a particular processor
- From: Jeff Moore <email@hidden>
- Date: Wed, 8 Feb 2006 12:23:24 -0800
On Feb 8, 2006, at 9:28 AM, Stefan Haller wrote:
Stefan Haller <email@hidden> wrote:
Jeff Moore <email@hidden> wrote:
It tells me that your IOProc is right out there on the edge of using
all the available time in these cases. I'd be very curious to see
how
these compare to the cycles that don't overload.
I'm not at the office tomorrow; I'll try to collect some more data on
Friday.
OK, it took me some more time. I hope you still remember what this
was
about. :-)
Yup. I remember!
I have put a couple of new screenshots on my web site.
<http://home.snafu.de/stk/tmp/1_CPU.png> shows the telemetry window
with
only 1 active CPU. I didn't get any overloads this time.
The telemetry shows a cycle that's 128 frames in duration or ~2.9ms
assuming a 44.1k sample rate. Both open cycles are consistent with
each other and the others around them. They show the IOProc taking
~2.2ms and the overall cycle taking ~2.3ms. The scheduling latency is
bouncing around between ~20mics and ~45mics, but that's still in the
mostly harmless range.
Everything looks within spec, although the IOProc is edging into the
danger zone. All it takes is one bad scheduling latency or a spike in
it's processing and it will overload.
<http://home.snafu.de/stk/tmp/4_CPUs_Overview.png> shows the telemetry
with 4 active CPUs.
Yup. Lots of overloads, but not a whole lot of information about why,
although it clearly isn't due to scheduling latency which looks to
be better than the single processor run.
<http://home.snafu.de/stk/tmp/4_CPUs_Detail.png> shows the same, but
with some of the entries expanded.
This one shows that the overloads are due to the driver returning
kIOReturnIsoTooOld from the write-the-output kernel trap. One
interesting point you can see though is that when the driver is
returning this error, the IOProc is taking 200mics longer than it
does when the driver doesn't return this error. This tells me that
your processing code is doing something extra here.
That said, the kernel trap is being called at pretty much the same
time in the IO cycle in the 4 CPU case (~2.25ms) as it is in the 1
CPU case (~2.29ms). This tells me that the driver is being
inconsistent here.
(It would really help to be able to save and load logs, like in
Shark...)
True.
<http://home.snafu.de/stk/tmp/HALLab_Latency_Trace.txt> is the latency
log that was taken at the 4 CPU test.
The trace doesn't show anything unusual, aside from the long running
IOProc. There aren't any VM faults or other blocking as far as I can
tell.
To recap, the test document was a Live set that created about 77%
audio
load, buffer size was 128 frames, using built-in audio.
The telemetry backs up your estimation of the audio load of your IOProc.
Let me know what other information I can provide to help track this
down.
While the telemetry does show that your IOProc is spiking in the 4
CPU case, it seems pretty clear when comparing it against the 1 CPU
case that the driver is being inconsistent when reporting
kIOReturnIsoTooOld from the kernel trap.
Stefan, I think that you should file a bug. You should be sure to
include the telemetry and can feel free to quote my analysis.
--
Jeff Moore
Core Audio
Apple
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden