Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: $Revision: 1.6.2.14 $; site uiucdcs.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxj!ihnp4!inuxc!pur-ee!uiucdcs!irwin From: irwin@uiucdcs.UUCP Newsgroups: net.unix-wizards Subject: Re: eagle Message-ID: <13700061@uiucdcs.UUCP> Date: Sat, 22-Sep-84 04:05:00 EDT Article-I.D.: uiucdcs.13700061 Posted: Sat Sep 22 04:05:00 1984 Date-Received: Wed, 26-Sep-84 03:13:45 EDT References: <13536@sri-arpa.UUCP> Lines: 49 Nf-ID: #R:sri-arpa:-1353600:uiucdcs:13700061:000:2598 Nf-From: uiucdcs!irwin Sep 22 03:05:00 1984 We are running 9900s on nine machines, 2-780s and 7-750s. The 780s have SBI interfaces on the mass buss, the 750s have CMI, so none are on the unibus. When we got the systems, we could not hack the cost of maintenance on all nine, so elected to handle the 750s ourselves. The 9900s on the 780s have been kept at current rev level, the 750s have not as a result of no maint. Our 780s are on DEC maint, but not the 750s. The firmware in the 9900s on the 780s is a 4 rom set (level 6.2 I think and handles bad block forwarding without special drivers) but we put in a patch for the bbf under 4.2 and have not changed it since the latest firmware was installed in the 9900s. I am told that level 7.0 is just around the corner. The firmware in the 9900s on our 750s is a three rom set, and we have had disk files damaged on those systems. We just went through a rather lengthy negotiation with SI to get the 750 disk sub systems on maint, so that we can get them up to current rev. I do not feel that the bug will remain after we have done so. We have been pointing the finger at SI because we were having problems with the 780s, they would go off into never-never land, no error messages and we could not determine what was causing it. SI helped us locate it, by studying the register dumps that we took. It turned out that we had some soft mem errors (which we knew about but ignored because they were correctable, were brand X, not DEC memory) and the memory controller was getting a second error while trying to correct the first, so "hung buss" by a confused mem controller. Now that we have cleaned that up, the 780s have not been causing problems. We got our 780s with 4 meg (256k boards) and later added an extra cabinet to one, moved the 4 meg to it and got a 8 meg mem for the vacated memory hole in the other. That one was the one giving us the most trouble and DEC mem tests on their micro diag floppy #3 for the 8 meg unit would not even report any errors. The #2 floppy which covers the 4 meg mem unit does a very complete test and points out any bad boards. If you have a choice of unibus or CMI or SBI, I would recommend avoiding the unibus controllers. We had them before changing over, you will get better through-put on the mass buss. We did not have problems with the unibus controllers (ours was Emulex) but a lot of swapping and so on can sure load down the unibus. We are running 96 RS-232 ports on each of the 780s on Emulex H2 unibus controllers and average 30 to 45 users logged in at any one time on both machines. I hope that this information is helpful. --al irwin--