[Laurence]

I set one process (Seti@Home) to +20 and another process (QT) to -20. I would expect that this would prevent Seti@home from doing anything unless QT was not trying to do something.... It doesn't work!

No matter what priority I give a process I can't make it so that the process doesn't take processor time unless nothing else is using the processor. Does anyone know why this is, or even better, a resource that would explain it in greater detail?

I have started AE, FCP, FFMPEG, QT all rendering at once and still a background process set to the lowest priority possible still takes CPU cycles. This doesn't seem to be the way it should work.

Any ideas?

[larkost]

If you are looking for them to take 0 processor cycles, then nicing them will never do this. The scheduler looks at a few things when dolling out processor time: priority, how long it has gone without cycles, I/O issues, and a number of performance metrics (trying to make the best use of the time).

Once a process has waited a while it gets processor cycles simply because it has waited a while. This means that every process gets cycles, the lower priority ones just get less (assuming that everything else is equal... never a good assumption, but a good rule of thumb).

Oh... and with the stuff you are talking about... they are often I/O bound, and usually run into that performance profiler...

[OreoCookie]

First of all, you shouldn't assign a nice value of -20 to any process unless you exactly know what you are doing. renice(ing) a job with a nice value of 2-4 will speed up the responsiveness of UI elements tremendously if you have something cpu intensive (e. g. I have several scripts that convert images using image Magick, and I have set a nice value of 3 which is good enough to use other applications with little performance impact.

On the other hand, if you encode videos with quicktime, a nice value of 10 (for SETI) would suffice to have both running at the same time.

[rkt]

it's all a bit hazy, but i'm sure i remember something about this before... iirc it went something like this:

on linux nice'ing something to -20 should tell the system to run the process real-time; this doesn't happen on macosx neé darwin, because of the special relationship between the bsd-layer & the mach-layer. to get processes to run "real-time" then you have to do it using mach-threads and request special performance priorities.

or something.

[larkost]

rkt: I am not aware that the linux scheduler works that way. I think that you might have heard someone say that it effectively is real time, but true real-time is possible only when the scheduler gives out fixed amount of cycles to certain processes, and usually requires a very low latency (implying a low time granularity which tends to kill thru-put).

There are semi-realtime schedulers for linux available as patches, but true realtime usually requires a RTOS... and that comes with a lot of sacrifices that would be silly for a desktop OS.

MacOS X does have a number of provisions for low-latency code, especially when it comes to the sound system (where it is usually the most critical) that perform nearly as well as real-time, but that is not part of the 'nice' system.

[OreoCookie]

But you shouldn't tinker with processes and make them `real time', it messes up the whole system. Definitely not for applications.

[rkt]

@larkost:

indeed, my post had slightly bad wording. it would have been better to say "/requests/ the process to have realtime priority", as it's up to the underlying system whether or not it can actually deliver this. as you correctly point out most systems are not realtime, so this doesn't actually happen.

however my point still stands, nice on darwin doesn't perform in the same way as you'd expect from other systems. setting a low nice value isn't going to give you the exact effect Laurence asked for ("No matter what priority I give a process I can't make it so that the process doesn't take processor time unless nothing else is using the processor"). I think this is only possible using mach threads directly.

this explains a bit further:
http://developer.apple.com/technotes...ernelThreading

[OreoCookie]

Originally posted by rkt:
@larkost:

indeed, my post had slightly bad wording. it would have been better to say "/requests/ the process to have realtime priority", as it's up to the underlying system whether or not it can actually deliver this. as you correctly point out most systems are not realtime, so this doesn't actually happen.

however my point still stands, nice on darwin doesn't perform in the same way as you'd expect from other systems. setting a low nice value isn't going to give you the exact effect Laurence asked for...

Well, you can assign negative nice values as root anyway ...

[rkt]

Originally posted by OreoCookie:
Well, you can assign negative nice values as root anyway ...

sorry, don't understand what you mean...?

[OreoCookie]

Originally posted by rkt:
sorry, don't understand what you mean...?

A normal user can only increase priorities using nice, and priorities below 0 are only accessible to root, and that's not a coincidence. So it doesn't matter whether or not a process with priority -20 isn't real time, QuickTime isn't supposed to run as real time.

So, bottom line, keep QT at priority 0, don't tinker with negative priorities, unless you know what you're doing.

(BTW, if you want to have fun with windows (at least 2k), any user can set the priorities with the task manager. Try running word in real time and use another app )

[Laurence]

I do realize that renicing anything to -20 is not recommended... I was only doing this while testing what was going on.

The problem I have is that something like seti@home should not be using a significant amount of the processor time when other tasks need the time. I also realize that this is a specific limitation of the OS X version of the seti client and I was just seeing if there was a workaround that could be utilized. (The seti team has stated that the processor arbitration routines or something like that aren't implemented on the OS X version at this time)

In my further testing I had three processor intensive apps running (ffmpeg, after effects, and QT) running and they were relitively evenly sharing the processor (something like 30, 35, 32) with the window server and miscelaneous processes using around 2-3%. When I started the seti@home process (which by default runs at proority 19) it started taking about 8-12% of the CPU. This seems wrong to me. When I began renicing ffmpeg, QT, & AE down (approaching -20 a few steps at a time) and bumping seti up to +20, the seti process was possibly using a little less processor time, but not much... around 7-11 or so.

I don't really care, as it is not like I'm always stressing the processor like this, but It just seemed kind of strange that there doesn't seem to be a way to limit a process more precisely than this.

[OreoCookie]

Originally posted by Laurence:
I do realize that renicing anything to -20 is not recommended... I was only doing this while testing what was going on.

The problem I have is that something like seti@home should not be using a significant amount of the processor time when other tasks need the time. I also realize that this is a specific limitation of the OS X version of the seti client and I was just seeing if there was a workaround that could be utilized. (The seti team has stated that the processor arbitration routines or something like that aren't implemented on the OS X version at this time)

In my further testing I had three processor intensive apps running (ffmpeg, after effects, and QT) running and they were relitively evenly sharing the processor (something like 30, 35, 32) with the window server and miscelaneous processes using around 2-3%. When I started the seti@home process (which by default runs at proority 19) it started taking about 8-12% of the CPU. This seems wrong to me. When I began renicing ffmpeg, QT, & AE down (approaching -20 a few steps at a time) and bumping seti up to +20, the seti process was possibly using a little less processor time, but not much... around 7-11 or so.

I don't really care, as it is not like I'm always stressing the processor like this, but It just seemed kind of strange that there doesn't seem to be a way to limit a process more precisely than this.

8-12 % sounds just about right, it does what it is supposed to. It's expected behavior, if you want to actually stop the process, then you should do things differently. 8-12 % isn't that much to really notice it.

[Richard Edgar]

It would seem that the command you're seeking is kill (or kill -STOP).

[larkost]

To expand on OreoCookie's point, this is because those other processes take time off to refill buffers, end since you are running them all at once you are really reducing the buffer size that each has to to work with. In comparison SETI@home has a fairly complex operation to perform on a relatively small data set, so it is not as buffer dependent, thus it will run efficiently with the extra time.

Everything is working exactly as it should...

[rkt]

Originally posted by OreoCookie:
A normal user can only increase priorities using nice, and priorities below 0 are only accessible to root, and that's not a coincidence. So it doesn't matter whether or not a process with priority -20 isn't real time, QuickTime isn't supposed to run as real time.

well yeah, i wasn't suggesting it, just answering the original question...