info-vax@ucbvax.ARPA (05/01/85)
From: engvax!KVC@cit-vax VMS V4 does indeed suck up more memory than an equivalently configured V3 system. However, when the system is NOT memory limited there really isn't much difference in performance between V3 and V4. Some things may be slower and others faster, but on the whole my subjective impressions of response time are no different. My system (ENGVAX) is an 8Mb., moderately loaded, 785 (used to be a 780). Under VMS V3, we almost always had quite a bit of memory left over. Now we are usually within a few hundred pages of using it all (we have more on order). A moderately loaded 750 with 5 Mb that I've worked with quite a bit also displays no real performance difference between V3 and V4. Another 780 that I know of has only 4 Mb and a heavy user load. System response appears MUCH slower than V3 since the system spends a lot more time paging to disk than before. Unfortunately, they've also got an old controller and little or no money to upgrade it. Memory requirements on ENGVAX look to be about 1000 to 2000 more pages than under V3 (0.5 to 1.0 Mb). Again, I have no hard evidence for these numbers, just feelings of what I remember from SHOW MEMORY. /Kevin Carosso engvax!kvc @ CIT-VAX.ARPA Hughes Aircraft Co. ps. Now that VMS V4 has been out for a little while, you can be certain that there will be a lot of people at DECUS next month who will have a lot to say about it. Hopefully, we can all look forward to some real performance data.
info-vax@ucbvax.ARPA (05/02/85)
From: sasaki@harvard.ARPA (Marty Sasaki) When we went from version 3.7 to version 4.0 of VMS the kernel used up 70% more memory. We fortunately have 8Mbytes, but I could see some problems with a smaller system. My subjective impression is much like engvax!KVC@cit-vax's, overall there isn't much change. However, there are times when things do seem to slow down considerably. This seems to be due to two things: 1) I haven't had the experience with V4.0 to really do a good job on tuning the system, experience I did have (and used extensively) on V3.x, and 2) there are occasionally degradations having to do with the disk ACP being part of the user's address space and not a separate process. I have been told that the second problem shows up because the disk handling is accomplished at the process's priority rather than at the ACP's priority in V3.x systems. The ACP usually ran at a higher priority than user processes, and could usually finish an i/o request without interruption. Such interruptions are more likely on V4.x systems. I have to admit to not totally understanding this explanation. Marty Sasaki (sasaki@harvard.arpa)