mhw@fithp (Marc Weinstein) (04/21/91)
Thought I'd share some experiences with you netters. I've heard the
*intense* controversy Re: Hardware Flow Control working vs. not working
on the UNIXPC/3b1. Here's my two cents...
A friend of mine and I recently bought Practical Peripherals 9600SA
modems - pretty nice, and pretty cheap. $449 from Telemart in Arizona.
1-800-426-6659 in case anyone's interested. Anyway...
These modems can talk V.32, V.42bis, MNP, etc, plus have Automatic Speed
Buffering (modem-to-modem connection and modem-to-port connection can be
at different baud rates) and automatic "best-protocol" negotation. Our
goal was to get the fastest possible data transfer rate between our PCs.
We first tried setting both of our port rates to 19200, and tried V.42bis
between the PCs (this SHOULD be the fastest - faster than MNP apparently).
With built-in error correction, we can use the UUCP 'e' protocol, which
apparently makes a BIG difference at higher baud rates since there's no
waiting for response, wasting precious connect time. The Transmit light
would be pegged. Unfortunately, his machine is running UNIX 3.5, so it
appears as though his HFC isn't working. We had serious problems - the
modems could push the interface faster than the PCs (at least his) can
handle it, so the file would get "transferred" but the far end wouldn't
recognize it - the 'C' message from UUCP would get lost, and UUCP would
not recognize that the file transmission had completed.
Interestingly, I then tried calling another system which IS running 3.51m,
but only supports MNP. I first tried with HFC disabled on my port.
My Transmit light was pegged, and, sure enough, the transmission failed.
Same problem. My system thought the transfer rate was 1918 Bps - pretty
damn good! But incorrect. Probably, his system was getting garbage, or
at least didn't recognize when the file transmission was completed. So,
I then enabled HFC, and this time the Transmit light was NOT pegged, but
rather would blink on and off - this leads me to conclude that HFC DOES
work (but perhaps not reliably). The transfer was successful, but the
effective transfer rate had dropped to 973 Bps! Quite a difference.
Now, this was a binary file, so I might have seen better with a text file,
but this told me that HFC was restricting the data transfer quite a bit.
And, as it turns out, even though the file transferred successfully, UUCP
still got confused, and the call terminated abnormally. So, so much for
using a 19200 port connection to the modem.
So, we then changed our PC-to-modem connection to 9600 baud, and everything
is working fine - no problems. Our guess is that the port, and HFC, works
reliably at 9600 baud. The port rate becomes the limiting factor - since
each end can only feed 9600 baud of data to the modem, there's never a
danger of exceeding its capacity, or even of taxing HFC with a lot of actvity.
Unfortunately, this means that the absolute highest transfer rate is 960 Bps,
which we now see consistently using V.42bis between the modems. Not bad, but
not what we had hoped.
We plan to leave things this way until he gets UNIX 3.51m installed, and
we're also going to install some updated ROMs in his modem. Then, we'll
try 19200 on the ports again. We'll keep our fingers crossed.
--
Marc Weinstein
{simon,royko,tellab5}!linac!fithp!mhw Elmhurst, IL
-or- {internet host}!linac.fnal.gov!fithp!mhwbruce@balilly (Bruce Lilly) (04/21/91)
[ Followup set to comp.sys.3b1, since the other groups no longer exist... ] In article <1991Apr21.020111.28633@fithp> mhw@fithp (Marc Weinstein) writes: >[ ... ] >So, we then changed our PC-to-modem connection to 9600 baud, and everything >is working fine - no problems. Our guess is that the port, and HFC, works >reliably at 9600 baud. The port rate becomes the limiting factor - since >each end can only feed 9600 baud of data to the modem, there's never a >danger of exceeding its capacity, or even of taxing HFC with a lot of actvity. >Unfortunately, this means that the absolute highest transfer rate is 960 Bps, >which we now see consistently using V.42bis between the modems. Not bad, but >not what we had hoped. Some questions: 1) were you using the built-in RS-232-C port (/dev/tty000), or an EIA or combo card? 2) what loadable drivers are loaded, and in what order (run /etc/lddrv/lddrv -s")? "/etc/lddrv/lddrv -s")? 3) have you tried transfers while other system activity was taking place, particularly while some large program was running (e.g. try switching windows a few times using shift-suspend or shift-resume)? -- Bruce Lilly blilly!balilly!bruce@sonyd1.Broadcast.Sony.COM
murphyn@motcid.UUCP (Neal P. Murphy) (04/24/91)
bruce@balilly (Bruce Lilly) writes: >[ Followup set to comp.sys.3b1, since the other groups no longer exist... ] You missed at least one group. Besides, I'm still seeing a little traffic on the unix-pc groups from time to time. NPN
mhw@fithp (Marc Weinstein) (04/25/91)
From article <1991Apr21.160738.29629@blilly.UUCP>, by bruce@balilly (Bruce Lilly): > [ Followup set to comp.sys.3b1, since the other groups no longer exist... ] > > In article <1991Apr21.020111.28633@fithp> mhw@fithp (Marc Weinstein) writes: >>[ ... ] >>So, we then changed our PC-to-modem connection to 9600 baud, and everything >>is working fine - no problems. Our guess is that the port, and HFC, works >>reliably at 9600 baud. >> ... > > Some questions: > 1) were you using the built-in RS-232-C port (/dev/tty000), or an EIA or > combo card? Originally, we were using the Combo card ports, and we wondered whether that could have anything to do with it. So, we switched to tty000, and saw the same problems. We're still loading 3.51m on the remote system, so we're not sure where the problems are coming from. > 2) what loadable drivers are loaded, and in what order (run > "/etc/lddrv/lddrv -s")? /etc/lddrv/lddrv -s: DEVNAME ID BLK CHAR LINE SIZE ADDR FLAGS wind 0 -1 7 -1 0x9000 0x54000 ALLOC BOUND lipc 1 -1 -1 -1 0x7000 0x360000 ALLOC BOUND kbd 2 -1 9 -1 0x1000 0x5d000 ALLOC BOUND cmb 3 -1 -1 -1 0x3000 0x367000 ALLOC BOUND ate 4 -1 -1 -1 0x1000 0x5e000 ALLOC BOUND > 3) have you tried transfers while other system activity was taking place, > particularly while some large program was running (e.g. try switching > windows a few times using shift-suspend or shift-resume)? I had a lot of applications running at once. Netnews software, mail tools, changing windows, etc. I exercised it pretty well. -- Marc Weinstein {simon,royko,tellab5}!linac!fithp!mhw Elmhurst, IL -or- {internet host}!linac.fnal.gov!fithp!mhw