blinn@dr.dec.com (Dr. Tom @MKO, CMG S/W Mktg, DTN 264-4865) (10/04/88)
My apologies if you're seeing this for the second time. I posted it to COMP.OS.VMS about 2 weeks ago (on 23-Sept), but haven't seen it come back, so I'm assuming it got lost. I'm also cross-posting it to COMP.SYS.DEC, as it is likely to be of interested to that newsgroup as well. Subj: More than you ever wanted to know about VAXBI arbitration Mike Hesselton of Petro-Canada asked about the VAXBI bus and the DWBUA UNIBUS adapter. Mike wrote: >In the past I have heard many grumblings concerning the 8000 series of >VAXen and the UNIBUS adapter. I have never (to date) heard this one >though and was wondering if anyone out there can confirm or deny it: > >We have 8530 with two BI adapters. DEC says that because we have a >UNIBUS adapter installed on one of our BI's that this BI is reduced >to run at the speed of the UNIBUS, approximately 1/10th of our other >BI. (ie. All BI periferals will now run at the lower UNIBUS speed) > >This sounds kind of strange to me, has anyone else heard this or has >DEC Canada read the Technical updates upside down again??? Mike, it certainly sounds like there's some confusion here. At the worst, the DWBUA can "hog" half the VAXBI bandwidth. While this may slow down some of the other VAXBI devices somewhat, it certainly does not slow them down to UNIBUS speeds. Note, by the way, that few of the devices typically configured on the VAXBI can even begin to consume all of the bandwidth available. So even only half the bandwidth is usually more than sufficient for most applications. Your requirements may vary. If you don't want to learn about VAXBI arbitration, the DWBUA, and why the DWBUA can't slow everything else down to UNIBUS speeds, skip this message. Due to the timing and throughput requirements of the Unibus, the DWBUA was designed to be able to get a lot of throughput on the VAX BI. The way it can do this is designed into the VAX BI, as part of the arbitration logic. This is all described in reasonable detail in the "VAXBI Technical Summary", a small booklet published back in 1985, which has part number EB-28190-46. Basically, the way arbitration works on the VAXBI is as follows (I'm going to quote, verbatim, from the book) [comments in brackets]: Arbitration logic is distributed among all VAXBI nodes. No processor is dedicated specifically to controlling bus use. [This differs from, e.g., the Unibus. It's possible because the BIIC has lots of smarts.] When the VAXBI bus is idle, every node can arbitrate. The one with the highest priority wins the bus. It then sends command/address information to initiate a VAXBI transaction. [This applies to EVERY node, including the DWBUA.] During an ongoing VAXBI transaction, all nodes except the bus master can arbitrate in the interval between the command/address cycle and the ensuing data transfer cycles. This interval is called the imbedded arbitration cycle. Again the node [other than the current bus master] with the highest priority wins the bus. It becomes `pending' bus master and initiates its own command/address cycle as soon as the last data transfer of the current transaction is complete. Priority is determined by one of three arbitration modes set by a two-bit field within the VAXBI Control and Status Register. These are dual round robin, fixed-high priority, and fixed-low priority. While any combination of arbitration modes can coexist among VAXBI nodes, dual round robin is the preferred mode because it allows nearly equal access to the bus for all nodes. [There's actually a fourth mode, which is "don't arbitrate", but it's typically used only when a node is shutting down. And, of course, a node only requests the bus when it needs it.] [End of quoted material] The same information is included in the "VAXBI Options Handbook", printed in 1986, part number EB-27271-46. That handbook also includes information on the DWBUA (quoted verbatim) [comments in brackets]: The VAXBI-to-UNIBUS adapter, DWBUA, transfers data between the high-speed synchronous VAXBI bus and the asynchronous UNIBUS. It allows VAXBI processors to access any UNIBUS address, and UNIBUS devices to access any VAXBI address. [As it happens, the mapping from UNIBUS addresses to VAXBI addresses is usually managed by a VAXBI processor, such as a VAX running VMS or ULTRIX, rather than by a UNIBUS processor.] The DWBUA routes transactions over two kinds of paths -- direct or buffered. VAXBI-initiated transactions use only the direct data path. UNIBUS-initiated transactions use either a direct data path or one of the DWBUA's five buffered paths. On the direct data path, the DWBUA transfers longwords (four bytes). Over a buffered data path, the DWBUA uses the VAXBI bandwidth most efficiently by internally buffering as much as one octaword (16 bytes). The DWBUA's maximum data transfer rate is approximately 1.0 Mbyte per second. Besides transferring data, the DWBUA acts as arbitrator for the UNIBUS. It lets UNIBUS devices send interrupts over the VAXBI bus. Unlike other VAXBI options, the DWBUA normally arbitrates in fixed-high priority mode rather than [dual] round-robin mode. [End of quoted material] Now, how does dual-round robin work, vs. fixed-high or fixed-low priority? Basically, "next master" is determined by looking at a data word that is passed on the VAXBI bus during the "arbitration cycle". There are 32 data bits and 16 possible nodes. Each node has a "low-priority" data bit and a "high-priority" data bit. The "node ID" is a number from 0 to 15 that is provided by the ID plugs on the VAXBI backplane; obviously, the IDs have to be unique (only one node "0", one "1", and so forth). By convention, the lower numbers have higher priority. During the arbitration cycle, each node can either assert its high-priority bit, its low-priority bit, or not bid for being master by asserting neither bit. If a node is operating with fixed-high priority, it always asserts its high- priority bit, or none at all if it doesn't need the bus. If it's operating in fixed-low priority mode, it either asserts its low-priority bit or none. Dual round robin is a bit more complicated. It comes into play once a node has become bus master. The master transmits a command/address, and the other nodes require some time to decode the address. During this time, the other nodes can also bid for being "next master", but the current master can't bid (and hence can't hog the bus). During this "imbedded arbitration cycle", the master puts its node ID on certain of the BI data lines, and the other nodes can use this information to decide whether (assuming they need the bus) they should bid in the "high-priority" or "low-priority" word. A node with higher priority than the current master (that is, with a lower node ID) will bid in the low-priority word, and a node with lower priority (that is, with a higher node ID) will bid in the high-priority word. If all the nodes are operating in dual round robin mode, then over time, each node has an equal probability of getting access to the bus. There's some other rules that come into play: fixed-high and fixed-low priority are reserved for Digital (customer device adaptors should always use dual round robin), and some devices may require that they be at lower node IDs (higher device priority) than others. The DWBUA operates in fixed-high priority mode, and it must always be node ID "0" when it is present. (Thus, you can have at most one DWBUA on any VAXBI.) To the best of my knowledge, it is the ONLY adapter that works in fixed-high priority mode. Consequently, the DWBUA always bids in the high-priority word when it wants the VAXBI bus for a data transfer, and since it is always the lowest node ID on the bus, it always gets to be the next bus master. HOWEVER, once it is bus master, it MUST relinquish the bus to another node if any other node wants it, and the other nodes will all arbitrate in the high-priority word if they're in dual round robin mode (since they all have a lower node ID than the DWBUA), so the highest priority node among them will get the bus next. Whenever the DWBUA doesn't need the bus (that is, whenever the UNIBUS devices are idle), the other VAXBI nodes operate essentially as if it weren't there. So, the DWBUA can't slow everything down to UNIBUS speeds. At worst, it can get one half of the available data cycles, and it does as much as it can to optimize its use of the cycles it does get. Since for most uses, the VAXBI has more available bandwidth than is needed, sharing the VAXBI with other BI adapters is not a problem. People who prefer both a belt and suspenders may, of course, choose to dedicate a BI to the DWBUA, but this is typically not necessary. Tom Dr. Thomas P. Blinn U.S. Channels Marketing Digital Equipment Corporation Continental Blvd. -- MKO2-2/F10 Merrimack, New Hampshire 03054 Internet: blinn@dr.dec.com Easynet: DR::BLINN Usenet: {decvax,ucbvax,allegra}!decwrl!dr.dec.com!blinn Phone: (603) 884-4865 Note: Opinions expressed herein are my own, and do not necessarily represent those of my employer or anyone else, living or dead, real or imagined.