View Full Version : System monitor on Windows 95
TVC15
12-21-2000, 06:50 AM
I am currently doing a college project about the effects of upgrading the memory and processor of an old PC. The scenario is as follows:
I have an old IBM with a 486 DX-33 processor, 8 MB RAM and Windows 95 installed. What I did was run system monitor tracking the following threads:-
1. Processor % usage
2. Page faults per second
3. Page outs per second
I then ran an Excel macro which inserted a large piece of word art on the screen and then copied it into another 40 sheets. Once it had finished, I saved the system monitor results.
I then performed the same test using the same processor, but with 32 MB memory. Then I replaced the processor with an Evergreen AMD 133 and performed the same tests, first with 8MB and secondly with 32 MB.
The results I recieved with regard to the processor were largely what I expected. With regard to the other 2 indicators, however, there were some things which I don't understand. The results were as follows:-
With 32 MB there were no Page outs for either chip. With 8MB the pattern was almost the same for each chip. (as I would expect)
It is the page fault result I am having problems with, however. Basically, it remained constant for each chip, and did not appear to be influenced by the amount of memory. What was also surprising was that it was twice as high for the AMD chip compared to the DX-33.
Can anyone explain this to me?
Cheers,
Andy
scada
12-21-2000, 08:27 AM
Since this is a homework project I won't give you the answer but I will give you a hint.
Pages\out tells you how many hard page faults have occured. IE: pages are read TO disk.
Pages\sec tells you about ALL paging. IE: reading pages from non-cached memory.
Now why would a 133 "pentuim" have more pages\sec than a SLOWER chip?
hmmmmmm......
Good luck http://www.PCGuide.com/ubb/smile.gif
[This message has been edited by scada (edited 12-21-2000).]
TVC15
12-21-2000, 07:08 PM
I think I might have to go "phone a friend" on that one.
Seriously, though, many apologies for being dumb but could you please provide me with the correct answer. I realise that this is merely a short term solution to my problem (ie enough to get my assignment done) but I'm afraid that is as far as my outlook on life runs. After all, did not John Maynard Keynes say that in the long run we are all dead?
scada
12-21-2000, 11:23 PM
Ok First I'll assume that your trying to see what effect extra memory will have on access to the swap file by tracking page faults.
The first thing to remember is that there are 2 types of page faults.
Hard page faults and soft page faults. A page fault occurs whenever data or code isn't in a process's working set. A hard page fault means that a page was moved in (to a working set) from the hard disk. A soft page fault occurs whenever a page is moved in (to a working set) from a memory location that isn't a part of that working set. Notice that you track pages out/sec this counter will increase when a working set is trimmed. (IE: pages are moved out to disk to recover memory.)If there is plenty of memory then working sets are NOT trimed. This is why as you add memory the values for this counter go down. However this does not mean that paging activity has stopped.The working sets could be increasing in size. In other words pages out/sec is only part of what pages/sec counts. Notice now that you are not tracking hard page faults or pages in/sec.(I'll assume that Win9x has the same sort of counters as WinNT but the names may be different) This counter would proably show that working sets are being increased (in size) by reading data in from disk.In other words as you used Excel the working sets grew in size. Over time if you accessed the same data the pages would be keep in the file system cache and pages in/sec would drop.( Hard faults would drop but soft faults might not and therefore pages/sec might also stay steady). So as you can see pages/sec is not a good indicator of a memory bottleneck,but should be used with other counters to check system performance.
As to why the 133 chip has a higher count then the DX. That would be because the 133 is simply a faster chip and can access more pages in less time than the DX.
I hope this explains things somewhat better. Most people would check the performance of critcal computers (app. servers,web servers, or database servers) and not Windows 95. Which is why it doesn't have all the counters that NT/2000 has. And frankly I have never used 95's performance counters before. So most of my talk is about win32 processes that should be the same for any Windows OS.
Good luck http://www.PCGuide.com/ubb/smile.gif
kenja
12-26-2000, 11:02 PM
Thanks for the explanation, scada. I hadn't quite grasped the concept of page faults before.
scada
12-27-2000, 09:40 AM
Glad you got something out of it. But I did make one mistake.
I had assumed that Pages/sec was the samw as Page faults/sec. It isn't. Here's the correct information.
Pages/sec counts BOTH pages in/sec and pages out/sec. In other words whenever data is moved out to disk or in from disk.
Pages faults/sec tracks Both hard and soft pages faults.
The points I made in the first post are still valid. That pages out/sec is only part of what pages/sec counts and that he'll want to track pages in/sec to get a better idea of memory usage. But I was wrong in saying that pages/sec counted SOFT page faults.
Hope this doesn't confuse anyone http://www.PCGuide.com/ubb/smile.gif
vBulletin v3.6.1, Copyright ©2000-2012, Jelsoft Enterprises Ltd.