Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!rutgers!im4u!ut-sally!utah-cs!utah-gr!uplherc!nrc-ut!caeco!murf From: murf@caeco.UUCP (Steve Murphy) Newsgroups: comp.dcom.modems,news.sysadmin Subject: Fast (12KBaud) UUCP 'g' transfer rates over Voice-Grade Lines Message-ID: <192@caeco.UUCP> Date: Wed, 12-Aug-87 18:04:34 EDT Article-I.D.: caeco.192 Posted: Wed Aug 12 18:04:34 1987 Date-Received: Sat, 15-Aug-87 14:21:37 EDT Organization: CAECO, INC., Orem, UT 84058 Lines: 131 Keywords: Telebit, TrailBlazer, Modems, UUCP, 'g' Protocol, Mimicry Xref: mnetor comp.dcom.modems:781 news.sysadmin:326 Ultra-fast 'g' Protocol UUCP File Transfer Telebit 'TrailBlazer' Modems--- I would like to report personal experience using Telebit's new UUCP transfer mode while in the 'FAST' mode. Using a vanilla Sun 3/160, with generic uucp provided by Sun Microsystems, I have recorded an average throughput of about 12K baud. To some this may not seem duly impressive, except for the following: A. The Sun 3/160 (and all the sun 2's and the 3/110's also) cannot hardware handshake AT ALL. They say they do, but in one direction only, usually so the external device can shut up the CPU, but not vice-versa. And, as far as I know, this is available as a special kernel fix (zs_asynch.o) for some $$$. But, you have to TURN IT ON. Their uucp package can't/won't do this, so HARDWARE HANDSHAKE is NOT AN OPTION. Now, if I worked for Sun, I'd blush, because this is a serious systems shortfall for a company supposed to be at the fore-front of technology. But they're not unique in this respect, as relatively few companies even know what hardware (RTS/CTS) handshake is. (except maybe Apollo). Even more Ludicrous: Sun OEM's MTI 8/16 port asynch port cards --which have hardware handshake capability; SUN DISABLES THIS FEATURE IN IT'S DRIVER. Sun is very philosophical about this. The only good thing I can say about it is, "At least they're consistant." B. At 19200, SUN DOESN'T SOFTWARE HANDSHAKE EITHER. Apparently, the driver can't send an X-off before the internal buffer overflows. Silo overflows galore. Try it. Turn on TANDEM and CBREAK and send it about 10K of data at 19200. I've talked to people over there, and this problem didn't seem to suprise them. This, by the way, was on an MTI port. I haven't tried it on the Cpu a/b ports yet, but I'm not very optimistic. C. At any rate, until now, with Sun systems, high speed serial devices were not usable. By experimentation, I know is that the Suns cannot handle long blasts at 9600 baud without handshaking. So what does the TrailBlazer do to overcome these serious shortfalls and still operate on the normal asynch ports at 19200 baud? Their modems talk the 'g' protocol. They detect the normal startup sequences for the 'g' protocol (the default protocol currently used by perhaps 95% of the usenet/UUCP community) and go into a 'protocol spoof mode'. Each modem acknowleges locally the packets sent to it. The modem on the sending side gathers packets as fast as it can, sending the acknowledgements itself, and ships the data to the other modem in a 1-way all-out 'blast' mode. The modem on the recieve side hands over the packets just like they were sent, and swallows the acknowledgements. Since the recieve operation is decidedly the slow part, the receiving modem's buffer will invariably fill, at which time, the PEP inter-modem communications tell the sending modem to hold off, and the sending modem holds off. It's buffer will then likewise fill, and it stops the sending system by holding off on it's acknowledgement packets. This simple way of handshaking kills all the problem birds in a system- independent way. It is actually enhanced by the relatively small packet size of the uucp g protocol. Thus I can shove data into my 3/160 at about 12Kbaud and not have to worry one whit about the total lack of handshaking ability. I'm not sure now which is the limiting factor: the ability of the Sun to handle data any faster than that, or noise limitations on the line. I shipped a 1,458,176 byte file in 19.98 minutes, among other tests. This is equivalent to sending data at 4.3 Meg per Hour (roughly). I forsee nothing but neat things as respecting the TrailBlazer. Conversations with Mike Ballard at Telebit (1-408-996-8000), who was in charge of the development of the 'g-spoof' mode, and who is now National Marketing Manager for this product, revealed that there it is definitely not impossible that Usenet sites could obtain a Trailblazer for 1/2 price, about $670. This would be an EXCELLENT price, with many 2400 baud modems ---- --------- costing more than this (and the Trailblazer talks 2400, 1200 and 300 in all their flavors just as well as any I've played with, [and I've played with more than a few, believe me] ). I'm super-excited about this development and I see definite possibilities for revolutionizing the Usenet community. No-one has anything like this out there. The figures I gave were for uncompressed data. What's to keep me from compressing data before I uucp it, and maybe doubling my total thruput thereby? If I can thereby send 8.6 meg of data in 1 hour over normal phone lines, after decompression, who's going to complain about it? Only the phone company, for the reduction of my bills. PARTICULARS: I've tested it locally between a sun 3/160 and a sun 3/110, and obtained these results: small files send at 13Kbaud, rec. at 11Kbaud, ave=12Kbaud. Both sides used /dev/cua (ttya), and not the MTI ports. When the MTI ports were used (same machine - two phone lines and two MTI ports) thruput at 19200 was only 5Kbaud, and at 9600, 6Kbaud. Perhaps differences here are attributable to handshake issues, driver issues, who knows. Between California and Utah: A Sun 3/160 in Santa Clara and one just like it here in Salt Lake City. Both have TrailBlazers on the A/B ports. Exactly similar results ( Ave= 12Kbaud (1,200cps)). And I noted that 2400 baud communications between the two sites is fairly noisy and there is plenty of garbage. Connecting FAST, though, is easy, and note the thruput even though the same noisy lines were used as the 2400 baud modems. NOTES: Sun's uucico doesn't know about 19200, and doesn't understand the Trailblazer's return codes. The 19200 problem is fixable by robbing it of 4800 baud capability via an adb -w fix (which Mike Ballard gave me). The return code problem is overcome by using the DIR access methods in L-devices(?) and L.sys. An L.sys entry like this may be used: hostname Any,0 cua 19200 cua "" ATV0E0X0\r 0 ATD14085551212\r 1 "" login: Ugotit etc.... Note that I locked my interface speed at 19200. (why not?) In fact, I override the factory settings thusly: ATs45=255s52=1s53=3s58=0s66=1s111=30s51=5 This allows remote command processing, sets DTR interpretation reasonably, the rs232 interface to standard interpretations, turns off flow control, locks the interface speed, sets up the uucp transfer mode, and sets the interface speed to 19200. Enough for now. If you have questions, etc. Write or call me. --- -- Steve Murphy, CAECO, Inc., 7090 South Union Park Avenue, Suite 200, Midvale, UT 84047 (801)255-8880 !{byuadam,utah-cs,nrc-ut,wicat}!caeco!murf