hey, we're getting real data out of this discussion :-)
At 21:54 16.09.98 -0500, Ken Kriesel wrote:
>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.
Me too....at least there is *some* effect that is larger than the
priority setting should account for.
I reported earlier on the strangeness that a GPS receiver would get
fewer satellites when NTPrime was running than when it was not; I suspect
that the problem is interrupt latency being longer when NTPrime has
the cache and the page tables than when the idle loop has it.
Or possibly a paging problem - see below.
>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...)
and would make it stop dead on my NT Pentium box, which is chugging along
decently, but routinely runs a "commit charge" (I think that's NT's version of
"virtual memory allocated") of 128 MBytes in 64 Mbytes physical.
My feeling (NOT knowledge) is that lots of Microsoft DLLs are *huge*,
get loaded into virtual memory, but have a very small working set in
normal usage; the exotic functions simply don't get called.
(BTW, NTPrime's VM size here is 4.8 Mbytes according to Task Manager)
Just theorizing....
Harald A
--
Harald Tveit Alvestrand, Maxware, Norway
[EMAIL PROTECTED]
