NetNews Usenet Archive 1992 #18/NN_1992_18.iso/spool/comp/unix/bsd/4523

Internet Message Format | 1992-08-20 | 7.0 KB

Path: sparky!uunet!kithrup!stanford.edu!rutgers!gatech!destroyer!caen!hellgate.utah.edu!fcom.cc.utah.edu!gateway.univel.com!ns.novell.com!gateway.novell.com!thisbe.Eng.Sandy.Novell.COM!terry
From: [e-mail] (Terry Lambert)
Newsgroups: comp.unix.bsd
Subject: Re: (386BSD) Modems and com ports
Keywords: internal or external?
Message-ID: <[e-mail]>
Date: 20 Aug 92 21:37:21 GMT
References: <[e-mail]>
Sender: [e-mail] (NetNews)
Organization: Novell NPD -- Sandy, UT
Lines: 130
Nntp-Posting-Host: thisbe.eng.sandy.novell.com

In article <[e-mail]> [e-mail] (Craig Chase) writes:
>So, before I go plunk $250+ on a modem I wonder if someone could
>clarify the situation with dropped characters on a serial line.
>
>I understand that the 386BSD device drivers have trouble keeping
>up with high-speed serial communications, but how much trouble
>and how fast?  The FAQ lists 38K bps as higher than you're likely
>to be able to go, does this mean the 19.2K would be OK with sl/ip?

1)    Dropping characters depends on the device driver.  With the default
    device driver and the right chips at a high clock rate, 38400 is
    about top speed.  It is possible to write a driver to go faster
    (I have a driver for SCO that I wrote that would do 115K but
    liked to lock non-16550 machine up tight).

2)    People have posted that they have has no problems with SLIP up
    to 19200 in comp.unix.bsd (here).

>(BTW: 19.2K being MNP5 + V.32 and quite doable on a modem
> with V.32bis + V.42bis you can go up to 56K)

I think you mean "can burst up to 56K".  The problem is that most of these
modems expext to be able to flow control the sender, since you can't
guarantee a minimum compression, and even 960 characters a second is asking
a lot that your normal phone line can't deliver.  Generally, this is
implemented with a large forward channel and a small (~150 baud) back
channel and is more suited to unidirectional connections (like sliding
window file transfer protocols).

From my experience, this generally means that you will have either in band
flow control (XON/XOF) or out of band flow control (CTS/RTS).

The problems with using in band flow control on SLIP or any other binary
protocol are manyfold:

1)    Modem buffers generally exceed the 128 character UNIX tty buffers.
    This means that by the time you react to the flow control, it's
    too late.  This is a problem for polled drivers, like my 115K
    driver for SCO, which took an interupt and polled like hell until
    an input latency (window border) was seen, since more data is
    dumped than can possibly be read, including the flow control
    characters.

2)    A UNIX write, once started, must run to completion before it may be
    XOFed.  Cheap modems have less than the required 384 character
    buffer window, as they expect the host to respond to flow control
    more or less immediately.

3)    If you are using in band flow control, you can't use a binary
    protocol.  For instance, packet sequence numbers for xmodem packets
    17 and 19 are ^Q and ^S, respectiveyly.  This includes zmodem,
    unfortunately, because the handshake to determine if binary data
    can be used is binary (GAK!).

The problems with out of band flow control are also prohibitive:

1)    Your driver must be written to uderstand the type of flow control
    your modem uses for CTS/RTS.  This May be Hayes style, or it
    could be Bell 103-C style.  See "Technical Aspects of Data
    Communications" from "Digital Press", by McNeely.

2)    CTS/RTS lines are *not* standardized by the driver (see below).


The problem shared by any flow control whatsoever is lockup on line drop.
If the computer is ^s'ed, or !RTS or !CTS'ed, then the driver will wait
for the condition to be cleared.  In most cases, this takes precedence
over a little thing like DCD dropping because of call waiting or a bad
connection.  Result:  Serial port is hung until (1) someone calls in
and manually resets it or (b) you reset your computer.  The good thing
about this is that DTR generally will not be re-raised to the modem
so that you *CAN* dial in to reset it until *AFTER* you have dialed
in and reset it, resulting in a catch-22.

One major problem here is that *many* (read: most) cheap MNP modems (read:
not from Microcomm) *force* in band flow control on in MNP mode.  Thus
you can *never* use binary data and *always* risk lockup.  This is
because, in general, the modems are cheaper from skimping on buffer memory.
If you had input and output buffers in excess of the window size of your
protocol plus 384 characters, you would never need flow control from the
modem to the computer or the modem to the modem (still need it for computer
to modem because of UNIX's small tty buffers).

The soloution is to ask a sales guy, who probably doesn't know and just
wants you to drop a third of a kilobuck so he gets his 10%, or a modem
manufacturer, who does know but hates to tell anyone anything bad about
their products, or to buy it on a trial basis.

>My *real* question is, will it matter if I get an internal modem
>or an external modem?  From a performance standpoint, it would
>seem that an internal modem has a little less hardware between the
>phone line and the bus, and so might have less trouble at the
>higher performance rates.  But then, I tend to doubt that it
>makes any difference you could notice from a device driver.

Ah, here's the nasty!  If you use an internal modem, what are the default
values of CTS/RTS/DCD/DTR?  Do they float?  Are they sinked low?  Are they
sinked high?

Generally, on a UNIX system, it pays to not buy an internal modem.  Sure,
the fancy ones will let you peg the signals seen by the computer for the
pseudo-RS232 level to values that will let it work -- but will it work
right?  Generally, no, not unless the UART is seperate from the modem
chips, and probably not then.  With a connector, you are guaranteed you
can buy a 150 ohm resistor and do the job if it isn't done correctly
by the serial board (I know of only one (it's built-in) serial board where
this is necessary).

Why is this important?  Well, you need tobe able to have DCD sinked low
unless carrier is present.  You need CTS sinked low unless it is raised
by the device (indicating it is truly clear to send)  You want the same
for RTS.  You want DTR to only go high (allowing the modem to answer)
when it is asserted by the driver (ie: a process, like getty, has the
port open.  You want HUPCL and ~CLOCAL set so that when you log out, it
hangs up the phone (1 22Hr long distance call will tell you this real fast!).
You want the "login:" message to only pop up (ie: getty's open succeeds)
only when carrier is present so that your modem doesn't talk you serial
port into SILO overflows.

And all of this dependant on the tty driver understanding either /dev/cua0
or the partial open hack to work right.


                    Terry Lambert
                    [e-mail]
                    [e-mail]

---
Disclaimer:  Any opinions in this posting are my own and not those of
my present or previous employers.