alan@drivax.UUCP (Alan Fargusson) (11/02/84)
I would like to know how System V rel. 2 compairs with BSD 4.[12].
We are running System V rel. 2 on a VAX with 4M ram, three rm05s,
one rm03, and five DZs. This system gets REAL slow with 25 to 30 users,
beside crashing about once a week. I would like to know if BSD 4.[12]
would be faster (and maybe not crash).
--
---------------------
Alan Fargusson.
{ ihnp4, sftig, amdahl, ucscc, ucbvax!unisoft }!drivax!alangwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (11/05/84)
> I would like to know how System V rel. 2 compairs with BSD 4.[12]. > We are running System V rel. 2 on a VAX with 4M ram, three rm05s, > one rm03, and five DZs. This system gets REAL slow with 25 to 30 users, > beside crashing about once a week. I would like to know if BSD 4.[12] > would be faster (and maybe not crash). All performance studies I have seen show that under conventional workloads UNIX System V Release n and 4.nBSD have comparable throughput. Each is faster than the other in specific areas. 4.1BSD is pretty stable. 4.2BSD has a faster file system but degrades worse under heavy load than 4.1BSD (this problem is being worked on). I would not guarantee that these systems would run a week without crashing, though; that depends on lots of things (like whether you have flakey hardware and whether you are using buggy kernel facilities). One thing to avoid on UNIX System V Release 2 is switching line disciplines. This is known to cause crashes. Have you analyzed your crashes to see what is causing them? 5 DZ11s will certainly take a lot of CPU, especially if you have many users of screen editors. A dramatic improvement for any such UNIX System V is to use the KMC11B I/O processor to offload the terminal processing (input canonicalization, pseudo-DMA, etc.). This is the first thing I would try. Note also that with only about 3Mb of user process RAM and 30 users, each user only has 100Kb of memory for his processes before swapping occurs. You should use the excellent system analysis tools of UNIX System V ("sag", etc.) to determine where your bottlenecks are. More main memory may help.