Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!cbmvax!drysdale
From: drysdale@cbmvax.commodore.com (Scott Drysdale)
Newsgroups: comp.sys.amiga.hardware
Subject: Re: second serial port
Keywords: 2232 7 port
Message-ID: <16279@cbmvax.commodore.com>
Date: 4 Dec 90 04:13:36 GMT
References: <14383@crdgw1.crd.ge.com> <90334.151404DXB132@psuvm.psu.edu> <1990Dec2.141048.10108@NCoast.ORG> <1990Dec3.053356.26826@monu6.cc.monash.edu.au>
Reply-To: drysdale@cbmvax.commodore.com (Scott Drysdale)
Organization: Commodore, West Chester, PA
Lines: 76

In article <1990Dec3.053356.26826@monu6.cc.monash.edu.au> edp367s@monu6.cc.monash.edu.au (Rik Harris) writes:
>davewt@NCoast.ORG (David Wright) writes:
>
>[commodore & IBM board details deleted]
>
>>	I would never use a board with more than 2 ports on it if it didn't
>>have it's own CPU. The only time a "dumb" board is worth the CPU overhead is
>>if you are running only low-speed devices, or you just want to be able to
>>attach 2 or three printers, and leave them attached rather than getting a
>>switch box. If you try to run 3 or 4 terminals at 9600 baud without a CPU
>>on the I/O board you will see significant speed loss.
>
>>		Dave
>
>[I have not used any of the multiple serial boards on any machine]
>
>I dont know what level of hardware expertise you have, David, but your
>comment is rather confusing.
>
>A CPU will add convenience to the design of a piece of hardware, not speed.
>A CPU needs to be clocked, and must access memory, and the hardware is
>limited by the speed the CPU can run at.
>
>For the last year I have been working on a Packet Switching Local Area
>Network (what it is/does is not really relevant) that is pushing away
>from the CPU, because it is too slow.  We have built specialised
>circuits to have the hardware do all the buffering and switching of
>packets without CPU intervention.  Doing this, we have increased the
>potential speed of the device by ORDERS OF MAGNITUDE (more than 3
>orders).
>
>Now, I'm not saying that a product that doesn't have a CPU is _going_
>to run much faster, just that there are more things to consider than
>simply whether the product has a CPU on it or not.  Admittedly, the
>product that can handle 3-4 terminals at 9600bps, that is on the
>market first, would probably be one with the CPU, but it is still not
>necessarily the best.

what you want a multiport serial card to do is annoy the host machine's CPU
as little as possible.  consider 8 ports sending and receiving at 19.2K baud
simultaneously with no hardware or local CPU assist, interrupting the host
CPU for each character.  that's close to 32,000 interrupts per second -
certainly not a desirable load on the host CPU.  put a CPU on the serial
card, however, and you can start trasferring large blocks of data between
the card and the host at lower rates, and have the card's CPU do all the
step'n'fetch to service the ports.  *extreme* reductions in host CPU overhead
are possible.

of course, the latency between a character completing assembly in one of the
UART's receive registers and when the host actually sees it is potentially much
greater than the direct interrupt approach, so this kind of thing wouldn't be
great for midi or other timing sensitive applications, but with a little more
code on the card's CPU, you could do decent timestamping and pass the data
to the host with the timestamps already there.

certainly a pure hardware approach without CPU intervention (intelligent
DMA, for instance) would be even faster, but this is only 8 ports we're
talking about, running at fairly low speeds.  i imagine your packet switch
has hundreds or thousands of "ports" to deal with.

>
>Rik. 
>-- 
>Rik Harris - edp367s@monu6.cc.monash.edu.au           | Build a system that
>new address!  rik@sola.fcit.monash.edu.au             | even a fool can use,
>Faculty of Computing and Information Technology,      | and only a fool will 
>Monash University, Caulfield Campus, Australia        | want to use it.

 --Scotty
-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Scott Drysdale           Software Engineer
Commodore Amiga Inc.     UUCP {allegra|burdvax|rutgers|ihnp4}!cbmvax!drysdale
		         PHONE (hopefully sometime this year)
"Have you hugged your hog today?"
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=