davidm@nixtor.UUCP (David Macklem) (06/08/89)
I have a number of questions about Telebits and the g-protocol spoofing that they do. Hopefully someone out there will explain. 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? The sending and receiving machines still need to packetize/unpacketize and checksum the data, etc., ie. everything that the modems do, assuming that the uucico's are communicating via the g-protocol. (I don't profess to know the g-protocol so if my ignorance of it is obvious, forgive me, but I don't think that this makes my point invalid.) I realize that the sending and receiving machines won't need to do any retransmission of packets (the modems will handle this) but is this not also the case with any protocol that the TB modems may support? If so, why are there so many (about 5?) protocols supported by these modems? Why not just one? 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. Since the modems handle the error checking and correction, the receiving machine won't see any errors. This would offload the machine a bit more than the current method. Any takers? Thanks in advance. -- David Macklem Nixdorf Computer Canada, Limited davidm@nixtor uunet!jtsv16!geac!nixtor!davidm
bogstad@smoke.BRL.MIL (William Bogstad ) (06/10/89)
In article <335@nixtor.UUCP> davidm@nixtor.UUCP (David Macklem) writes: >I have a number of questions about Telebits and the g-protocol >spoofing that they do. Hopefully someone out there will explain. > >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. >... If so, >why are there so many (about 5?) protocols supported by these modems? >Why not just one? I assume because they are trying to sell to different markets. Unix machines normally talk to each other using uucp, PCs xmodem or kermit, SLIP is used for IP links, etc. Nobody has to rewrite any software to gain most of the advantage of having a Telebit. >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. I'm not familiar with the f-protocol, but I would guess that it sends a single checksum for the entire file. 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. Also some systems probably can't handle a full speed 9.6K or 19.2K serial connection for the time it would take to send an entire file. You can't assume the same size machine on both ends of the link or even that receive and transmit capabilities for a single machine type are balanced. For terminal connections, the transmit side almost always ends up with a higher usage and might have been designed with that assumption. The receiver might lose characters again resulting in retransmit. Actually, I would guess it was the marketing consideration rather then any other which drove the initial decision to do the "g" rather then "f" protocol. The same consideration probably is why the "f" protocol hasn't been developed yet. SLIP gains a whole new market. Bill Bogstad bogstad@crabcake.cs.jhu.edu
csg@pyramid.pyramid.com (Carl S. Gutekunst) (06/12/89)
>>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? > >Well, I don't think that the f-protocol is in all versions of UUCP and this >would reduce the UNIX market.... Also some systems probably can't handle a >full speed 9.6K or 19.2K serial connection for the time it would take to >send an entire file. 'f' is a streaming protocol, with no ack packets except at the end of the file. This makes it perfect for running with the TrailBlazer; you don't need any protocol in the modem at all. In fact, we were using 'f' over the Trail- Blazer years before the 'g' spoof existed. And the 'f' protocol allows the use of XON/XOFF handshaking, so the flow control problems Bill aluded to do not exist. But there were other problems. XON/XOFF didn't work very well in the version 2.0 TrailBlazer ROMs, so hardware RTS/CTS handshake had to be used, which is something very few UNIX computer makers support. And yes, many boxes cannot take 9600 bps input streamed at them continuously without getting input over- run. (This is very different from flow control -- it indicates poor design of the serial I/O controller or interrupt system.) The biggest problem with 'f' is that it assumes the line is not 8-bit trans- parent, and does quoting of all control and 8-bit characters. This increases the size of text files by about 5%, and compressed files by over 40%. I did some exhaustive performance studies of 'f' versus 'g' protocols using Pyramid 98xe, Sun 3, ISI Optimum V, and Sequent Balance. There were some in- teresting 'knees' in the curves I have to go back and look at; for example my Pyramid 98xe was slower over TrailBlazer links than my Sun 3, but much faster on a hardwired link. The bottom line, though, was that while the performance gain of the 'f' protocol was measurable, it wasn't worth it. I had too much problems with input overrun. And the performance gain wasn't usually enough to offset the 'f' character quoting overhead. <csg>
grr@cbmvax.UUCP (George Robbins) (06/12/89)
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? That's not really the point - what the spoofing addresses is the problem of acknowledgment delays when the modem is operating in a packetizing mode and doesn't understand the packet boundries of the higher level protocol. A protocol better tuned to the characteristics of the modems would obviate the need for spoofing... > If so, why are there so many (about 5?) protocols supported by these modems? > Why not just one? To each their own. Each market has a strong preference for a particular protocol. Not to address the major ones would give the market away to the competition. > ...why don't all uucico's > communicating using modems that agree on some protocol use the > f-protocol? Because we live in a world where the marjority of systems are binary distributions which support only the 'g' protocol or perhaps one of two mutually incompatible streaming protocols. Worse, bugs in the common implementation of the 'g' protocol and system "raw" buffer size limits tend to prevent excercising the options for larger packet sizes that could improve 'g' thruput. The situation is only gradually evolving as more vendors ship HDB or BSD 4.3'ish versions of uucp. -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@uunet.uu.net Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
rjn@hpfcdc.HP.COM (Bob Niland) (06/12/89)
re "The biggest problem with 'f' is that it assumes the line is not 8-bit
trans- parent, and does quoting of all control and 8-bit characters.
This increases the size of text files by about 5%, and compressed files
by over 40%."
Yes, but if the modem has on-board data-compression, it compresses the
quoting back out before transmission.
I'm using a pair of USR HST modems between work and home. Both computers
address the modems at 19200 bps, and I get phenomenal throughput using UUCP
'f', even on pre-compressed binary files.
Regards, Hewlett-Packard
Bob Niland rjn%hpfcrjn@hplabs.HP.COM 3404 East Harmony Road
[hplabs|hpu...!hpfcse]!rjn Ft Collins CO 80525-9599clewis@eci386.uucp (Chris Lewis) (06/13/89)
In article <10391@smoke.BRL.MIL> bogstad@brl.arpa (William Bogstad (JHU|mike) <bogstad>) 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
datri@concave.uucp (Anthony A. Datri) (06/13/89)
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? What happens is that the TB will ACK a uucp packet as soon as its host sends it, instead of waiting for the remote host to ACK it. You save on latency this way.
csg@pyramid.pyramid.com (Carl S. Gutekunst) (06/14/89)
In article <4980002@hpfcdc.HP.COM> rjn@hpfcdc.HP.COM (Bob Niland) writes: >>The biggest problem with 'f' is that it assumes the line is not 8-bit trans- >>parent, and does quoting of all control and 8-bit characters. This increases >>the size of text files by about 5%, and compressed files by over 40%. > >Yes, but if the modem has on-board data-compression, it compresses the >quoting back out before transmission. I would *guess* that an even bigger win -- albeit more work -- is the encode filter used by netnews. This also reduces the number of interrupts the CPU has to service, which was supposed to be one of the gains using 'f' protocol. Then go through your MNP Level 5 modem. <csg>
allbery@ncoast.ORG (Brandon S. Allbery) (06/14/89)
As quoted from <335@nixtor.UUCP> by davidm@nixtor.UUCP (David Macklem): +--------------- | I have a number of questions about Telebits and the g-protocol | spoofing that they do. Hopefully someone out there will explain. | | 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? The sending and receiving machines | still need to packetize/unpacketize and checksum the data, etc., ie. +--------------- Telebits do *not* use 'g' protocol between themselves; they use PEP. What happens in the protocol recognition mode is that UUCP (or Xmodem or Kermit) sends its packets to the Telebit as usual. The Telebit then *strips* the protocol and sends the packets via its usual PEP encoding. The remote modem then re-assembles the packets into valid UUCP (Xmodem, Kermit) packets for the remote computer. Why? Because layering two packet protocols on top of each other guarantees throughput problems. Telebit, by special-casing common protocols, avoids this transparently. ++Brandon -- Brandon S. Allbery, moderator of comp.sources.misc allbery@ncoast.org uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu Send comp.sources.misc submissions to comp-sources-misc@<backbone> NCoast Public Access UN*X - (216) 781-6201, 300/1200/2400 baud, login: makeuser
igb@Fulcrum.BT.CO.UK (Ian G Batten) (06/14/89)
In article <1989Jun12.185746.7217@eci386.uucp> clewis@eci386.UUCP (Chris Lewis) writes: > >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. This may be a difference between US and UK, but I find that UUCP over X25 is basically OK. I have a machine with a TB+, a pair of v22bis modems and a 2400 bps X25 line. I see 245 cps with the 'e' protocol from HoneyDanber (interestingly, 'x' doesn't seem to work for me!) and perhaps about 140 for 'g' protocol. This is for a newsfeed over about 100 miles. [E protocol is pretty similar to 'f', but doesn't reduce the datawidth. I've never tried shipping binary data over X25 with it. As it gets us full bandwidth of the line for our news feed, we aren't going to disturb it.] ian -- Ian G Batten, BT Fulcrum - igb@fulcrum.bt.co.uk - ...!uunet!ukc!fulcrum!igb
paul@csnz.co.nz (Paul Gillingwater) (06/15/89)
In article <335@nixtor.UUCP> davidm@nixtor.UUCP (David Macklem) writes: >I have a number of questions about Telebits and the g-protocol >spoofing that they do. Hopefully someone out there will explain. Oh, I couldn't resist answering this one. Sorry my reply is a bit late: comes of living 10,000 miles away I guess... >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? The key word here is "spoof". Two matched TB's running at 19,200 on their DTE interfaces will "pretend" to do uucp - but in reality they are using their own protocol, called PEP, which is a packetised error-correcting ARQ type protocol. The TB's will feed all the right answers back to uucico so that it thinks it's talking uucp-g with another uucico -- but it's not. >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? The danger of assuming that you are using an error-free link is that the end-points are not secure. By that, I mean that you can lose characters at each end due to things like missed interrupts, overrun errors between the modem and the computer due to poor handshaking, etc. That's why it's better to allow the protocol to check. >Any takers? Yep! >David Macklem Nixdorf Computer Canada, Limited From a fellow colonialist... -- Paul Gillingwater, Computer Sciences of New Zealand Limited Bang: ..!uunet!dsiramd!csnz!paul Domain: paul@csnz.co.nz Call Magic Tower BBS V21/23/22/22bis 24 hrs +0064 4 767 326
caf@omen.UUCP (Chuck Forsberg WA7KGX) (06/15/89)
In article <13751@ncoast.ORG> allbery@ncoast.ORG (Brandon S. Allbery) writes:
:Why? Because layering two packet protocols on top of each other guarantees
:throughput problems. Telebit, by special-casing common protocols, avoids
:this transparently.
Almost, but not quite, transparently. Enabling protocol spoofing for a
protocol typically interferes with the correct operation of other
protocols, so the spoofing is not quite "transparent".
What's more, the protocol spoofing wins only if the spoofing completely
understands the protocol in use. My TrailBlazers don't understand Sliding
Window or Long Packet Kermit. They Don't understand some forms of XMODEM,
and their YMODEM spoofing doesn't work at all with real YMODEM.
Finally, the throughput with Kermit, UUCP, or XMODEM spoofing does not
equal the throughput attained with ZMODEM without spoofing.
Chuck Forsberg WA7KGX ...!tektronix!reed!omen!caf
Author of YMODEM, ZMODEM, Professional-YAM, ZCOMM, and DSZ
Omen Technology Inc "The High Reliability Software"
17505-V NW Sauvie IS RD Portland OR 97231 503-621-3406
TeleGodzilla:621-3746 FAX:621-3735 CIS:70007,2304 Genie:CAFvjs@rhyolite.wpd.sgi.com (Vernon Schryver) (06/17/89)
In article <783@omen.UUCP>, caf@omen.UUCP (Chuck Forsberg WA7KGX) writes: > ... > Almost, but not quite, transparently. Enabling protocol spoofing for a > protocol typically interferes with the correct operation of other > protocols, so the spoofing is not quite "transparent". > ... > Chuck Forsberg WA7KGX ...!tektronix!reed!omen!caf > Author of YMODEM, ZMODEM, Professional-YAM, ZCOMM, and DSZ > Omen Technology Inc "The High Reliability Software" > 17505-V NW Sauvie IS RD Portland OR 97231 503-621-3406 > TeleGodzilla:621-3746 FAX:621-3735 CIS:70007,2304 Genie:CAF Quite so. I have a Compressed-SL/TCP/IP-with-cksums protocol (uhh, kludge) which distills TCP/IP to <framing><user-data><1-byte-of-TCP><cksum><framing>. With UUCP enabled, a pair of TB+'s on a test wire would continually retrain and loose the connection, and never pass any data TCP/IP data. I presume they thought the binary compress-SLIP swill looked like UUCP handshakes, and went out to lunch when it did not make sense. I kind of wish there had been a warning in the manuals. It took me too much time to figure out that there was nothing wrong with the modems or the wire. Of course, if you're doing UUCP-g, TB+'s are currently unbeatable. Vernon Schryver Silicon Graphics vjs@sgi.com
honey@mailrus.cc.umich.edu (peter honeyman) (06/20/89)
brandon, the tb encapsulates g in pep, it doesn't strip and recreate the g frames. the sender's modem validates the g frame, but the receiver's modem doesn't bother (since pep is reliable). peter
clewis@eci386.uucp (Chris Lewis) (06/22/89)
In article <193@cat.Fulcrum.BT.CO.UK> igb@fulcrum.bt.co.uk (Ian G Batten) writes: >In article <1989Jun12.185746.7217@eci386.uucp> clewis@eci386.UUCP (Chris Lewis) writes: >>G-protocol does work over X.25 with PADS. >>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. >This may be a difference between US and UK, but I find that UUCP over >X25 is basically OK. I have a machine with a TB+, a pair of v22bis >modems and a 2400 bps X25 line. I see 245 cps with the 'e' protocol >from HoneyDanber (interestingly, 'x' doesn't seem to work for me!) and >perhaps about 140 for 'g' protocol. This is for a newsfeed over about >100 miles. I don't think that our numbers necessarily disagree. "Cross-country" in this case meant 3000+ miles and (well, maybe that should have been "cross-continent") at least one international gateway (Bell Canada "DATAPAC" => US "Tymnet"). And at least one 4800 baud hop. And lots of other traffic sharing the lines... 60 baud "g" protocol, but with "f" protocol, our effective thruput ranged from about 3000 (full binary data) to 4300 (which, after all, was near the max rated speed of one of the trunks). With "g", you can send your three packet window not too badly, but remember, you have to wait for the "transmit timeout" (minimum 50ms on our pad) before the last bit of it actually gets sent. [Well, depends on X.25 packet size etc. etc. etc.] As well, you also have to wait for the transmit timeout before the acks get sent back. So, think of basic X.25 "g" speed as: "time to send three packets at rated link speed" *plus* two "transmit timeouts". As your speeds get higher and higher, the transmit timeouts tend to dominate, and your speed will reach a plateau. If you can increase your window size, that helps a lot. Not having acks required until the end of the file is transmitted (as in "f" and "e") is *much* better. The above discussion is over-simplified and doesn't include gateways of course... >[E protocol is pretty similar to 'f', but doesn't reduce the datawidth. >I've never tried shipping binary data over X25 with it. As it gets us >full bandwidth of the line for our news feed, we aren't going to disturb >it.] You mean you aren't using compressed batching?! e is very dangerous unless you've carefully set up your PAD - a single binary character in the data could do all sorts of nasty things (at best, cause it to be impossible to send a file because the PAD strips the character so checksums will never match, to such things as resetting the pad, changing parameters etc.). If you've not spent the time making absolutely certain that the PADs are set up correctly, you're best off using "f" protocol. [I had given Rick Adams a X.25 PAD dialer module that didn't quite make it into BSD 4.3, which has PAD initialization built in. See the comp.sources.unix archives if you want it... I don't have access to it no more.] -- Chris Lewis, R.H. Lathwell & Associates: Elegant Communications Inc. UUCP: {uunet!mnetor, utcsri!utzoo}!lsuc!eci386!clewis Phone: (416)-595-5425
rick@pcrat.UUCP (Rick Richardson) (06/24/89)
In article <1989Jun22.154318.25599@eci386.uucp> clewis@eci386.UUCP (Chris Lewis) writes: > >With "g", you can send your three packet window not too badly, but >remember, you have to wait for the "transmit timeout" (minimum 50ms >on our pad) before the last bit of it actually gets sent. >[Well, depends on X.25 packet size etc. etc. etc.] > >As well, you also have to wait for the transmit timeout before the acks get >sent back. So, think of basic X.25 "g" speed as: "time to send >three packets at rated link speed" *plus* two "transmit timeouts". If you are lucky (?) enough to have ISDN capable lines, you can use an AT&T 750x series voice/data phone to transmit X.25. The PAD in these phones has (in addition to the usual 50ms idle timer), a feature we called "minimum timer". This option automatically determines whether or not file transfer or interactive typing is going on, and forwards packets within a couple RS232 character times, while at the same time it avoids sending wasteful short packets. I.E. file transfer packets fill up and get forwarded immediately, the partial packet at the end of a file transfer block burst gets forwarded within a couple RS-232 character times, and single keystrokes go out as one character packets. Of course, since the ACKs also get delayed, it is best to have this scheme running on both ends of the connection. These days, thats pretty unlikely, since there are only a few areas which are served by ISDN. Sigh. The scheme works wonderfully for all kinds of protocols, not just UUCP g. It was, in fact, developed to solve the abysmal performance of X and Y -MODEM protocols when layered on top of X.25, as well as the noticeable echoplexing delay when the conventional 50 msec idle timer is used. And the best part is, you just set the mode once when you install the phone and forget it. No hacking PAD parameters. -- Rick Richardson | JetRoff "di"-troff to LaserJet Postprocessor|uunet!pcrat!dry2 PC Research,Inc.| Mail: uunet!pcrat!jetroff; For anon uucp do:|for Dhrystone 2 uunet!pcrat!rick| uucp jetroff!~jetuucp/file_list ~nuucp/. |submission forms. jetroff Wk2200-0300,Sa,Su ACU {2400,PEP} 12013898963 "" \d\r\d ogin: jetuucp
igb@Fulcrum.BT.CO.UK (Ian G Batten) (06/26/89)
In article <1989Jun22.154318.25599@eci386.uucp> clewis@eci386.UUCP (Chris Lewis) writes: >You mean you aren't using compressed batching?! e is very dangerous >unless you've carefully set up your PAD - a single binary character in >the data could do all sorts of nasty things (at best, cause it to Not using a PAD! PSS modem straight into the back of the machine, X25 in the kernel. It's 8-bit clean: we ship kernels in the raw. (With 'g', admitedly. BuT I think 'e' will work as well.) ian ian -- Ian G Batten, BT Fulcrum - igb@fulcrum.bt.co.uk - ...!uunet!ukc!fulcrum!igb
csg@pyramid.pyramid.com (Carl S. Gutekunst) (06/28/89)
Couple of notes regarding UUCP over X.25. The biggest problem with 'g' protocol for many users isn't the delays (which can be terrible), it's the cost. 'g' protocol typically triples the packet charges on networks like PSS and Telenet that make you pay by the segment. The delays are much more noticable on international links, e.g. between the U.S. and Germany. You can reduce the delays considerably by increasing the X.25 packet window size, oddly enough. Also note that 'g' requires 8-bit transparency, which may not be possible on some PADs, requires funny PAD parameters in any event, and (so Telenet tells me) isn't always guaranteed on some international gateways. You should never never never use 'e' or 't' protocols over X.25. These are raw 8-bit interfaces that do no error checking. Anything goes wrong, and you'll never know about it. Even the simple 8-bit checksum of 'f' is a big improvement. Also, 'e' and 't' have no provision for inband flow control, e.g. XON/XOFF. 'f' allows this. Important only if you are using a PAD. The 'x' protocol is completely useless. It requires a zero-length packet passed end-to-end to mark end-of-file. This is impossible on a PAD, illegal on some networks, and dropped for "efficiency" reasons by some vendor's raw X.25 interfaces. <csg>
ostroff@cboard.UUCP (Boyd Ostroff) (07/22/89)
In article <4980002@hpfcdc.HP.COM> rjn@hpfcdc.HP.COM (Bob Niland) writes: > >I'm using a pair of USR HST modems between work and home. Both computers >address the modems at 19200 bps, and I get phenomenal throughput using UUCP >'f', even on pre-compressed binary files. > Forgive the stupid question :-), but *how* does one coerce uucico to use 'f' or 'e' or 'x' or ANYTHING other than 'g' on a standard dialup line? Is this highly machine/version specific? Do you need to have UUCP source code? I'm running HDB UUCP on an AT&T 3B1, and would like to experiment (having ongoing problems with a UUCP link due to buffering in SUNY's IBX digital phone system). Any suggestions would be appreciated! ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: Boyd Ostroff, Technical Director ::::: System Operator, "The CallBoard" :::: :::: Dept of Theatre, SUNY Oswego :::::: (315) 947-6414 300/1200/2400 baud :::: ::::: ostroff@oswego.Oswego.EDU :::::: rochester!kodak!gizzmo!cboard!ostroff :: :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
jparnas@larouch.UUCP (Jacob Parnas) (07/22/89)
In article <4980002@hpfcdc.HP.COM> rjn@hpfcdc.HP.COM (Bob Niland) writes: >... >I'm using a pair of USR HST modems between work and home. Both computers >address the modems at 19200 bps, and I get phenomenal throughput using UUCP >'f', even on pre-compressed binary files. > >Regards, Hewlett-Packard >Bob Niland rjn%hpfcrjn@hplabs.HP.COM 3404 East Harmony Road > [hplabs|hpu...!hpfcse]!rjn Ft Collins CO 80525-9599 What throughput do you get on compressed and uncompressed data files? ------------------------------------------------------------------------------ | Jacob M. Parnas | DISCLAIMER: The above message is from | | IBM Thomas J. Watson Research Ctr. | me and is not from my employer. IBM | | Arpanet: jparnas@ibm.com | might completely disagree with me. | | Bitnet: jparnas@yktvmx.bitnet \---------------------------------------| | Home: ..!uunet!bywater!acheron!larouch!jparnas | Phone: (914) 945-1635 | ------------------------------------------------------------------------------
ray@ole.UUCP (Ray Berry) (08/02/89)
The current 14.4K HST gets about 1600-1700 bytes/sec when sending com- pressed data. Fallback supposedly occurs in steps of 2400 baud; I haven't verified this.. -- Ray Berry kb7ht uucp: ...ole!ray CIS: 73407,3152 /* rent this space */ Seattle Silicon Corp. 3075 112th Ave NE. Bellevue WA 98004 (206) 828 4422
rjn@hpfcdc.HP.COM (Bob Niland) (08/03/89)
re: >> I'm using a pair of USR HST modems between work and home. Both >> computers address the modems at 19200 bps, and I get phenomenal >> throughput using UUCP 'f', even on pre-compressed binary files. > jparnas@larouch.UUCP (Jacob Parnas) asks... > What throughput do you get on compressed and uncompressed data files? From an old posting, updated this evening... These tests were performed between a 320 (a 16.6 MHz 68020) running HP-UX 5.5 and a 350 (25 MHz 68020) running 6.0. The serial interface was port 0 of a 98642A MUX on both ends. The HSTs were configured as per [my usual recommendations], and 'f' protocol was used. The telephone call was local, but probably involved two exchanges (from a 223- prefix to a 226- prefix). The command used was 'uucp', and the times are from the /usr/spool/uucp/LOGFILE, and include some UUCP session overhead. Test data objects: ASCII - "/etc/newconfig/Update.info/from.2.x" (a 113Kb text file) binary - "/hp-ux", 5.5 (the kernel file, about 800Kb) packed - ASCII.Z, as crunched by compress(1) The results: ASCII - 1618.3 bytes/sec binary - 1101.5 bytes/sec packed - 919.2 bytes/sec (raw), 2476.1 bytes/sec (net) This last result is interesting. The "raw" figure is... ASCII.Z_size/time ... and the "net" figure is the original... ASCII_size/time The SD (Send Data) LED on the HST was cycling much more slowly for the .Z test than for the other two, and I expected that the double compression might actually expand the data, resulting in worse throughput than the simple ASCII case. Obviously this did not happen. My first thoughts are that either the HST is using a different algorithm than the compress(1) Lempel-Ziv and is gaining some additional compression, or, that the modem detected expansion, turned off compression, yet saved time because it did not have to expend internal CPU cycles performing it. In any case, it appears that you can reduce your phone bill by pre-compressing data before sending it. ..later that decade... I re-ran the test tonight between a 332 (16.6 MHz 68030) and the same 350 using the same modems and MUXes. Both systems running HP-UX 6.5. The remote system was hiding behind a PBX this time. Test data objects: ASCII - "/etc/newconfig/Update.info/from.2.x" (the same file) binary - "/hp-ux", 6.5 packed - ASCII.Z, as crunched by compress(1) The results: ASCII - 1530.8 bytes/sec binary - 1106.9 bytes/sec packed - 832.0 bytes/sec (raw), 1888.0 bytes/sec (net) These HSTs are a year old. U.S.Robotics is claiming slightly higher performance for the current HST. I haven't tried the newer ones, or the V.32 versions. Regards, Hewlett-Packard Bob Niland 3404 East Harmony Road ARPA: rjn%hpfcrjn@hplabs.HP.COM Fort Collins UUCP: [hplabs|hpu*!hpfcse]!hpfcla!rjn CO 80525-9599
generous@dgis.daitc.mil (Curtis Generous) (08/13/89)
ostroff@cboard.UUCP (Boyd Ostroff) writes: >Forgive the stupid question :-), but *how* does one coerce uucico to use >'f' or 'e' or 'x' or ANYTHING other than 'g' on a standard dialup line? The uucico that comes with Pyramid OSx4.4 and latter allows the protocol to be specified with the addition of a new extension to the Caller field in the L.sys file that makes it look something like this: host Any TCP,f telnet host.daitc.mil "" \d\r .... This will force in this case the 'f' protocol to be negotiated with the remote host (if it supports it of course). --curtis -- Curtis C. Generous DTIC Special Projects Office (DTIC-SPO) ARPA: generous@daitc.mil UUCP: {uunet,vrdxhq}!dgis!generous
csg@pyramid.pyramid.com (Carl S. Gutekunst) (08/27/89)
In article <72@cboard.UUCP> ostroff@oswego.Oswego.EDU (Boyd Ostroff) writes: >Forgive the stupid question :-), but *how* does one coerce uucico to use >'f' or 'e' or 'x' or ANYTHING other than 'g' on a standard dialup line? Not a stupid question, because no one documents this, far as I know. On versions that support it, you can put the protocol right after the "ACU" keyword, in L.sys (Systems) and L-devices (Devices), like this: ACU,g (g only) ACU,f (f only) ACU,fg (f if they have it, otherwise g) The versions known to support this are HoneyDanBer, BNU as of SVR3.1, and the "latest" 4.3BSD, which Pyramid and a few other places are using, but does not appear to have made it into 4.3BSD-tahoe. >I'm running HDB UUCP on an AT&T 3B1.... You have a problem. That's BNU, which is an older version of HDB that AT&T-IS got their grubby paws all over. Amongst other things, they took out 'f', and left you with 'x', which is completely unusable. So you're SOL. <csg>