From: rrezaian@austral.chi.il.us (Russell Rezaian)
Newsgroups: biz.comp.telebit,comp.dcom.modems,comp.sys.sun.hardware
Subject: Re: Advice re. Sparc IPC and Worldblazer
Summary: Sun serial ports strike again.
Date: 30 Aug 92 20:07:24 GMT
Followup-To: comp.sys.sun.hardware
Organization: DOC Data Processing Systems

In article <8374@sirius.ucs.adelaide.edu.au> dclunie@ucs.adelaide.edu.au (David Clunie) writes:
>This may seem a little basic, but ...

Yes, but that doesn't mean that it isn't important, or that the answers
are simple...

>I have a Sparc IPC and a Worldblazer. They are connected via one of the
>standard two serial ports with the cable in the sun kit and a gender
>changer. I have them configured for hardware flow control at 38,400
>baud. They talk happily together (especially if I set AT&C2 to keep
>CD asserted). However, when I dialup a host and connect at say 14,400
>bits of text get dropped (much more often if compression is enabled).

This looks like the standard hardware flow control problems that have been
plaguing most workstations since the advent of high speed modems.

You might also have trouble with the system when you force CD high all the
time.  If you ever want to allow incoming dialup connections over that
port you need CD to go down to let the system hang up.  If you never
have incoming connections you can usually manually kill things in the
event of an abnormally dropped connection.  It's still a bit annoying
though...

>Now this would seem to be a standard handshaking problem, and the
>host people swear that there end is just fine so it must be me. Problem
>is that if I switch to software handshaking the problem is still
>there ... seems very odd to me.

Well, here's a few comments, mayhap they might offer a few ideas.  Sun
serial drivers in OS versions up to something like 4.1.2 only support
hardware handshaking in one direction.  (There may be patches, I am not
aware of any, and this may vary depending on platform.)  The modem can
slow the Sun down if the Sun is sending data too fast for the link, BUT
the Sun has no way to slow the modem down if incoming data overflows
buffers (or in some cases overloads the CPU).  Hence your lost data.

If the modem uses compression, then more data can be sent over the phone
line and data will be sent to the computer at a higer rate, thus the
problem of overloaded buffers will be exacerbated.

Software handshaking won't work, because of the transmission latency.  It
takes too long for the data chars that are supposed to halt transmission
to make it over the link, and the buffers still overflow.  Sometimes the
software handshaking will simply be lost.  Compression adds even more
latency, and only makes the problem worse.

>Now, my question is basically has anyone else got this configuration
>to work. People have told me that Sparc's are terrible at handling
>interrupts and can't cope with 38,400 baud and that is my problem ...

This is the generally accepted wisdom, I know people who claim to have
considerable success using very high speed modems with the internal
serial ports.  Your milage will vary :-)  I have also been told that the
IPC/IPX machines do not handle high speed serial connections as well as
the SparcStations (Sparc2's mostly)  I have no idea whether that's true.

>seems odd that compression would worsen this situation. The IPC
>manual says to use software flow control ... does this mean it
>can't do hardware flow control ? Seems to work most of the time
>though ...

It will work in many instances.  That's the anoying thing.  There is
hardware flow controll, it isn't fully implemented.  As for compression
making things worse, see my point above.

>File transfers with various protocols work ok ... but i guess the
>small packets and acknowledgements conceal any real problems.

Not to mention that most file protocols accidentally implement the only
types of software flow control that work in these circumstances.  Compare
zmodem to kermit sometime though.  It is an interesting experiment, and
facinating to see kermit outperform zmodem...  (zmodem performs very
poorly on error recovery)

>In summary I am a little frustrated, as I always seem to get when
>dealing with serial ports :) 

Join the club :-)

>I am considering picking up a cheap
>SS1 with a multi-port serial card to use as a dialup service, with
>Worldblazers on the end. This little preliminary experience with my
>own workstation is beginning to put me off ... !

You might get this to work, HOWEVER, many of the multiserial cards for
Sparcs are even worse than the internal ports at high speed.  If you go
that route, make sure the board is a "smart board" with a decent on board
co-processor.

A far better, and cheaper solution is to go out and buy an ethernet based
terinal server that lets you do a "remote telnet" to attach terminal
server ports to a local machine.  Suns are great at ethernet flow control,
and any terminal server that can't handle high speed modems is IMHO
garbage.

>It occurred to me that perhaps the problem is with the Worldblazer
>firmware (I have the 5.00 rom's from memory) but this seems extremely
>unlikely to me.

I never had any problems of this nature with the 5.0 formware on my
WorldBlazer.  And when I could get hardware handshaking working (I have
similar, but different problems, the board I am using supports full
hardware handshake, and is an excellent high speed board, but it is nearly
impossible to turn on flow control using the default system utilities
(like UUCP)) I had no problems.  The new ROMS are shipping, but that
probably isn't your problem.

>Anyway ... any comments would be appreciated ! Helpful or not !

Well, I don't know if this has been helpfull, but I hope so.  Note follow
up set in headers.
--
Russell Rezaian			|  rrezaian@austral.chi.il.us