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!mhwfloyd@ims.alaska.edu (Floyd Davidson) (05/19/91)
In article <1991May18.175656.2858@fithp> mhw@fithp (Marc Weinstein) writes: >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... > > >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. Maybe it does, maybe not. but... > 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 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. (Actually the receiving modem will not even be asserting HFC in the example given.) It seems there is a basic misunderstanding here about how data flow control works. I'm sending Marc a more detailed explanation by email rather than post it. I would suggest that anyone else who wants further information on this should bring it up in the comp.dcom.modems group. Floyd -- Floyd L. Davidson | Alascom, Inc. pays me, |UA Fairbanks Institute of Marine floyd@ims.alaska.edu| but not for opinions. |Science suffers me as a guest.
res@colnet.uucp (Rob Stampfli) (05/19/91)
Just to add another twist to the already sordid tale of woe regarding hardware flow control on the Unix-PC.... I have a V.32 modem connected to my PC, and it seems to work just fine sans HFC with uucp g. Well, almost -- it does tend to resync a lot when I am getting news, but I have always attributed that to the "known" problems of talking to a TB 2500 in V.32 mode. The other day, I connected a terminal to another spare port. Lo and behold, I discovered that any activity that resulted in significant output to the terminal completely hosed the uucp transfer in progress on the modem at the time. I tried the following with no noted improvement: 1. Swapped the modem and terminal between tty000, tty001, and tty002. 2. Changed the physical location of the serial card. 3. Exchanged serial cards. 4. Exchanged the Unix-PC with another different machine. 5. Changed the baud rate of the terminal from 9600 down thru 300. 6. Changed the rs232 cable to the modem. The only thing that may have affected the problem was applying the io 4/60 -> 1/60 sec serial i/o patch. Applying this patch *seemed* to make the problem harder to reproduce. Things I have not tried are: 1. Reloading and testing with 3.5. (I am on 3.51m.) 2. Swapping modems. Note that I can spool up two outgoing uucp transfers -- one via the modem, and one via a hardwire link -- without problems. The only time this problem manifests itself is when the modem is receiving data, and another port is sending data. Now, I wonder. Could something in that part of the io subsystem that is responsible for processing the outbound queue be locking out interrupts long enough for the incoming stream from the modem to overrun? If this is true, then this problem and the HFC problem might be related in that they are being caused by dropped characters due to either the hardware not being robust enough to accomodate 9600 baud, or a software problem in the io subsystem. Perhaps the HFC problem has nothing to do with HFC. And, maybe the problem with uucp g I notice occasionally is the incoming packets being corrupted by the ACKs. I have nothing substantive to prove this. I'm just casting about looking for answers. And it is too late to continue, so I am going to bed. -- Rob Stampfli, 614-864-9377, res@kd8wk.uucp (osu-cis!kd8wk!res), kd8wk@n8jyv.oh
thad@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 ]
floyd@ims.alaska.edu (Floyd Davidson) (05/19/91)
In article <2825@public.BTR.COM> thad@public.BTR.COM (Thaddeus P. Floryan) writes: >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). The original article, quotes from which you did not include, was concerning modem use. And the point that I was making was that there is a misunderstaning about data transfers using modems and its relationship to hardware flow control. One of the misunderstood things is that they are not related and are two separate issues. >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..." The sending modem is NOT going to detect anything related to HFC between the receiving port and the receiving modem. If you are hardwired between ports it will, but the discussion was about modems, not hard links. (However, it still won't make any difference, see below...) > 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. No not magic. 2400 bps and modem buffering. There is no signal from your office modem to the 3b1 to slow down. The modems are transfering data at 2400 bps, not 9600. As long as your office computer can handle 2400 bps it is going to work. The T2500 asserts HFC to the 3B1 when its transmit buffer is full. That has nothing to do with the computer or the modem on the other end. It is totally between the T2500 and the 3b1 and is intended to keep the T2500 analog side transfering data as fast as it can, which in your case is restricted to 2400 bps. It works very well too. (And does because the T2500 is capable of buffering data at the max rate that the 3b1 can send it at.) If the data rate between the modems was faster than the receiving end could handle, then the receiving end would drop data, but at 2400 bps that is unlikely. So your experience is interesting, but it does not in any way prove that the sending modem gets any kind of HFC signal from the receiving modem. It doesn't. >The audience in comp.dcom.modems probably doesn't even know (or care) what a >3B1 and its problems are, so why burden them? They probably don't even know what a 3B1 is, but they do understand flow control and modems. Try 'em. And be sure to ask how a Tbit modem sends HFC signals to the distant modem. Someone from Telebit will tell you it doesn't. >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 [ 15 lines of chest thumping about the 3b1 removed] >Point being: the 3B1 doesn't have enough "horsepower" to handle thousands of >interrupts per second. That *is* the point. > [ about 50 lines 3b1 advertisements removed (geeze Thad, we know it is a nice machine, why do think we own them. Are you selling yours?) ] > Note that handling interrupts and HFC are two different things. I have no idea if the 3b1 really is not asserting HFC on incoming data buffer overflow, it doesn't make much difference. It can't handle data at 19.2 kbps because it can't handle interrupts that fast, HFC or no. The 3b1 can't buffer data that fast, so how is it going to make HFC work? (Given the current serial port hardware which requires one interrupt per character. If someone wants to design a buffered serial port card then we might worry about "incoming" HFC a little more.) Even at 2400 bps between modems one could still have a problem if the modem to 3b1 rate is 19.2 kbps if the modem buffers receive data and dumps it to the 3b1 at a full 19.2 kbps rate. Think about it. Floyd -- Floyd L. Davidson | Alascom, Inc. pays me, |UA Fairbanks Institute of Marine floyd@ims.alaska.edu| but not for opinions. |Science suffers me as a guest.
murphyn@motcid.UUCP (Neal P. Murphy) (05/22/91)
res@colnet.uucp (Rob Stampfli) writes: >Just to add another twist to the already sordid tale of woe regarding >hardware flow control on the Unix-PC.... >I have a V.32 modem connected to my PC, and it seems to work just fine sans >HFC with uucp g. Well, almost -- it does tend to resync a lot when I am >getting news, but I have always attributed that to the "known" problems of >talking to a TB 2500 in V.32 mode. The other day, I connected a terminal to >another spare port. Lo and behold, I discovered that any activity that >resulted in significant output to the terminal completely hosed the uucp >transfer in progress on the modem at the time. I tried the following with Just another thought: has anyone ever tried to set the nice(2) value of the uucico process to, say, 10, where things usually run at 20? That might give uucico more CPU time, give other processes less time, and cause fewer buffer over-runs. NPN
ahh@glyph.kingston.ny.us (Andy Heffernan) (05/23/91)
With all these questions about hardware-flow-control, I'm tempted
to add a question to the FAQ-list like:
----
50) What the hell's the deal with hardware-flow-control (HFC) ?
I don't know.
----
If there's ever a definitive answer, I'll be listening.
By the way, I remember hearing about someone porting VMS to the 3b1...
is there any update on how that's going?
--
-------------------------------------------------------------------------
Andy Heffernan $BJ8;z(J uunet!glyph!ahh