info-vax@ucbvax.ARPA (11/12/84)
From: Bill Mitchell <whm%arizona.csnet@csnet-relay.arpa> Has *anyone* done *any* disclosable benchmarks on the 8600? DEC's been talking about the machine for who knows how long and now that it's "here", the sum of the performance data that we can get out of them is "up to 4.2x a 780". Does anyone know what the low end of the scale is? Is the 4.2x figure for real time or is it for CPU-bound activities? I'm assuming that 4.2x is some sort of reasonable upper bound on throughput, but what's the lower bound? On an unrelated topic, why is DEC pushing their UNIBUS disks so hard? Sure, they've got the slide shows and the answers about how there's plenty of room on the UNIBUS for the disks, but we've had no luck in pinning them down about why all the emphasis is on the UNIBUS disks and why the MASSBUS disks are hardly mentioned. I've heard that DEC is overstocked and is trying to reduce the surplus; anybody know if there's truth in this? Bill Mitchell
info-vax@ucbvax.ARPA (11/13/84)
From: Ron Natalie <ron@BRL-TGR.ARPA> I think DEC would like to forget about MASSBUS entirely. The move is out for the new Digital Storage Archicture disks and the CI/780. DEC's aren't the most cost effective processors on the market but the MASSBUS peripherals can not compete at all in the competitive market place. -Ron
info-vax@ucbvax.ARPA (11/13/84)
From: Mike O'Brien <obrien@CSNET-SH.ARPA> It's true that the MASSBUS stuff is not at all competitive, but when you start to consider second vendors plus other things on the UNIBUS, the picture becomes far less clear. As of now, the price/performance of second-vendor MASSBUS disk systems is very favorable when compared to DEC UNIBUS disks (that is, they're about even). Plus, things like LAN's compete fiercely for UNIBUS cycles, and they have no MASSBUS alternatives. Consequently, for a sizeable system, about the only thing to do is to buy a second UNIBUS adaptor: one for the disks and one for the LAN (put the terminals wherever you want; their burst rates are not that difficult to handle). This definitely runs into money. So, while arguments about intelligent controllers vs. burst rate are kosher when taken alone, the Big Wide World is harder to figure. [Even on its own merits, using a buffer in the controller to preclude the necessity of a high burst rate into main memory only holds if the cache size is large compared with the typical transfer. On a 4.2BSD UNIX 8K file system, two file system block reads will fill the UDA-50 buffer cache. Upshot: I'm still looking at Emulex/Fuji.]
info-vax@ucbvax.ARPA (11/13/84)
From: medin@ucbarpa.BERKELEY (Milo Medin) Yeah, I have been puzzled by the emphasis on UNIBUS stuff myself. I asked a few DEC people about why they put an RA81, which is a fine drive, which is a 2MB/s device, on a .5-.8MB/s UNIBUS. They said that those drives are part of the DSA and they want you to use the CI bus and cluster them together, and that the CI bus is 70 Mb/s and isnt unibus bound. But then I pointed out that their file server, a HSC50 is an 11-based product and has the unibus in it as well, and the disks go thru an UDA50. I asked what the difference was where the unibus bottleneck was, that its still a bottleneck. They didnt know why, but they said they had a good reason. Sigh. I really like the RA81, its a great idea, but this unibus stuff is ridiculous. Thats why I only use Eagles and Emulex massbus controllers (SI makes them too). Surely they arent planning a new line of PDP11 unibus products... Milo
info-vax@ucbvax.ARPA (11/13/84)
From: Richard Garland <OC.GARLAND%CU20B@COLUMBIA.ARPA> Unibus HSC50 and DSA disks Its true the HSC50 has a PDP11 in it (F11 chip set) but there is no Unibus or UDA50's in it. It has a fast backplane into which disk controllers and a CI interconnect plug. The PDP11 is the supervisor of the whole thing but data does not pass through it. The HSC should handle multple controllers and multiple disks in parallel and fill up the band width of the CI in a reasonable fashion. The Unibus connections via the UDA50 is clearly the low end solution whereas DEC intends to push the CI for upper end systems. We find that a UDA50, Ethernet, 56 terminals, an E&S PS330, and an FPS AP164 can all coexist on our one Unibus nicely. Just takes some intellegent buffering and queueinmg in the CPU which VMS manages adequately. Certainly if we had the funds we would look ata second Unibus or a CI. If (when) we get an 8600 a CI will obviously be part of it. My feeling is that with Unix one is not wedded to DSA disks particularly or to clusters so there Emulex/Fuji etc make more competitive sense. Being a VMS shop on the other hand I see value in staying with the DSA disks and looking forward to clusters some day. Rg -------
info-vax@ucbvax.ARPA (11/15/84)
From: Ron Natalie <ron@BRL-TGR.ARPA> Nobody makes a second-vendor MASSBUS disk system. MASSBUS is inherently expensive. What DEC should be pushing is SBI based controllers (which are what the EMULEX and SI controllers are) like the CI/780. -Ron
info-vax@ucbvax.ARPA (11/15/84)
From: Ron Natalie <ron@BRL-TGR.ARPA> Acually, there are several processors in the HSC50. There is an F11 which is for control, plus some bit sliced microprogrammed wizmo with a custom intstruction set (which the DEC people say does resemble PDP-11 for some reason). -Ron