Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site redwood.UUCP Path: utzoo!watmath!clyde!cbosgd!ihnp4!zehntel!hplabs!hpda!fortune!rhino!redwood!rpw3 From: rpw3@redwood.UUCP (Rob Warnock) Newsgroups: net.arch Subject: Re: time for a RISCy bus Message-ID: <132@redwood.UUCP> Date: Fri, 18-Jan-85 23:08:03 EST Article-I.D.: redwood.132 Posted: Fri Jan 18 23:08:03 1985 Date-Received: Thu, 24-Jan-85 07:09:26 EST References: <4940@utzoo.UUCP> Organization: [Consultant], Foster City, CA Lines: 81 +--------------- | While all these bus schemes do have | interesting characteristics, there is one disturbing problem that they | all share: | Every last one of them is appallingly complex. | (Well, maybe I'm slandering the Nu-bus a little bit, but not the others.) +--------------- I agree. The major complexity with the Nu-bus is that you need a FIFO to stack up "interrupt events" (or did they change that in the TI version? I only have the old MIT stuff). All in all, though, it IS very clean. +--------------- | It is high time somebody did for bus structures what the RISC has done | for machine architecture: provided a simple, high-performance alternative | to the convoluted, baroque "mainstream" approach... | Anybody got any bright ideas? | Henry Spencer @ U of Toronto Zoology|{allegra,ihnp4,linus,decvax}!utzoo!henry +--------------- Yeah... Ethernet! Now wait a sec before you start flaming... It's one wire, the text of the full spec is only 100 pages, you can put 99% of the important stuff on two pages, and many many vendors have proven they can interface to it. It supports both standard protocols and proprietary protocols, simultaneously. Simple devices can use simple protocols, complex systems can use complex stuff. You can use it in bus, star, wire, fiber, and microwave configurations, and all of that can appear to be one net if you like (with repeaters and/or bridges). The bandwidth is about that of an early PDP-11 UNIBUS or Q-bus. It only takes two chips to interface to it (to the transceiver cable level), and though they are expensive today, remember that "all silicon eventually costs $5 [Gordon Moore -- Intel]". (Besides, look at your bus-driver/receiver costs with those big, wide, monster busses!) I was going to say SCSI, but in the name of "improvements", it has gotten more and more complex (with sub-devices and disconnect/reconnect, etc.), so that a full-functioned SCSI controller can be more complex than an Ethernet controller. SCSI DOES supply somewhat higher bandwidth (12Mhz), and by using the (proposed) asynchronous-acknowledge feature you can get up to 4Mbytes/sec in some configurations. It also has SMALL limits (8) on the number of controllers+devices on the bus, as well as distance problems. The increasing necessity (for both speed and manufacturing economics) of packaging whole sub-systems on a board, rather than just pieces, and the decreasing costs of "CPUs" per se (a Z80 costs less than an SIO!), makes the "skinny backplane" worth considering. If several subsystems are packaged in one box (read: power supply and RFI shield), the interconnect can be even cheaper. And when was the last time you were able to take a terminal controller or a disk controller out of your system, fix it, test it, and put it back without crashing the system???!?!? "Skinny" backplanes make that possible (though not guaranteed, as anyone with certain UNIBUS Ethernet controllers knows). Yes, the bandwidth limit is a problem, but the latency across the "Etherbus" for a 1K disk block is a small fraction of the latency of reading that block from disk, and even small compared to the kernel CPU time to process the data ("read()" call, buffer cache search, etc.). [For those who haven't done the arithmetic, the Ethernet-induced latency to send a small request packet and get back 1024 bytes of data is just under one millisecond under light load, about 3-5 times that if the net is 70% loaded AVERAGE -- you never see average loads that high in real configurations.] Yes, many currently available board-level controllers have latency and throughput problems. I suspect that's because such controllers were designed to be "everything to everybody", rather than a simple, transparent path to the "bus". It's NOT inherent in bit-serial transmission. O.k., I have presented my bright idea: "skinny" backplanes, with the current default being present-day Ethernet version 2.0 (IEEE 802.3), especially when used with simple / protocols (like XNS Packet Exchange). Comments? (Guidelines: Let's try to keep it technical, on "skinny" vs. "fat" backplanes, not Ethernet vs. Pronet vs. Hyperchannel, for example.) Rob Warnock Systems Architecture Consultant UUCP: {ihnp4,ucbvax!dual}!fortune!redwood!rpw3 DDD: (415)572-2607 USPS: 510 Trinidad Lane, Foster City, CA 94404