Newsgroups: comp.sys.next
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!elroy.jpl.nasa.gov!zardoz.cpd.com!neil
From: neil@uninet.cpd.com (Neil Gorsuch)
Subject: Re: Is there an 8+ serial port mux for NeXT cubes available?
Message-ID: <1991May2.214100.13070@zardoz.cpd.com>
Keywords: serial mux
Sender: news@zardoz.cpd.com (usenet news administrator)
Organization: Uninet Peripherals, Santa Ana, CA, USA
References: <9104240831.AA01164@lhs.woodside.ca.us> <573@rosie.NeXT.COM> <1991Apr26.023505.32391@mp.cs.niu.edu>
Date: Thu, 2 May 91 21:41:00 GMT

In article <1991Apr26.023505.32391@mp.cs.niu.edu> bennett@mp.cs.niu.edu (Scott Bennett) writes:
>In article <573@rosie.NeXT.COM> bloschen@next.com writes:
>>In article <9104240831.AA01164@lhs.woodside.ca.us> dick@lhs.woodside.ca.us  
>>(dick benster) writes:
>>> We would like to hook up many modems to a NeXT '040 cube, and  
>>I have seen products from UNINET that do this.  They have several  
>>configurations of 4/8 serial and parallel ports.  They have done some clever
>>things things using pty's and the SCSI port to do this.  The particulars are:
>     Clever, perhaps, but not very smart.  I would like a serial port
>controller, too, but one that comes with a *real* driver, not one that
>mucks things up by involving tty/pty code and its overhead, extra daemons,
>effective loss of available pty's, etc.

I would respectfully say that you don't know what you're talking about
as far as the complete pros/cons of this method as applied to our
product and market.  Here's the full scoop (in my biased opinion 8-):

First of all, the practicle aspects of being a supplier of peripheral
addon products to workstations: To take an example, in the Sun arena,
we have a lot of competitors that supply S-bus cards for serial port
expansion.  They all use drivers.  Every customer that has compared
ours and their method says ours is vastly superior.  Almost all of our
customers say that they are very happy not to have to rebuild the
kernel when installing our stuff or when they upgrade their operating
system.  Every time that Sun changes operating system versions, our
competitors scramble to change their driver to account for the
changes, and their customers wait for a new version so that they can
use the ports again.  Now carry it further.  Our stuff works on all
the following systems, without any drivers or kernel rebuilding, and
has one common source program (and Makefile) for them all: NeXT,
DECstation, Sun 3, Sun 4 (sparc), Solbourne (ours is one of the few
programs that are not binary compatible between Sun sparc and
Solbourne), IBM 6000, MIPS, Data General Aviion.  There are other
systems that it works on, but they aren't unix, and the code isn't the
same, and one of them even uses a (horrors 8-) driver.  It would be a
nightmare to supply drivers for all those systems and keep them
updated with their respective operating systems.

Now on to some technical aspects.

pty/tty and other overhead.  Read my lips, "there is far, far more
resource usage (overhead) in generating/processing characters than is
used in sending them through a pty/tty driver".  On a sparcstation,
well over 100,000 characters a second (can you say 1,000,000 baud
equivalent ? ) can be pushed through the tty/pty drivers.  A lot of
drivers (like the drivers on the serial ports of a sparcstation) have
to go through an entire interupt for every single character going in
or out.  The way that our stuff works, we only incur interupts on each
block of characters, and the vast majority of characters traveling on
a serial port come as blocks of output characters from application
programs.

Now for a real example of the efficiency of our methods.  We have a
customer that has 3 very large workstations that are normally sold as
servers being used as data base front ends.  Each one has 32 serial
ports with terminals attached to them, using our slats.  They tell us
that this method is much better, performance wise, and has lower
overhead, than they would get by using either ethernet serial boxes or
serial cards in their machines.

Mucking things up with pty/tty code.  There is no cleaner way to do
things than by letting the operating system handle the stuff it
normally handles anyway (remember, this is unix, use things that are
already there whenever possible), at least in the systems that don't
use streams to differentiate between the hardware interface driver
stuff and the "stty raw/echo/onlcr etc" stuff.  The pty/tty drivers
are the perfect thing to use to add hardware serial ports, since they
handle all other interface aspects except for the final source/sink of
characters.  Plus, it lets us do things like provide full
dial-in/dial-out access on every port, even on systems that don't
normally support it, by using split ptys if required.

Extra daemons.  There is only 1 daemon per computer system that
handles all of the slats and slat serial ports.  Read my lips, "the
overhead caused by slatd (our daemon) is negligable when it's idle,
and a very small amount compared to the programs generating/processing
characters when characters are moving through it".

Loss of ptys.  Are you running out of ptys?  NeXT, like most systems,
will probably add more ptys.  We haven't had a customer complain yet
about the slat losing them pty's that another application/program
needed.

Not having a *real* driver.  Why do you need one, if our method allows
for more robust code, does all the things that the customers want to
do with serial ports, doesn't require a kernel rebuild on installation
or operating system upgrade, and has less overhead associated with it
that with a lot of serial drivers that we have seen?

>I also can't see paying twice
>as much for it as for serial port controllers for pee cees.

You are paying HALF as much as comparable units. PC cards are cards
only, the SLAT is in an external case, involves cabling, power supply,
etc, all of which adds considerably to the cost.  If you want to
compare apples to apples (is that a fond word for members of this
group 8-) ? ), compare our price to an ethernet serial box.  The last
time I looked, most of them were in the $2,000 to $3,000 range.  PC
cards are also much higher volume, and have lower manufacturing costs
associated with the higher volumes.  We don't compete with cards that
go in a card cage.  If you have a card cage, and can add a serial
card, I would be the first to urge you to use that instead of our
slat, the cards will probably be cheaper.  If you don't have a card
cage, our method is probably cheaper, and certainly has some important
technical advantages (in my biased opinion 8-), over ethernet serial
boxes.

--
Neil Gorsuch        INTERNET: neil@cpd.com          UUCP: uunet!zardoz!neil
MAIL: 1209 E. Warner, Santa Ana, CA, USA, 92705     PHONE: +1 714 546 1100
Uninet, a division of Custom Product Design, Inc.   FAX: +1 714 546 3726
AKA: root, security-request, uuasc-request, postmaster, usenet, news