Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!public!thad From: thad@public.BTR.COM (Thaddeus P. Floryan) Newsgroups: comp.sys.3b1 Subject: Re: more on the HFC saga Message-ID: <2793@public.BTR.COM> Date: 14 May 91 11:49:26 GMT References: <1991May13.010730.4743@fithp> Distribution: na Organization: BTR Public Access UNIX, Mountain View CA Lines: 118 In article <1991May13.010730.4743@fithp> mhw@fithp (Marc Weinstein) writes: To all those who are still interested... We've discovered quite a bit over the last few weeks about Hardware Flow Control on the 3b1. If the below findings are common knowledge to some, such is life. If anything is incorrect, please post a correction! [...] Sigh, no correction needed. Details of purchasing a company 6 weeks ago have kept me away from the net for awhile, so I've a bunch of catching up to do. As an aside, as part of that acquisition and attempting to bring up a Sun 3/60 to SunOS 4.1.1, an SGI IRIS with IRIX 3.whatever, a PS/2-80 with A/IX 1.2.1, etc. I've gained a new appreciation for how GOOD the 3B1/UNIXPC really is and how EASY it is to install and/or upgrade system software on the 3B1; those other systems suck dead bunnies through a straw in that regards in my opinion. (I also saw the post re: 3B1 and Sun 3/60 Ethernet, and since I just acquired and upgraded a Sun 3/60 to SunOS 4.1.1, I'll try out the rcp, et al by taking one of my 3B1 in to the office and "seeing what happens" :-) In any event, my original posting started this thread (ref: 1800 cps output and 75 cps input using HDB at 19200 baud after 6KB or so of uucp'ing; that 75 cps was due to constant "Alarm n" after each subsequent block transferred followed by a 10-second wait thus driving the cps rate down to the floor, lower than even the proverbial whale turds :-). A quick grep on the extant newsgroup files here at BTR shows many others have confirmed those stats. My own tests with extremely sophisticated DLM and other RS-232 test equipment confirm beyond a shadow of a doubt: THE 3B1/UNIXPC CANNOT OPERATE AT 19200 BAUD RELIABLY. I first discovered this in 1987 with 3.51 and re-confirmed this in 1991 with 3.51m; tests were run on ALL of tty000 through tty004, with stock V2 UUCP and the 3B1 HDB UUCP, and xmodem/ymodem/zmodem and "cat" transfers. Recent private conversations with "people who should know" (:-) have elicited the info that HFC on *INPUT* is *NOT* implemented in *ANY* kernel that CT has produced. Many (most?) of CT's systems were 68020-based, and the *NEED* for HFC at 19200 was non-existent as proved by my own tests on two MightyFrames; as an aside, HFC at 38400 on the MightyFrames is also not needed except for worst-case zmodem transfers where, in my tests, I encountered only ONE serial port overrun in over 200MB file transfers during the tests. And, again, from a "person who should know", examination of the kernel source code verifies that INPUT HFC is non-existent; output HFC is compiled-in and works just fine. And as for the one abusive respondent who claims that 19200 baud works just fine and that I was full of it, I wonder what he's smoking? I have read in a private email (cc'd to me) that with a 3-wire (2,3,7) direct 19200 baud serial connection between his (the abusive respondent's) 3B1 and an NS32532-based Minix machine he gets 700-750 cps; yeah, sure, that's a high-quality 19200 baud connection all right; hot damn! :-) And for those who've forgotten, here's the crucial (non-abusive) part of the abusive respondent's posting to comp.sys.3b1 re: my original posting in regards to 3B1 operation at 19200 baud: [...] Funny, my TrailBlazer Plus, still with creaky old 4.00 ROMs, has been running just fine with hardware flow control and an interface locked at 19,200 for several *years* now. Currently traffic levels are near three-quarters of a *gigabyte* per month with nary a trace of data loss. (There may be an occasional HFC hiccup but uucp's g protocol obviously deals with it and even at that the data rates show minimal impact from retries. HDB uucp, BTW, not the stock garbage.) For the record, I happen to have some numbers for Tuesday of last week, an entirely ordinary day for ******** [site name deleted] with respect to uucp. That day a total of 24 megabytes was transferred in and out over the modem in just over 7 hours. Outbound traffic outweighed inbound by about 1.24 to 1 and these numbers include a non-trivial amount a 2400 baud traffic (perhaps even a trace of 1200) along with some PC Pursuit in addition to Telebit (PEP) links. Despite all that when one accounts for g-protocol packet overhead the *average* rate is over 1,000 bytes per second. [...] Using my calculator, 24MB during 7 hours equates to 952 cps, which is about what I get with my T2500 locked at 9600 baud on the 3B1 for a mixture of email and large uucp file transfers. Even considering the 2400 and 1200 baud connects, that is NOWHERE'S near the 1850+ cps over the modem (even faster using direct hard-wired connections) I do get using systems that CAN and DO support 19200 baud correctly (e.g. my Amigas (which are 68020-based) or the CT MightyFrames (also 68020)). A properly functioning 19200 baud connection is capable of "almost" 7MB per hour (6.9MB actually) which, for 24MB, should have required only 3-1/2 hours at most, half the 7 hours (or twice the speed) as stated in the posting extract included above. Twice as long is the same as half the speed. Hmmm, half of 19200 is 9600, and with 10 bits per character is 960 cps. Double hmmm. Phooie! If you believe that 750 cps (or even 952 or 1000 cps) is a correctly functioning 19200 baud connection, I have some ocean/beach-front property in Arizona I'll be happy to sell you, or you can buy my option on the Brooklyn Bridge for $1,000,000 in small, unmarked bills! :-) The 700-750 cps data rate is about the maximum my own VAX-11/780 systems can pump out at 19200 with NO other load on the system. If one is going to test 19200 baud operation, one damn well better be using systems that are CAPABLE of 19200 baud operation; the 3B1/UNIXPC is NOT. As for testing, as posted previously, I do have and use the proper test systems since I sell commercial modem-interface products of my own design and manufacture to phone companies, the US Govt, and others. This is the real world, not a chapter from "Peter Pan"; closing one's eyes and wishing real, *REAL* hard, is *NOT* going to make one's dreams come true. As much as I like the 3B1 (I have a LOT of them! :-), it simply does NOT support 19200 baud in a consistently reliable manner on the 3B1. Sheesh, haven't YOU ever wondered WHY "19200" isn't in the 3B1's serial port baud UA setup menu? Thad Floryan [ thad@btr.com (OR) {decwrl, mips, fernwood}!btr!thad ]