Re: Ioproc Scheduling Behavior
Re: Ioproc Scheduling Behavior
- Subject: Re: Ioproc Scheduling Behavior
- From: Jeff Moore <email@hidden>
- Date: Tue, 16 Mar 2010 23:47:14 -0700
On Mar 16, 2010, at 11:08 PM, Chuck Carlson wrote:
>
> We have an architecture that has the ioproc sending audio via udp to a dsp thread in another process on the same machine (might be on another machine in the future). The ioproc then waits in a socket function for the processed audio from the other process.
>
> After startup, the system has mediocre performance as we increase the load on the dsp thread. That is, at about 60% load on one cpu of a C2 Duo, audio dropouts happen. But when we run Shark on the system, we can kick the system into great performance and can run 95%+ of one cpu. The jump in performance happens when Shark starts processing it's data after collection and remains after Shark is exited.
>
> So, we've got some learning to do about thread scheduling so we can get this great performance without Shark.
You are probably getting hit by the speed stepping of the processor due to your usage pattern.
> So I'll ask some questions that may get us started, feel free to ask for more info.
>
> I read on this list that HAL adjusts the real time constraints on the ioproc based on history of usage. So, does waiting in a socket affect this scheduling, as the thread may not be consuming the cpu cycles that HAL has allowed for it but is using most of the sample frame time?
The HAL only cares about wall clock time. It doesn't really care at all about how many cycles are used. Whether you are waiting or are performing a calculation, it all still consumes the same wall clock time from the HAL's scheduling point of view.
> Is there a way to know what the drop-dead time is for the ioproc?
Not really. While the IO cycle allows for an amount of time equal to the IO buffer size, this time is shared with the overhead in the driver (e.g. the float-to-int conversion) and the overhead in the HAL itself. Plus, depending on the app environment there could also be other IOProcs. So you don't really have all of that time in your IOProc and knowing how much you do have is situational.
> If we knew this, we could use a timed wait socket call. How would this affect ioproc scheduling?
If you must block on the IO thread, you should always use a call that will time out. The timeout value should be a conservative estimate of the most time you think you will ever take while still meeting the deadline.
> When I call thread_get_state in the ioproc, I am seeing that it is set preemptable. The Mac OS X Internals book by Singh says that thread_get_state cannot be called on the current thread so this might not be valid info. Is the ioproc ever scheduled non preemptable?
Not at the moment, but there are no guarantees that it will stay that way.
> The priority of the dsp thread is set using the mach real time constraints by the CAPthread class. The dsp thread also uses socket calls to wait for packets so it is sleeping in the kernel while it waits. Should the real-time constraints be reset at any point, like before or after a socket call? And again, Singh says that thread_set state can't be called on the current thread so this may need to be done elsewhere.
>
> Any other good books, docs I should look at?
The HAL only adjusts the scheduling parameters of it's IO thread when something, like the IO buffer size, changes.
--
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