Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: scheduling question

Hi,

On Wednesday, Jan 14, 2004, at 22:05 Europe/Berlin, Jim Magee wrote:

There are "helper" threads that process the data within the in-kernel network code somewhat isolating your thread from directly accessing the network hardware in that way. Your realtime thread may even interfere with the responsiveness of these helper threads in ways that might affect your own data. Even if you don't interfere with the processing of the in-kernel data, your response-time characteristics are going to be dominated by the scheduling behavior of these in-kernel threads. There are also situation where the network stack just borrows another user-level thread (that just happened to be in the network stack at the time) to drive completion of your packet handling (inbound and outbound). Obviously, you can't make these all realtime threads, so that too will affect your latency.

Are there other tweaks to enhance the latency of networking? I don't mind a decrease in throughput, I'm in one of the rare cases where bandwidth is not the limit. There are these popular "bandwidth tuner" tweaks where people change the system's TCP buffer size with sysctls, would shrinking the buffers give me any latency improvements or will that result in dropped packets?

The THREAD_PRECEDENCE_POLICY isn't really a completely different policy from the normal timeshare (migrating priority) policy on the system. It's just a way to control a key aspect of that policy. In essence, you are telling the schedule that, within this one process, some threads should have precedence over others even if they have the same priority. Essentially, you are assigning ordinal values to the process' threads without having to know or guess an appropriate system-wide priority for the threads. The system doesn't guarantee to honor it, but will attempt to do so (fairness may dictate that we chose threads to execute out of ordinal order). However, the effect should be process-local, and therefore cannot be relied upon to have any system-wide effect whatsoever.

So, using THREAD_PRECEDENCE_POLICY will only increase the priority of the thread within my process, but the priority of my thread will not be affected? If so, increasing the process' priority in addition should then give me the desired system-wide effect, I assume.

What has worked well for others in this type of situation is to use the THREAD_EXTENDED_POLICY notion to declare the thread as a "non-long-running" thread (by specifying the timeshare parameter as FALSE). As long as your thread is well behaved and gives up the CPU in reasonable amounts of time, it will always run at a fixed priority.

I think that's what one of the code snippets I tried is doing. I got that from someone on the CoreAudio list when I asked for low-latency scheduling tips.

One more question: If I change a thread's scheduling policy, will threads created from that one inherit that policy or will they have normal policy?

As such, it will have significant preference over other threads in the system that are (or have been) consuming large amounts of CPU time (and are therefore likely to get in the time way of reasonable timeliness).

The main competitor for my network thread is a CoreAudio thread with a number of processing-intensive AudioUnits. Well, it could be that some of the problems I have now on my development iBook disappear by themselves when we run it on the dual G5 it's intended to run on.

-Stefan
_______________________________________________
darwin-kernel mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel
Do not post admin requests to the list. They will be ignored.
References: 
 >Re: scheduling question (From: Jim Magee <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.