Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!spool2.mu.edu!uunet!sco!md
From: md@sco.COM (Michael Davidson)
Newsgroups: comp.sys.ibm.pc.hardware
Subject: Re: How to set serial port to 115k baud?
Message-ID: <9553@scolex.sco.COM>
Date: 11 Jan 91 20:59:37 GMT
References: <3815@ns-mx.uiowa.edu> <9493@scolex.sco.COM> <3835@ns-mx.uiowa.edu>
Sender: news@sco.COM
Organization: The Santa Cruz Operation, Inc.
Lines: 61


In article <3835@ns-mx.uiowa.edu> williams@umaxc.weeg.uiowa.edu.UUCP (Kent Williams) writes:
>In article <9493@scolex.sco.COM> md@sco.COM (Michael Davidson) writes:
>>You *can* run a 16450 at 115.2K bps but your mileage will certainly
>>vary - the 16450 or 16550 will probably hold up OK but you may have
>>some problems with with the RS232 drivers - and don't expect to get
>>away with more than a few feet of cable at that speed.
>>
>Even with a 386, 115.2K is pushing the limit of what you can do with
>interrupt driven communication.  The queue in the 16550 would help some.
>Has anyone at SCO run a dumb card under unix at 57K?

Yes - I regularly run standard dumb serial cards (both a standard COM1
style port and an AST style 4 port dumb card) at 57.6K under SCO
UNIX 3.2.2. In both cases these cards have been upgraded to have 16550
chips instead of 16450's. The 16 byte FIFO in the 16550 makes this
quite practical - the default configuration of the 16550 under SCO
UNIX 3.2.2 is to trigger an interrupt when the receive FIFO has 14
characters in it - this reduces the number of interrupts considerably
(to much less than half the number you would get from a 16450 running
at a continuous 9600 bps) - however, the maximum interrupt latency
allowable is only 2 character periods (ie you get an interrupt when the
FIFO has 14 characters in it so you have to start emptying the FIFO
before it fills up completely 2 characters later) - this maximum interrupt
latency doesn't seem to be a problem on a 25MHz 386 - if it does become
a problem the solution is to reconfigure the FIFO to interrupt when it
contains only 8 characters - this still reduces the interrupt load and
gives a full 8 character periods (ie well over 1 millisecond at 57.6K)
before the FIFO fills up and data overrun occurs - no 386 machine should
have *any* problem getting the data in this case.

A couple of comments here may be of help to anyone who wants to
experiment with this:

    The standard SCO serial driver for dumb cards only supports
    baud rates up to 38.4K (B19200 and B38400 are both defined
    in /usr/include/sys/termio.h as alternatives to the traditional
    EXTA and EXTB baud rate definitions).

    The baud rate divisors for the 16450 or 16550 chip in the serial
    driver are stored in a 16 element array called "bauddivisor" in
    the sio driver.

    The divisor for 38.4K is stored in the last element of this array
    (at address "bauddivisor + 0x3c") and has the value 3 - if you want
    to experiment with 57.6K you should patch this value to be a 2.
    Then setting a tty line to speed EXTB will get you 57.6K.

    If you are attempting to receive data at 57.6K you may experience
    problems with the standard size of the raw character queue in the
    tty input processing code. By default this size is 256 and if
    more than 256 bytes are received before your application has time
    to read the data (which is very possible at 57.6K) then data will
    be lost. Fortunately this limit is patchable. The kernel variable
    ttyhog defines this value - the default is 256 bytes - I would
    suggest increasing this to at least 1024 if you want to handle
    high data rates.

Please note that we do not *support* operation at these higher speeds
but I thought that this information might be useful to anyone who
wanted to experiment.