8-port serial async cards??

[Karl Denninger]

In article <8878 at alice.UUCP> debra at alice.UUCP () writes:
>In article <2870 at ddsw1.MCS.COM> karl at ddsw1.UUCP (Karl Denninger) writes:
>}>...
>}>I haven't timed it - but Anvil says throughput to the board is in excess of
>}>160kbs - it can sustain 9600 to 16 ports at a time.  It also goes up to 38k.
>}>...
>}ARGH!
>}
>}The Anvil board may be fine for 16 terminals, but I wouldn't think of using
>}it with even TWO 19200 baud modems.
.....
>}Yes, this is only about 20kbs -- TERRIBLE performance on input.
>}
>}Admittedly, output is much better -- as long as there's no input going on!
>}I don't know if I buy 160kbs though....
>}
>}When our Telebit comes online, my "19200" baud serial terminals' display
>}rate goes down to under 9600 bps -- because the board is overloaded and
>}giving priority to the input (thank god they did get this right).
>
>You realize you are being very demanding (even for a board with an
>8Mz 80186). We used to have an old Altos, with controllers for 8 terminals.
>We used 1 port for 4800 baud uucp-input, and the others for 9600 baud
>terminals. Any uucp traffic (input) on the one port would visibly slow
>down output on the other terminals (even when using only one) to 1200 baud.
>Those boards used a 4Mhz Z80 I believe.

And you had a gawd-awfully stupid (1) driver for that "smart" board, or (2)
I/O microcontroller code.

I used to program controllers for the satellite earth-station market, using 
a synch protocol (no screwing around here or you LOSE frames; lost frames
mean lost commands, and that was considered "not allowed" in the specs).  
The microcontrollers could EASILY handle 4 9600-baud lines using a 6Mhz Z-80,
in mode 2, going in both directions, and STILL have enough left to provide 
~20ms response to digital input changes as well as a console display.
This with no hardware assist, and with with the overhead of a multitasking 
operating system as well (PROM-based with NVRAM config!)

Yeah, it's really tough to do.  The code took a LOT of work; I wrote and
debugged the darn stuff, I ought to know.  But goddarn it, it did work, with
hardware flow control (and soft if you wanted), and it ran like gangbusters.  
The Z-80 _is_ reasonably talented in handling interrupts, but then again,
it's also got about 1/4 the processing power (if that) of an 80186!

DEC does 9600 baud, 8 lines up, BOTH directions on the DHV-11M with two
8051's (I believe these are 2 or 4Mhz parts; it's been a while).  Also an
8-bit slug of a processor; only one processor actually gets/puts characters
from what I understand, the other is essentially a bus/dma interface.

This kind of performance is _easily_ achievable, and it's all I ask for.
Meet the darn spec, don't fudge the spec (ie: "it's only good for output-only")
or at least SAY the 160kbs is only for output.....and that input capacity is
20 kbs!  Then I won't go out and buy a nice expensive boat anchor, or
something that will have our users wanting me strung up by the short hairs.

If you can't at least do this, then make the darn source code to your
drivers available (Anvil has refused) so I can fix (or rewrite) them.  As
for our (or anyone else) stealing them, do you really think it does any good
to have that code without the boards?!  (In any event, we offered to sign a
non-disclosure on it, but that wasn't good enough).

Look, my '386 CPU can handle more SIOs at high speed, AND handle the disk
controllers, and user processes, and tape drives, etc..... and not lose
characters.

>So I doubt whether there is much they can do to inprove the  Anvil board
>by much. If we rate the processor at about 0.5 MIPS, and we assume
>19200 baud input and output on all 16 lines, that is over 60000 chars/sec
>together, that leaves less than 10 instructions to handle a single char.
>No way this can be done. What they claim (160kbs) corresponds to 16 lines
>at 9600 baud in only one direction, but even then you have only about
>40 instructions to handle a character. This could be hairy already.

Sure it is.  It was hairy when I was doing controllers, too.  Every line of
the driver was scrutinized; that code was _hand_ optimized and every last
clock cycle squeezed out.  But it worked, with hardware flow control, on a
processor that was awfully darn busy doing other things as well!  Remember
what this was carefully -- a 6Mhz Z-80, with a CTC (timer chip) as well as
four SIO's (2 channels each), programmable speed/parameter selection, the
works.  It normally ran 8 units of some hardware via a proprietary serial 
protocol (packet monster); asynchronous messages were the norm.  

It's tough to do -- that's why there's dual-ported memory on the board, and
arbitration circuitry.  That's why there's a bunch of local memory, and 32K
of PROM there too.  And that's why the 8Mhz '186 to do the processing.  So
you have the resources to blast and accept characters at that speed.  

Actually, all I really want is the ability to run 9600 baud input/output on
8 lines.  That's fine.  The board should be up to this level of performance;
it's what they claim for it!

9600 bps * 8 ports * 2 directions = 153,600 bps, or just about what
Anvil claims the stallion will do.

There's no way I could actually DO this.  Heck, I can't get 1/5th of that 
performance on input channels!  

I'd bet I could eat a character and set it up for transfer to the Unix/Xenix
host (in raw mode) in under 20 instructions.  In "cooked" mode I expect
higher overhead; ok, so it's 30 or even 40 instructions per character 
(on input).  I'm willing to accept (and know there will be) a higher overhead 
for "special" characters (Xon/Xoff), or modem control signals (hardware flow 
control, for example).  My current problems are in raw mode, by the way....

Wow, that was hard.

If I sound frustrated, it's because I AM frustrated.  That board was #$@%^&
expensive!  And it's not met my expectations.

Gimme commented source code to the existing driver, OR a technical 
description (with port assignments and meanings) and schematics for it's 
construction.

Alternately, give me a hardware techie who can design a board (with access to
the parts needed), thinks progressively (which doesn't always mean the
"biggest" hardware; the craftyist is what I want to see...),  who wants to 
make a nice chunk of change but will wait for his/her (substantial) chunk
until the board PROVES itself on the market, can prototype the thing, and 
works well with prog-types. 

I'll blow the net's socks off, and there will finally be a smart board that
does all the "nice" things and gives REAL performance.  Like 8 Trailblazers
up screaming, no problem and NO slowdown (if your CPU can feed it fast
enough!).

Yeah, I'm gonna sell the things if we do this.  So what.  (you think I'd do 
this much work for nothing?  What, you nuts?! :-)  Who wants one?  :-)

Note that the ISA bus (AT) is good for 8 MB/second or so.... this ought 
to be relatively easy to do up to 500kbytes/sec or so; for better than that 
you're going to have to go for a bus master setup (which doesn't work on 
all systems) or use the new EISA bus (32-bit, 30MB/sec!).  Either of these 
approaches will require a monster (or some clever trickery) for the onboard 
processor.  

Then again 500kb/sec is more than enough for almost anyone!

--
Karl Denninger (karl at ddsw1.MCS.COM, ddsw1!karl)
Data: [+1 312 566-8912], Voice: [+1 312 566-8910]
Macro Computer Solutions, Inc.    	"Quality solutions at a fair price"