SUMMARY: Better the 38.4kbps on serial port?

From: Henrik Schmiediche (henrik@PICARD.tamu.edu)
Date: Fri Feb 17 1995 - 19:35:57 CST


    Hello,
Thanks to all who responded to my post. For reference here it is again:

   I have heard that there are unsupported ways of getting better then
   38400bps on a Sparc serial port. Maybe it is not recommendable, but
   could anyone tell me how? I have a Sparc 20 running Solaris 2.4.

The bottomline:

    1) Yes it is possible to run at Speeds higher the 38.4kbps by
       modifying the kernel. Specifically, speeds of 51200 and 76800
       can be achieved.
    2) Very few modems can handle these non-standard speeds.
    3) The ppp package dp-3.1.2 had build in support for these
       higher speeds.
    4) The best way to get greater then 38.4kpbs serial support
       is to buy an add on card or periperal device that can handle
       higher speeds. Several are on the market.

Below is a segment from the dp-3.1.2 docs that explains how to
modify the kernel for faster the 38.3kbps speeds. After that are
selected and edited comments for users who responded to my query.

Thanks again!

    - Henrik

*************************************************************************

8.1 Sun zs Ports
 
The zs ports on the Suns are capable of going faster than 38400. The
divisor in the hardware timer chip is set so that
 
    baud_rate = 4915200 / ((divisor + 2) * 2 * 16)
 
Here are some example divisors
 
      Divisor Baud Rate
        510 300
        62 2400
        14 9600
        6 19200
        2 38400
        1 51200
        0 76800
 
So, there is a little room for going faster. Unfortunately, there is
not a 57600 baud rate available. However, some modems can handle 76800
(such as the Telebit Worldblazer), and that can be set just as easily.
By default, the "-DFASTSZ" flag is set in the Makefile.hw file.
So, code will be compiled into the program that will recognize
76800 as a valid baud rate. Since all 16 table entries are used up,
we must replace one of the unused baud rate divisors with a 0 divisor.
I have never seen anyone use 50 baud devices. The code that recognizes
76800, uses the table entry for 50 baud.
 
In order to modify the kernel table for the zs divisors, use the
following adb commands:
 
    # adb -w -k /dev/ksyms /dev/mem
    zs_speeds/16d
    _zs_speeds:
    _zs_speeds: 0 3070 2046 1394 1140 1022 766 510
                    254 126 83 62 30 14 6 2
    zs_speeds+2/w0
    _zs_speeds+2: 0xbfe = 0x0
    zs_speeds/16d
    _zs_speeds:
    _zs_speeds: 0 0 2046 1394 1140 1022 766 510
                    254 126 83 62 30 14 6 2
 
This modifies the in-memory copy only. To modify /vmunix, use ?w0.
To modify for all future kernels, modify /usr/sys/`arch`/OBJ/zs_async.o

*****************************************************************************

>From raoul@mit.edu Tue Feb 14 00:39:24 1995

Don't bother. Going higher than that is useful for PC's, where the
lack of interrupt handling or genuine multi-tasking makes you want to
process big greasy wads of bytes at a time, downloading them into a
serial buffer. But on Sparc's, you can severely overload the Sbus by
driving too many lines too fast simultaneously. Even 19.2 on a Sparc
II gives transmission rates better than 1.2 kbytes/second with kermit,
which is plenty for normal use.

                                Nico Garcia
                                raoul@mit.edu

>From bern@penthesilea.uni-trier.de Tue Feb 14 01:00:24 1995

Not sure about 2.x, and I don't have the How-To for 1.x handy, but the
basic Thing to do is that you go over to the Kernel Files and have
some Bit Patterns of the Speed Bits (there are three of these, if I'm
not very much mistaken) interpreted as Speed XYZ, instead of one of
the lower Speeds used normally.

Note that 38k4 is already considered unsuported, and that the UARTs
used in SUNs *definitely* can do faster than 38k4.

Regards, J. Bern

>From netcom.com!zodiac!zcon.com!szh Tue Feb 14 01:24:35 1995

It is not recommended. You will get data overruns and lots of
problems.

Plus the two rates that you get using this modification (51200 and
76800) are pretty much not useful for most people - in fact, the only
thing that I know that uses 76800 is a ZyXEL modem. Nothing uses
51200.

The only way I know how is for SunOS 4.1.x - it is a kernel
modification. So this will not help you out.

From: csmoko@relay.nswc.navy.mil (Chuck Smoko - E81)

Henrik,
Here is a post that I found that should have the info that you want.
The problem that I found was that the bauds above 38400 were not all
that common. I.e. not 57600!

                                                                chuck

PS: You may wish to apple the sun patch that does the hw flow control
for 4.1.x. It is # 100513-04. I have it if you need it.

On Jan 6, 9:39pm, Lupe Christoph wrote:
} >Sun Consulting sales a high speed patch but it is pricy. Alternatives is to
} >get a serial port board from CoSystems(or any other 3rd party company)
} >which supports higher speed drivers with their product. The latter solution
} >is supposed to be cheaper.

From: sdr@rdga3.att.com (S. D. Raffensberger 52882 (RD))

I wouldn't waste my time trying. The SUN serial ports
are crap even at 38,400. Going faster would only make
them worse.

SBUS cards with really fast serial ports (115K) are
available from third party vendors at arount $250.
If you want fast serial data transfer, even Sun
recommends ignoring ttya and ttyb.

Steve Raffensberger
AT&T

From: bidwell@andrews.edu (Daniel R. Bidwell)

I have a Sparc 1 running Solaris 2.4 with a Magma High Speed Serial
board in it that has one paralell printer port and two serial ports that
run at 115KB. It is an Sbus card and comes with device drives for
Solaris 2.x so I don't see any reason that it shouldn't run on a Sparc
20 also.

--
Henrik Schmiediche, Dept. of Statistics, Texas A&M, College Station, TX 77843
E-mail: henrik@stat.tamu.edu  |  Tel: (409) 862-1764   |  Fax: (409) 845-3144
Finger for pgp 2.6 key, fingerprint: E867 D9DB 9616 5DAC  0F67 FE98 77FE 8583



This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:10:16 CDT