Return to BSD News archive
Newsgroups: comp.unix.bsd Path: sserve!manuel!munnari.oz.au!mips!decwrl!sdd.hp.com!caen!hellgate.utah.edu!fcom.cc.utah.edu!gateway.univel.com!ns.novell.com!gateway.novell.com!thisbe.Eng.Sandy.Novell.COM!terry From: terry@thisbe.Eng.Sandy.Novell.COM (Terry Lambert) Subject: Re: (386BSD) Modems and com ports Message-ID: <1992Aug20.213721.4548@gateway.novell.com> Keywords: internal or external? Sender: news@gateway.novell.com (NetNews) Nntp-Posting-Host: thisbe.eng.sandy.novell.com Organization: Novell NPD -- Sandy, UT References: <1992Aug20.171557.30071@watson.ibm.com> Date: Thu, 20 Aug 1992 21:37:21 GMT Lines: 131 In article <1992Aug20.171557.30071@watson.ibm.com> cchase@watson.ibm.com (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 terry_lambert@gateway.novell.com terry@icarus.weber.edu --- Disclaimer: Any opinions in this posting are my own and not those of my present or previous employers.