Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!apple!netcomsv!gandrews From: gandrews@netcom.COM (Greg Andrews) Newsgroups: comp.sys.3b1 Subject: Re: more on the HFC saga Summary: Can't use TrailBlazers for HFC benchmarking Message-ID: <1991May15.002922.20778@netcom.COM> Date: 15 May 91 00:29:22 GMT References: <1991May13.010730.4743@fithp> <2793@public.BTR.COM> Sender: netnews@netcom.COM (USENET Administration) Distribution: na Organization: Netcom - Online Communication Services UNIX System {408 241-9760 guest} Lines: 58 In article <2793@public.BTR.COM> thad@public.BTR.COM (Thaddeus P. Floryan) writes: > [a whole lotta stuff but here's just a bit of it] > >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.) > Yeah, but I've already pointed out to him that saying "my HFC works with UUCP transfers over a TrailBlazer PEP connection" doesn't prove anything. Telebit modems in uucp spoofing mode won't feed packets to the receiving computer faster than it can accept them. That is, it feeds uucp packets to the computer, then waits for the acks before it sends more. The modem negotiates "normal" size packets and windows (64 byte packets, window size of 3) so the largest amount of data it could pour into the computer isn't very large. The modems flow control each other, and the sender's modem can flow control the sender by witholding acks. In other words, the modems arrange things so it's almost impossible for them to overrun anyone's buffers - whether hardware flow control is enabled or not. The modems provide end-to-end flow control through the *uucp protocol* rather than hardware handshaking. It matters not whether hardware flow control is perfect or broken - the modems don't use it when they're spoofing uucp. To summarize, using the results of PEP/uucp sessions will not tell you how well your hardware flow control works. It only tells you how well the uucp spoofing works. > >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. > My back-of-the-envelope calculations came up with 1,000 cps, but it's still the same conclusion - 24 megabytes in 7 hours is much closer to 9600 bps than 19200... > >Thad Floryan [ thad@btr.com (OR) {decwrl, mips, fernwood}!btr!thad ] > -- .------------------------------------------------------------------------. | Greg Andrews | UUCP: {apple,amdahl,claris}!netcom!gandrews | | | Internet: gandrews@netcom.COM | `------------------------------------------------------------------------'