Earle Goodman <[EMAIL PROTECTED]> writes:
> The problem occurs when:
> 1) There is have enough stuff running to fill up the physical memory
> 2) The applications running take up a good portion of the CPU (30-60%?)
>
> This allows enough CPU time that some is given to the "idle" process, but
> there is enough activity that swapping has to occur and that the other
> applications can run noticeably slower.
I'm not surprised.
One thing that can definitely happen is when other tasks use short
timeslices i.e. give control back to the scheduler when waiting for
an event expected to occur a very short time in the future. Then the
scheduler has to start another process - this can take a while. If
the process is badly written it may gain control, execute a few
cycles & surrender control to the scheduler again. That way lots of
the CPU power goes into context switching, leaving less for user
processes. Even high-priority ones.
HOWEVER there just Ain't No Way in which anything like this would
cause 5 seconds to turn into 5 minutes. Swap thrashing *might*, but I
think people would notice...
I suspect that what's happening with the compiler/debugger is due to
an overactive process scheduler. Especially regarding the debugger.
The "culprit" would be just *any* other process wanting to execute -
irrespective of priority, CPU intensiveness or otherwise - Prime95
would be one of the easier processes to "tolerate" since it runs at
such a low priority that it will always yield to anything wanting
CPU time. *It's the task switching that's the problem, not what the
task being switched to is doing*. If you don't believe me, write a
task which just loops, this will have almost zero memory requirement,
execute this at idle priority & you'll find you're hit in the same
way.
If you had "genuine" contention for the CPU (enough processes running
so that the idle tasks rarely if ever got CPU cycles) then running
the idle task would make very little if any difference to the
execution speed of the foreground tasks. Irrespective of memory
requirements - if the memory overloaded then the idle task would swap
out & remain out of physical memory until the scheduler picked it
again.
You *may* be able to improve the situation by fixing the scheduler
parameters - e.g. increasing the MINIMUM cpu slice so that the
scheduler is less active - this causes foreground tasks to run
faster, they are able to exploit the cycles which the scheduler isn't
wasting by intervening too often.
However the strategy you have adopted seems sensible.
The alternative would be to manually stop the Prime95/NTPrime process
if/when ultimate performance is required & start it again afterwards.
Phil Brett writes:
> >
> > Some ( humble ) sudgestions :-
> >
> > 1) The prime server takes into account the RAM available ( setable in
> > Prime95 ? ) when dishing out work.
> >
> > 2) Prime95 somehow backs off for a few minutes if memory gets low
> > to let the
> > swapping sort itself out.
> >
> > 3) George finds a way to reduce the memory requirements ( not likely with
> > the same speed I admit )
I don't think either of (1) or (2) would be effective, for the
reasons I've outined above. As for (3), I'm sure George would welcome
any suggestions as to how this might be achieved. I reckon he's
already done a pretty neat job of stowing quarts in pint pots.
> > Good luck Aaron in your battles.
Agreed!
Brian Beesley
