Xref: utzoo comp.dcom.modems:3983 comp.mail.uucp:3267 Path: utzoo!attcan!telly!eci386!clewis From: clewis@eci386.uucp (Chris Lewis) Newsgroups: comp.dcom.modems,comp.mail.uucp Subject: Re: Telebits and uucp g-protocol Keywords: Telebit Trailblazers, g-protocol, uucp Message-ID: <1989Jun12.185746.7217@eci386.uucp> Date: 12 Jun 89 18:57:46 GMT References: <335@nixtor.UUCP> <10391@smoke.BRL.MIL> Reply-To: clewis@eci386.UUCP (Chris Lewis) Organization: R. H. Lathwell Associates: Elegant Communications, Inc. Lines: 115 In article <10391@smoke.BRL.MIL> bogstad@brl.arpa (William Bogstad (JHU|mike) ) writes: >In article <335@nixtor.UUCP> davidm@nixtor.UUCP (David Macklem) writes: >>I understand that the Telebit TB+ modems can do the uucp g-protocol >>between themselves. This ability sure is nice but it doesn't really >>offload the CPU that much, does it? ... > I believe that this is correct. My understanding is slightly different - the TB+ modems spoof G-protocol to their *hosts*, not to each other. TB+ <-> TB+ communications is still in PEP or whatever. It's not intended to off-load the CPU, it's intended to maximize throughput. G protocol requires acknowledges of each packet within a certain number of packets (usually 3, but there are some with 7). AKA windowing. When you have modems that aren't, strictly speaking, full duplex, or when you have *long* end-to-end delays (bouncing off satellites), it may take a significantly longer time to get the ack back from a packet than it does to send 3 (or 7) packets. When you have 3 (or 7) packets transmitted without having received their associated acks, you have to stop transmitting packets and wait for the acks from the packets you sent. G-protocol does work over X.25 with PADS. The main difficulty (not counting cost and "how it god's name do I configure the PAD to allow this?!" for the moment) is the end-to-end-to-end delays. At 9600 baud, you can send 3 64 byte packets in 200-ish ms. Then you add the 50 ms. timeout to send the ack packet back, plus X.25 gateway delays, plus network turnarounds, plus satellite links etc. Yuck. When we tested 9600 X.25/PAD links with G, we got 600 baud effective thruput. And that was simply bouncing it off our local X.25 connection 5 miles away. Cross country was more like 60 baud. The idea of the TB+ is to allow the transmitting host to emit large amounts of data which are sent in bulk (no line turnarounds etc.) - the transmitting host is happy because it's getting its acks back from the TB+ that it is directly connected to. The upshot of it is that even with very slow end-to-end-to-end acks, it doesn't slow down the transmissions of a file. On the other hand, the TB+ *has* to synchronize both hosts during negotiation about whether a file actually got where it went, and requests to send things. (This is why people with TB's complain about small files, and have been talking of some sort of batched UUCP transmit) Otherwise, one UUCP may thought that the file got there, but the line went down and the other didn't get all of it. Hence, inter-file transactions may be somewhat expensive. But, data file transfers themselves can go close to the effective transfer rate regardless of what the end-to-end-to-end response time is. >>My second question is related to the first. Since the Telebits can do >>the error-checking and correction themselves why don't all uucico's >>communicating using modems that agree on some protocol use the >>f-protocol? This protocol, as far as I can tell, is used over X.25 >>lines and the master just sends the whole file and then waits for an >>acknowledgement from the slave. > > Well, I don't think that the f-protocol is in all versions >of UUCP and this would reduce the UNIX market. That's fur shore. > I'm not familiar with >the f-protocol, but I would guess that it sends a single checksum for >the entire file. Right. Plus conversion to 7-bit datapath. > Although the modem to modem link becomes error free >you have to worry about the serial line running between the host ports >and the modems. If an error occurred here, the entire file would have >to be retransmitted. On one link I set up (X.25 pads), this happened quite frequently with huge files until we smartened up and split them into smaller pieces. Further, there is no need for a TB+ to spoof "f" protocol. Since "f" protocol doesn't require acks on a per-packet basis, the sending UUCP can simply spew the whole file, only needing X-ON/X-OFF (or DTR or whatever) handshaking with its TB+, BUT, then it *has* to wait for file synchronization just like G-protocol does. Thus, you *can* run f-protocol over the TB+, obtaining close to the f-protocol speed limit. BUT, using "f" over TB+'s is a waste - because if the file transfer fails for any reason, you don't get to find out about it until the whole file is transfered (with "g", the TB+ does have a chance to tell you that the receiver ran out of disk...). And finally, "f" protocol is 7-bit, whereas "g" protocol is 8. On text files, "f" protocol may be slightly better than "g" (because there are no packet headers), but on binaries, the "f" protocol expands non-printable characters to 2 or 3 characters. So, binary files can get considerably larger. To sum up the TB+ situation vis-a-vis UUCP protocols: - "g" and "f" will be effectively the same speed on small files because the inter-file transactions (the same in both) dominate the time. - "g" is a big win on big binary files. (eg: compressed news feeds) - "f" is a small win on big ASCII files. - "g" is frequently a big win on big files and buggy modem-to-host connections, or any other reason that can cause a transfer to fail once it's started without completely destroying the link. - "g" is always available on both ends. "f" is rather rare. "f" protocol is ideal when you have a "dumb" but error free link that doesn't understand any of your protocols directly. Eg: X.25 PADS. Or direct lines if you have working bidirectional flow control and both ends are guaranteed never drop anything. But god help you if one of your hosts drops characters. But if your link is "smart" and knows about some of your protocols, (eg: TB+ with G-spoofing), a packet-oriented one is better. -- Chris Lewis, R.H. Lathwell & Associates: Elegant Communications Inc. UUCP: {uunet!mnetor, utcsri!utzoo}!lsuc!eci386!clewis Phone: (416)-595-5425