Buying V.32bis, V.42bis modems for the Sun IPC and PCs
A few months ago my boss asked me to get some high speed modems for
our Sun IPC and home PCs. It turned out to be more difficult than I
Aside from the issue of finding a good cheap modem, there was some
question about the ability of the IPC to use high speed modems.
There's a big discussion of that issue below, but for those who don't
have a Sun, here's the modems I picked. I needed 2 internal and 1
external modem, and I'm still interested in getting a pocket modem. I
only considered V.32bis, V.42bis fax modems with 14.4Kbps for both fax
and data, plus the v.42bis compression.
Infotel internal, $199, and external for $269 from Midwest Micro (800)
972-8822. They need more phone lines at Midwest Micro, but I was
patient and finally got these prices. I was unable to locate anyone
who could assure me that the internal modem had a 16550 UART, but
since Infotel was uniformly praised in the email I recieved, I assume
Zoom was a close runner up. I found the following prices at
Microcomputer Concepts (800) 772-3914: Zoom internal $219, external
$269, but the internal modems were on backorder. So they lose out
because of the $40 difference and the backordered status. Oh well,
that's capitalism! But I should also mention that there was a Zoom
internal on sale this week at Best Buy for $199, so you could probably
find it around. And Zoom was also uniformly praised by people who
responded to me about high-speed modems.
Sun Serial Port Problems:
Sun workstations are notorious for problems with their serial ports. I
got many reports from people who bought high speed modems, only to
find that the Sun serial ports couldn't handle the hardware
handshaking. Here's a sample:
From: email@example.com (Hannes Fischer)
Subject: Re: Anyone out there successfully get a 14.4K modem running on a Sun?
In comp.sys.sun.admin you write:
>I have been in the market for some high speed modems for me and my
>boss to be able to dial in from home or from the road to our Sun IPC.
>There has been a little talk on the net that the sun can't handle the
>throughput in the serial port due to stupid Sun problems with hardware
>flow control, which can be fixed, but only at a high price.
I'm running a USR Courier V.32bis on a SLC. The problem is the
sun won't do inbound flow control (lower RTS when it's unable
to accept data) so you get "zs0: silo overflow" when uploading
stuff, or doing heavy SLIP/PPP traffic. Outbound h/w flow control
does work (the sun stops sending when the modem lowers CTS).
Bottom line: it *does* work, but you need to use a protocol when
doing uploads, to account for occasional character losses.
A more severe problem is that the sun's tty drivers (I'm running 4.1.1)
gets into a state where there's a getty on the serial port, but
DTR remains low - killing the getty process will restore the
port. This might be a problem with DTR raising too fast when a user
logs out - I didn't check this, to.
Many others reported the problems with the hardware handshaking, but
no one else mentioned the problem with the getty and the DTR, but as I
am also running SunOS 4.1.1 this did not make me happy. I got many
different suggestions on how to fix the Sun serail port problem
ranging from buying more stuff to switching a jumper on the
Here's what the comp.sys.sun FAQ has to say about it:
36) Do the Sun serial ports support RTS/CTS flow control?
The serial port hardware can do CTS-based control of the flow of
data *from* the Sun *out* the serial port automatically. The
tty driver option for that is the CRTSCTS option; it can be
the "printcap" "ms" capability for a printer;
in the "gettytab" "ms", "m0", "m1", or "m2" capabilities
for a dial-in port;
the "STTY=" option for a dial-out line for UUCP or "cu"
[check the UUCP documentation for details];
and can be specified with the "hf" capability in "/etc/remote"
The hardware cannot directly do RTS-based control of the flow of
data *into* the Sun, and the software does not currently support
controlling the flow of data into the Sun with RTS.
NOTE: the EEPROM options in newer Suns do not affect the flow
control performed by the OS; in fact, the OS ignores the
"ttya-mode", "ttyb-mode", "ttya-rts-dtr-off", and
"ttyb-rts-dtr-off" EEPROM options entirely. You don't need to
set them to change the way the OS handles the tty, and even if
you do set them, it won't change the way the OS handles the tty.
However, I also got the following:
Date: Mon, 14 Dec 92 15:19:24 PST
From: mike@nit.PacTel.COM (Mike Cantu)
Subject: Modems on Suns
I have been using Telebit 2500 modems on Suns (most sun4 models) for the past
year or so. I don't know anything about throughput problems tho, we do
PEP uucp transfers at will.
The flow control trick is a little-documented jumper config on the motherboard.
There is a jumper in the middle of the board, towards the back (where you
plug in the cables) that is labled RS-232 and RS-423. For some unknown
reason (to me, at least) Sun ships all workstations with their serial ports
configured as RS-423 devices. Anyways, set it to RS-232 and you're set.
Then make sure you set the modem for hardware flow control. I have mine
setup with the port locked at 19200. The modem adjusts its speed to talk
to the remote modem, but always speaks to the Sun at 19200.
My local guru also mentioned the jumper on the motherboard trick, and
even showed me the documentaiton, but he had never tried a high-speed
modem. The documentation is in the SPARCstation IPC Installation
Guide, that little spiral bound doohickey, on page 80-81. It
desrcibes how to switch the ports between RS232 and RS423. My handy
"Microprocessor Based Design" by Slater tells me that RS423 is
essentially the same, but "updates the basic approach of RS-232, using
voltage levels and switching speeds more appropriate for modern
systems." Since most RS-232 devices don't use anything near the 12 V
signal level, most (if not all) will work with the lower voltage 423
standard, which, I guess, is why Sun configures it to 423 by default.
However, why this should make the hardware handshaking work, or if it
does, is not clear to me. I have no reason to doubt it, since I
haven't tried it. As it turns out I got two messages concerning the
Central Data SCSI terminal servers, and it turns out that I already
have one of these hooked on, so that solves me problems right there.
Maybe someday I'll try out that jumper trick, but then again, as I
have many useds for my free time, none of which include RS-232
interfacing, I probably won't do anything if the Centeral Data stuff
works as advertised.
Here's the two messages, one from Central Data and one from a user:
Date: Tue, 29 Dec 17:01:19 1992
Subject: modem speeds
> Our scsiTerminal Server has properly implemented bi-directional hardware
> flow control for this exact reason, and is what I've been using to run a
> few different V.32bis modems for quite some time now. Rather than post
> data sheets-n-stuff here, why don't you send me email if you want details
> on our products. They are local ports to the sun (NOT ptty's), and support
> baud rates up to 57.6K.
> Also, anyone else seeing this posting is also welcome to email, call, or
> FAX inquiries in. We also have a VAR program, an educational discount, and
> quantity discounts.
> >Thanks in advance.
> Vic Serbe "Makers of the scsiTerminal Server."
> Central Data scsiSupport | PH# (800) 482-0315 x237 |
> firstname.lastname@example.org | +1 (217) 359-8010 x237 |
> uunet!cd.com!vics | FAX +1 (217) 359-6904 |
Date: Fri, 1 Jan 93 02:11:34 CST
From: email@example.com.AU (David Clunie)
Subject: Re: Anyone out there successfully get a 14.4
Whatever anyone tells you about how their config works, if you use a high-speed
modem at any DTE speed other than the modulation speed, or use compression or
erro-corretion, it WILL NOT WORK. Sun's cannot do hardware flow control on incoming
data. I wasted weeks if not months on this.
I ended up buying a SCSI terminal server from Central Data that plugs in the
SCSI port, doesn't use an SBUS slot, can be shifted to another non-Sun machine
and is very cheap. Highly recommended. Excellent customer support. Morningstar
supports them for their slip/ppp product which is a good recommendation if you
-- Don't blame me, I voted against Amendment 2!
Edward Hartnett firstname.lastname@example.org
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:07:24 CDT