mhw@fithp (Marc Weinstein) (05/19/91)
Well, it is almost time to give up. Thad's article seemed to sum it up
quite nicely. It appears that HFC, with some playing on our part, works
just fine when sending data out, but is worthless on incoming data. Here's
what we saw...
As we left our heroes in the last episode, they had used two Prac Periph
modems, talking using 9600 baud V.42bis, with port speeds set to 19200.
It took a separate port conditioning daemon, running all the time and
reapplying port settings every ten-or-so seconds, to get HFC to go on
and stay on. Don't trust the gettydefs settings, and don't think that
uucico will apply HFC.
With both of our port speeds set to 19200, we attempted to send some
files. First, we sent compressed news batches. Oh my God!!! It worked!!!
They went through just fine, showing a transfer rate of 1079 Bps. This
is definitely an improvement over the 959 Bps we typically see with
9600 baud port speeds. We were ecstatic! Then, we tries sending something
which was NOT already compressed - we used the 3.51m kernel - compresses
pretty much using V.42bis. Total failure! The sending system spit out
a stat showing file transfer at over 1800 Bps, but the receiving system
NEVER saw the Completion message in UUCP. It never recognized the file
coming in. We also tried MNP5 - same results.
This makes sense. If the data to be transferred is already compressed,
then there's not much the modem compression will add, so the throughput
at the 3b1 port will be very close to the throughput on the phone line,
which is 9600 baud, or a bit higher when the start/stop bits are removed.
So, the system limits itself to some data transmission rate over the port,
and the 3b1 seems to be able to handle it. Then, when you pass it something
which is NOT compressed, V.42bis can really crunch it, and therefore the
DCE-to-DCE rate of transfer ends up being much slower than that at the port,
and the port can't keep up. 1800 Bps is fairly close to the 19200
capability, and the PC loses characters. So, if there were some way to
always limit the transmission rate between modems, a 19200 port speed
could probably be maintained.
Now, to adequately demonstrate that HFC works in one direction, we now
set one of the port speeds to 9600 baud. Now, if the system with the
9600 baud port speed sends data to the one with the 19200 port speed,
then the port speed on the sending system is limiting the rate of
transfer - everything works fine. If the receiving system is the one
with the 9600 port speed, then the following happens. The modems
continue to talk at the same rate, but the modem at the receiving end
starts to buffer incoming data, since the data is arriving faster than
the port can offload it, and eventually the modem detects pending
overflow. So, the modem asserts HFC, which is detected by the sending
modem, which asserts HFC to the 3b1. Now, the port at the 3b1 detects
CTS being negated, and it stops the flow of data. Fine! Everything
works ok. And, in the example I gave above where we sent compressed
batches with a port speed of 19200, the SENDING modem's buffer starts
to fill up, because the port is feeding it data which is can't send
to the remote modem fast enough, and the modem eventually asserts HFC,
which the outgoing port detects and limits the flow of data.
So, the ideal would be to arrange a setup where compression is disabled
for the sending of already-compressed files (since the modem compression
would cause the rate to go too high) while for less compressible files
the compression would be enabled, thus helping the throughput. I'm
not sure if this can be achieved, so we're close to giving up. We still
plan to try the UUCP g protocol with 19200 - perhaps the ACK nature of
the protocol would keep the throughput low enough to allow the 3b1
to keep up.
--
Marc Weinstein
{simon,royko,tellab5}!linac!fithp!mhw Elmhurst, IL
-or- {internet host}!linac.fnal.gov!fithp!mhwthad@public.BTR.COM (Thaddeus P. Floryan) (05/19/91)
In article <1991May19.030549.3983@ims.alaska.edu> floyd@ims.alaska.edu (Floyd Davidson) writes: {comments re: HFC on the 3B1 per the extractions:} > Maybe it does, maybe not. but... > [...] > HFC doesn't have anything to do with the rate of data transfer > between the modems. The sending modem is NOT going to detect > anything as a result of the receiving modem asserting HFC. > [...] > I would suggest that anyone else who wants further > information on this should bring it up in the comp.dcom.modems > group. Let's not mingle two issues here (HFC and modem transfers). Incoming HFC on the 3B1 simply does NOT work no matter whether one is directly connected with hardlines or receiving via a modem. Besides the fact my own tests (in 1987 and 1991) indicate it doesn't work, comments from "reliable sources" (no pun) indicate the incoming HFC code has NOT been compiled into the distributed code (due to #ifdef ...(and (presumably) untested routines)). Outgoing HFC works just fine on the 3B1, both over hardlines and modems. Thus I disagree with the comment above re: "...sending modem is NOT going to detect anything..." because calling from my office at 2400 baud into a T2500 connected to my 3B1 (fixed at 9600 baud) works just fine ... the 3B1 does "somehow" detect my office computer's HFC signal to STOP to prevent its (the office computer's) buffer from overflowing when the 3B1 is sending at 9600 baud but the office computer is receiving at 2400 baud. Magic? Swinging dead chickens over one's head while dancing under a full moon in one's Jockey shorts? Dunno. The audience in comp.dcom.modems probably doesn't even know (or care) what a 3B1 and its problems are, so why burden them? The 3B1 is one heckuva nice system (I have many of them), but it's NOT a powerhouse by today's standards. My 3B1 are (subjectively) faster than the Mac II (68020) running A/UX at my office, but both my Sun and MightyFrames run circles around most other systems I use on a regular basis. For example, I've given up optimizing streaming tape I/O on the 3B1 with double buffering techniques because the disk I/O on the 3B1 seems to be the bottleneck as shown by running the "diskperf" program (originally designed to test Suns). The max on the 3B1 (ANY disk) is about 55KBytes/sec which is too slow to stream the tape drive; the MightyFrame's stats simply went off the scale (the same program) at over 350,000 bytes/sec. The ephem program which I run daily on my 3B1 calculates to the exact same results on both the MightyFrame and Sun, but the MightyFrame version seems about 100 times faster (the 3B1 is about the same speed as my VAX-11/780, though, for this calculation! (planetary orbits, astronomical coords, rise/set times, etc)) (Yet, strangely, the 3B1 can do, say, an uncompress, faster than my '020 Amiga whose diskperf is 650Kbytes/sec; must be a factor of single-threaded vs. multi-threaded file systems; comments?) Point being: the 3B1 doesn't have enough "horsepower" to handle thousands of interrupts per second. This point slammed home quite clearly earlier today when "someone" attempted a uucp transfer from my system while a tape backup was ongoing ... uucp (HDB (over serial line)) just simply up'd and died. As a reference point, my VAX-11/780 cannot do it either, and the 3B1 (in my opinion) has better serial I/O capability than the VAX with its DZ-11. But do you see me selling off my 3B1s? NO! I accept the fact the serial I/O is limited to 9600 baud (still better than my VAXen) and ENJOY all the other great things of which the 3B1 IS capable (gcc, emacs, email, klondike, etc. :-) Even though my own MightyFrames (two) haven't yet shown problems at 19200 (or even 38400), CT *DID* manufacture a "Terminal Accelerator" for those systems to even further improve serial I/O performance (and, no, I don't have a "TA" in either of my systems, but considering the MightyFrame's Ethernet cards have a dedicated MC68010 (which is the 3B1's PRIMARY CPU) just to handle the Ether stuff, I wouldn't be surprised to learn the "TA" card also has a 68010. Even the Apple laser printers have dedicated 68020 CPU's to handle the PostScript stuff connected to a system sporting just a 68000 as its PRIMARY CPU).) If you want speed, get a "box" boasting a 68040, 88K, R4000, etc. and be prepared to spend Big Buck$, and be faced with a possibly "immature" kernel. If you want a neato (and affordable, solid and reliable) UNIX box, get a 3B1. I *LIKE* the 3B1 and its kin, and have put MY money where my mouth is, now owning seven (7) 3B1, two MiniFrames, two MightyFrames, one Sun, one Iris, one PS/2-80 (w/ AIX), several Amigas (68000, 68010, 68020), and some other systems including the VAXen, and I expect the 3B1 systems in my "stable" to outlast ALL those others. For 25 years up to four years ago, I was a "DEC diehard"; no longer. The 3B1 and its user/owner community reminds me so much of the ORIGINAL hacker community of the '60s that ... wellllll, no need to get maudlin here. Damn! I wish AT&T didn't screw the 3B1 marketing so badly; well, my commercial software products should soon appear on the 3B1's brethren and kindred souls after decades on the DEC machines (PDP-10, DEC-20, and VAXen). And I'm gonna have at least one 3B1 in this year's West Coast Computer Faire, May 30 - June 2, at Moscone Center in San Francisco in the AT&T Users' Group booth! If you're in the area, gimme a call as I have discount admission tickets, and if you can help in the booth (4 hrs max) I'll get you in for free. And, no, I am NOT employed by AT&T, CT, UNISYS, Motorola, Apple, etc. (though they and others DO buy and use my software products). As a final disclaimer, I do own 25 shares of AT&T stock (which I bought back in 1965 or so when I worked for GTE's Electronic Defense Labs :-) Thad Floryan [ thad@btr.com (OR) {decwrl, mips, fernwood}!btr!thad ]