For the record I also have found that NTPrime will slow down machines. I do
believe that it does have to do with swapping (these are machines with 64M).
The two cases when it is mainly noticeable is while debugging and compiling.
I do not have exact numbers, but I would say if I compile with NTPrime
running it takes about twice as long, I could get empirical data if people
are interested. For these reasons at work I have used the NT Scheduler to
only run NTPrime at night time and on weekends.
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.
These are the type of things I have experienced...
Earle (George) Goodman
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Phil Brett
> Sent: Wednesday, September 16, 1998 11:22 AM
> To: [EMAIL PROTECTED]
> Subject: RE: Mersenne: Yikes!
>
>
> It looks like Aaron's been sha* on from a large height because of others
> ignorance ( isn't that always the case).
>
> 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 )
>
> Good luck Aaron in your battles.
>
> Regards
>
> Phil Brett
>
>
> >As you and I well know, NT Prime (I hadn't changed it's default priority
> >setting) runs at the lowest priority. I contend that the problems they
> >experienced on that particular day were due to the slow mainframe access
> >that the other programs were running into. It's happened before I put NT
> >Prime on, and it's no surprise that it was still a problem for
> them. Also
> >the problem only affected their machines in Phoenix, but NT
> Prime was also
> >running on machines in Omaha, Denver and Seattle, which had *no* problems
> at
> >all.
>
> >Thanks and sorry,
> >Aaron Blosser
>
>
>
