Re: Coreaudio-api Digest, Vol 6, Issue 134
Re: Coreaudio-api Digest, Vol 6, Issue 134
- Subject: Re: Coreaudio-api Digest, Vol 6, Issue 134
- From: Jeff Moore <email@hidden>
- Date: Tue, 17 Mar 2009 11:12:33 -0700
From that backtrace, it seems like there is a lot of sleeping going
on. Some of it looks lock related, but some of it also looks like
waiting. I don't know enough about the network stack to say if this
would be considered a bug or not, but it never hurts to file one and
find out.
At any rate, I think your best bet is to also follow up with one of
the more network and/or kernel focused lists (darwin-dev might be a
good place) or to get in touch with our Developer Support folks.
On Mar 17, 2009, at 2:44 AM, Stéphane Letz wrote:
Message: 3
Date: Mon, 16 Mar 2009 11:26:31 -0700
From: Jeff Moore <email@hidden>
Subject: Re: Socket recv behaviour in real-time context
To: CoreAudio API <email@hidden>
Message-ID: <email@hidden>
Content-Type: text/plain; charset=iso-8859-1; format=flowed;
delsp=yes
On Mar 16, 2009, at 10:23 AM, Stéphane Letz wrote:
Well the RT thread is not disturbed by other RT threads! The high
latencies I can see occurs already when a *compilation* is done. I
could record several latencies peaks (like 9,2 ms or 18.4 ms) using
Shark with an audio network process that runs at 256 frames / 44.1
(so a period that should be about 5 ms.) The system call that has
the long wait time is "recvfrom_nocancel" and is interleaved with
system calls related to the compilation.
Hmm. It sounds like you have some part of your your work being done
by
either one thread with a large work queue or just a plain low
priority
thread. It could also be that there are occasional blocks in the
system calls. You'd need to do a little more digging into the
problem.
Since there are latency peaks, you might want to also do a time
profile trace to see if you can see what was going on during those
latency peaks.
Using the "latency" tools, I don't see any abnormal scheduling
latency for the RT thread.
Using the Shark "time profile" trace show this call stack for the
"recvfrom_nocancel" function:
0.3% 28.9% mach_kernel recvfrom_nocancel
0.3% 27.5% mach_kernel socketpair
4.0% 24.4% mach_kernel soreceive
0.3% 10.6% mach_kernel sbwait
0.0% 10.0% mach_kernel msleep
0.0% 10.0% mach_kernel uiomove
0.0% 9.7% mach_kernel lck_mtx_sleep_deadline
0.0% 7.7% mach_kernel thread_block
0.0% 7.7% mach_kernel thread_block_reason
7.7% 7.7% mach_kernel ml_set_interrupts_enabled
0.0% 1.4% mach_kernel assert_wait_deadline
0.0% 1.4% mach_kernel wait_queues
1.4% 1.4% mach_kernel ml_set_interrupts_enabled
0.6% 0.6% mach_kernel lck_mtx_lock
0.3% 0.3% mach_kernel thread_block
0.3% 0.3% mach_kernel _mutex_assert
So it may be a lock or priority inversion of some functions used in
kernel mode? It this trace enough to do a bug report?
--
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