I can confirm from my own experiences that the working set and thrashing
that may result is an issue both for WindowsNT and for Windows95.
NT Services get woken up for about a 1% cpu duty cycle even when set to
lowest priority, on a system that is thoroughly saturated with other things
to do. This means the working set on a resource-hungry system must be
swapped back in frequently. I don't think there's anything that can be
done about that. ("It's a feature.")
Each thread gets a priority boost occasionally. Page 459 of the NTWS4
Resource Kit says it's "random". Priority can be kicked up from 1
(idle, the base priority of prime95) to 5 or higher for prime95 even
when there are several competing higher priority cpu-bound tasks, giving
each ready thread a base level of throughput that is typically 1% of the
cpu.
I suppose George could have prime95 begin in an idle state,
check how much free memory is available, launch an iteration only if the
amount is 5MB more than the estimated working set of Prime95, then check
every x iterations whether there's still 5MB free, and if not, write
results to disk, free memory, and revert to idle state. (But this would
reduce efficiency and increase code size a little more...)
My impression is that the problem at USWest was more related to the large
number of machines launched together and the resultant primenet server bugs
discovered, exhaustion of available exponents, & resultant repeated retry
by the USWest primenet client systems. It's easy to imagine their internet
connection not being ready to handle a few thousand cpus adding more
traffic atop the normal load.
Ken
At 07:21 PM 1998/09/16 +0100, "Phil Brett" <[EMAIL PROTECTED]>, wrote:
>Only one small point. I'm running NTPrime on a few machines ( with peoples,
>networks, my mum's permission ) and i've noticed a performance problem that
>users do notice. If the machine in question has, say, 32MB of RAM the
>percentage working set that NTPrime uses is quite high. My machine LL
>testing in the 5,700,000+ range is using 3,700K ish.
>
>I've ( and the users ) have noticed that this can cause mad swapping battles
>that slow the machine to a crawl. The affected machines now factor which has
>a much smaller working set.
>
>This can only get much worse as the FFT sizes rise.
>
>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 )
3) above is a possibility for those willing to run the double-checking with
alternate code that George has been considering implementing in the future.
Ken
