AMD or Intel?

On Fri, 21 Oct 2005 15:57:59 GMT, kony wrote:

Commit Charge Peak is the relevant entry in Task Manager.
If (hopefully) your ram exceeds that figure, a large part of
the remainder is used for file caching- another very useful
purpose.

I ran some tests with Shrink. Here are the results:

1) After reboot, before Shrink:
Mem Usage: 147480
Commit Charge Peak: 150388

2) While Shrink is running (~50% done):
Mem Usage: 255308
Commit Charge Peak: 262264

Total Processing Time: 24 min 44 sec

3) After Shrink is closed:
Mem Usage: 167948
Commit Charge Peak: 282472

I have screenshots of Task Manager Performance page if you need more
detail.


--

If you build a man a fire and he will be warm for a day. If you
set a man on fire, he will be warm for the rest of his life.

On Fri, 21 Oct 2005 18:06:28 GMT, kony wrote:

Compare your Commit Charge, Peak, to the amount of RAM in
the system. If it comes near or exceeds physical ram you
would benefit from more for the *moments* it does exceed...
which could be very often or only rarely, a careful watch of
Task Manager would be needed to better detemine the Commit
Charge Total at any moment (like during DVDShrink(ing)
something).

I ran the tests and posted the results separately in this thread.


--

If you build a man a fire and he will be warm for a day. If you
set a man on fire, he will be warm for the rest of his life.

On Fri, 21 Oct 2005 20:27:13 GMT, (Bob) wrote:

On Fri, 21 Oct 2005 15:57:59 GMT, kony wrote:

Commit Charge Peak is the relevant entry in Task Manager.
If (hopefully) your ram exceeds that figure, a large part of
the remainder is used for file caching- another very useful
purpose.

I ran some tests with Shrink. Here are the results:

1) After reboot, before Shrink:
Mem Usage: 147480
Commit Charge Peak: 150388

2) While Shrink is running (~50% done):
Mem Usage: 255308
Commit Charge Peak: 262264

Total Processing Time: 24 min 44 sec

3) After Shrink is closed:
Mem Usage: 167948
Commit Charge Peak: 282472

I have screenshots of Task Manager Performance page if you need more
detail.


No that is enough, your 512MB is plenty for that job. Now
if you were shrinking while doing OTHER things too, of
course you would have to check it again for the higher Peak.

Generally the best way is to use the system *normally*
(perhaps a little aggressively) for a couple days without
rebooting then see what the Commit Charge Peak was. Leave
at least a few dozen MB margin for caching. Sometimes that
Peak is not so obvious if there are odd jobs, for example
the system one system I used to scan and touch-up a document
before faxing, rarely uses over 300MB but during that job it
went over 700MB.

On Fri, 21 Oct 2005 20:57:18 GMT, kony wrote:

I ran some tests with Shrink. Here are the results:

1) After reboot, before Shrink:
Mem Usage: 147480
Commit Charge Peak: 150388

2) While Shrink is running (~50% done):
Mem Usage: 255308
Commit Charge Peak: 262264

Total Processing Time: 24 min 44 sec

3) After Shrink is closed:
Mem Usage: 167948
Commit Charge Peak: 282472

I have screenshots of Task Manager Performance page if you need more
detail.

No that is enough, your 512MB is plenty for that job. Now
if you were shrinking while doing OTHER things too, of
course you would have to check it again for the higher Peak.

The profile above is for my typical background load. Because Shrink
hogs the CPU - it runs at 100% according to Task Manager - I have
practically no CPU power left to do anything. And the same is the case
for my son on his 3.2 GHz P4 Prescott with 1 GB RAM.

Shrink does have a provision for lowering the priority and of course
so does Task Manager. But this test was run full bore.

Generally the best way is to use the system *normally*
(perhaps a little aggressively) for a couple days without
rebooting then see what the Commit Charge Peak was. Leave
at least a few dozen MB margin for caching. Sometimes that
Peak is not so obvious if there are odd jobs, for example
the system one system I used to scan and touch-up a document
before faxing, rarely uses over 300MB but during that job it
went over 700MB.

Since I keep Task Manager in the tray, I consult it often especially
when I notice performance degredation. Windows is notorious for memory
leaks (either itself or permitting apps to leak memory) and if I let
too much leak, performance deteriorates rapidly. So I am on top of the
issue you discuss above.

DVD Shrink is the only application that not only heats up my CPU to
the highest temps on record for my system - even more so than the
stress test you recommend (I forgot the name) but it is the only
application that also heats up the so-called "motherboard" temperature
and also the hard disk. No other application, DVD or otherwise,
including the one you recommend, heats up the motherboard temperature
or the hard disk temperature anywhere near as much as DVD Shrink.

I have no idea why that happens. But it happens every time. I have had
to raise the limits in MBM5 several times or else I get an alarm.
Admittedly I have the alarms set lower than the critical temperatures
associated with those probes, but the levels I chose held up well
until I started using Shrink.


--

If you build a man a fire and he will be warm for a day. If you
set a man on fire, he will be warm for the rest of his life.