Asytekvax.124 net.unix-wizards utzoo!decvax!ucbvax!menlo70!sytek!sytekvax!sam Thu Aug 27 19:36:27 1981 Regarding the Emulex CS-11 I had hoped to hold off on comments on the Emulex CS-11 multiplexor until it was working, but since there have been a number of notes in the news recently, I thought I should put my "two cents" in. We have a CS-11 on our VAX-11/750. In fact, as far as I know, we are the only people around with one on a 750. To say that there have been problems would be an understatement! We have gone through at least 6 versions of microcode and one visit from the Emulex guru who wrote the CS-11 microcode. During our many chats we have uncovered numerous bugs, some of which cause horrendous problems. If I remember correctly (there have been so many things wrong), the modem control logic problem described in one of the more recent news articles was due to the CS-11 dropping DCD and at least one other signal when setting bits in the dmcsr register (which results in a SIGHUP being sent to everything on that port, unless it is "hardwired"). In addition, there are still timing problems (at least on the VAX-11/750) with writing the dmcsr, then turning around and reading it immediately (and possibly vice versa). It seems that the controller can't respond to the requests for information (for the read) fast enough to satisfy the UNIBUS timeout requirements, and consequently a nonexistant memory trap occurs while in kernel mode. In my dh driver I've put in 3 microsecond delay loops at the certain places to avoid this problem. Ken DeGroud (the Emulex guru) says that only 1.5 microseconds is actually required. There is supposed to be yet another microcode release out shortly (if not already) which fixes this problem. For your information, we are running Rev F4 (A, B, C,....) and the newer Rev is F5. However, it appears that all has not been fixed even in Rev F5. We are currently able to use only one 16-line panel of the two we have, as the second panel (daisy chained) causes the system to crash quite reliably. I expect to see a Rev F6, or "Sytek Rev" as the case may be, before all is done. While this may scare you, I might add a few comments. First, it appears that a 750 is a peculiar beast due to its UNIBUS interface (UBI). The timing constraints are much stricter (more to the UNIBUS specification) than most PDP-11's. As a result many manufacturers that designed peripherals for the UNIBUS, but skimped in terms of meeting timing requirements are being bit by the 750 (eaten is probably closer). Some of the earlier CS-11 problems were of this sort, and there are sure to be at least a few more of a similar nature left. The folks at arpavax (Berkeley) have a 32-line CS-11 on their VAX-11/780, and hasn't had any complaints (that I know of at least). my guess is that what ails the CS-11 (in the lastest Rev microcode) is specific to the 750. Finally, to squelch one rumor you might have heard of, the CS-11 does not appear to have throughput problems. George Gobel of Purdue told me that someone (unnamed) had throughput problems. This person's belief was the CS-11 couldn't handle more than 20-30K of throughput. To my relief, we have been able to run (4) 19.2K terminals + "some" 9.6K terminals "full blast" without any noticeable delays. This was on some earlier versions of microcode, but I believe that the stated Emulex claims of 50K throughput are within reason. Rather than have people bug (how appropriate) me with requests for the locations at which to place delay loops, I'll try and put together a later news item which shows enough context to identify the appropriate locations. Sam Leffler ----------------------------------------------------------------- gopher://quux.org/ conversion by John Goerzen of http://communication.ucsd.edu/A-News/ This Usenet Oldnews Archive article may be copied and distributed freely, provided: 1. There is no money collected for the text(s) of the articles. 2. The following notice remains appended to each copy: The Usenet Oldnews Archive: Compilation Copyright (C) 1981, 1996 Bruce Jones, Henry Spencer, David Wiseman.