Regarding the Emulex CS-11

[utzoo!decvax!ucbvax!menlo70!sytek!sytekvax!sam]

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