>From: Morten Due Jorgensen <[EMAIL PROTECTED]>
>Date: Fri, 27 Nov 1998 09:53:05 +0100
>Subject: Mersenne: Priorities (was RE: any large groups that run GIMPS
software on corporate computers?)
>
>>The claim US WEST is making, or made since I doubt they still believe it,
is
>>that the software itself, in the process of all those fun FFT
calculations,
>>was tying up the processor. We all know it only takes idle time, but when
>>you look at performance monitor in NT, all you see is that NTPRIME.EXE is
>>taking between 90-98% processor time, so they assumed it was hogging the
>>processor. Needless to say, the US WEST folks don't quite understand that
>>it doesn't take CPU time from other processes, only the idle process. Oh
>>well...sigh...
>
>I would like to comment on that. I have been doing some experiments on
this, using a program of my own (Neural network training of Backgammon) that
I wanted to run on my PC at home at any time without interferring with my
other tasks, just as Prime95. At home I run W98, and I have not tested this
on NT, but my observation is, that when two or more "busy" programs run at
various priorities ("busy" here meaning a program that can use all the CPU
it can get), the lowest priority program _will_ be given a small amount of
clock cycles, and thus in fact MORE than the available idle time. Given two
programs, one running at normal priority, the other at the lowest possible
priority (idle priority), the second program will get around 1-2% of the
CPU, while the first will take up ninety-some %, giving away only the
mandatory few % to other system tasks, the amount will rise as the priority
rise. (Luckily this is NOT the case for the built-in idle thread!)
>
>In the case of only one busy low priority program, like what is usually the
case with Prime95, and no other programs wanting to hog the CPU, it is not
easy to tell, whether these other programs actually are delayed because of
the low priority program, but in this case, I claim that it simply doesn't
matter, since the programs are not "busy" anyway. However, if the other
programs have enough to do, they will still need to give away a little to
the idle priority program. With the 1-2% as seems to be the case, it will
appear to be a P98 instead of a P100, you're running...
>
>I don't know, why Microsoft has chosen to implement their multitasking like
this, but a fair guess would be that it is not desireable to prevent even
low priority program from being totally halted, because it would prevent
them even from being shut down gracefully, while other busy programs were
running. Those of us being fortunate enough to have tried out the good ol'
Commodore Amiga will remember that on those machines, a low priority task
would indeed be halted until CPU was available. The housekeeping of cycles
were much more strict. (Please do NOT send PC vs Amiga mails to the list
now, let's keep it on topic.)
>
>Like I said, these are observations on W98, someone else would perhaps do
some experiments on NT?
OK, here is how it works in NT. There are 31 priority levels for processes
in NT; this range is divided into subranges for Idle, Low, Normal, High and
Realtime priority tasks (I would need to go home and look up how exactly
that is done, but if I remember correctly, anything above 16 is Realtime, 0
and 1 are Idle etc...).
The priority determines how likely the process will get some CPU time. The
NT scheduler can give these processes boosts in their priority. That is done
for example when you switch between applications - the foreground app gets a
boost of 2 points on the priority scale (at least in the default setting of
NT WS - "maximum foreground boost" in the system properties control box).
[Technically, of course, it is the main thread of this particular app who
gets the boost, from "normal" to "above normal" or "highest" for example,
but I did not want to cover the entire mechanism here - would be slightly
off topic. My sloppy use of the word "process" stems from the same
reasoning.....]
In order to prevent any process from "starvation" (i. e. the process gets
never any CPU resources since it has a low priority and there are other
processes with a high priority running at "full throttle"), the scheduler
will give any of these low priority tasks an occasional priority boost.
Hence indeed prime95 can have a (low)performance impact (let's say you're
doing some numbercrunching/rendering overnight - then prime95 will still get
some CPU cycles due to the described effect).
Hope that is enlightening
Martin
