aris@tabbs.UUCP (Aris Stathakis) (09/26/89)
From article <3217@ccnysci.UUCP>, by ciamac@ccnysci.UUCP (Ciamac Moallemi): > Why use Zmodem? A protocol that is a superset of Zmodem would > probably be better (maybe Zmodem itself needs to be revised). A few > extra features that I can think of: > > o Bidirectional transmission. > o Encryption > o Data Compression > > These are just off of the top of my head. I think the Zmodem standard > needs some revision before we do something big like add it to UUCP. I think it's about time someone made a new UUCP protocol with some of these features. Especially Bi-directional transmission. It has been done before for MS-DOS, and i remember and old program for the APPLE II+ that did bi-directional transfers. The 'g' protocol is a bit outdated. We need something NEW and better. Some ideas i had - 1) Variable size packets (that work with MNP5) 2) Bi-Directional transmission. 3) A bit of compression perhaps Any other ideas? I'm no programmer, but i'm sure there is someone out there that could code this. aris -- Aris Stathakis | Bang: ..!uunet!ddsw1!olsa99!tabbs!aris or aris@tabbs.UUCP - UNIX is like sex - if you've tried it, you can't get along without it. - - If you haven't you really have no idea what the fuss is all about! -
sl@van-bc.UUCP (Stuart Lynne) (09/29/89)
In article <240@tabbs.UUCP> aris@tabbs.UUCP (Aris Stathakis) writes: >From article <3217@ccnysci.UUCP>, by ciamac@ccnysci.UUCP (Ciamac Moallemi): >I think it's about time someone made a new UUCP protocol with some of these >features. Especially Bi-directional transmission. It has been done before It's been done. It's called dialup SLIP. Seriously, running dialup SLIP gives you lots of different things. It's not to hard to get. You then can run FTP, Telnet, SMTP, etc over it. Hacking uucp to provide bi-directional file transfer would be virtually impossible. It certainly wouldn't be uucp anymore. Far easier to use existing protocols and software. I originally hacked together uupc from dsp so that people could send/receive mail and news to personal computers. If I was doing it today I would concentrate on getting dialup SLIP access. -- Stuart.Lynne@wimsey.bc.ca uunet!van-bc!sl 604-937-7532(voice) 604-939-4768(fax)
jimb@faatcrl.UUCP (Jim Burwell) (09/29/89)
aris@tabbs.UUCP (Aris Stathakis) writes: >From article <3217@ccnysci.UUCP>, by ciamac@ccnysci.UUCP (Ciamac Moallemi): >> Why use Zmodem? A protocol that is a superset of Zmodem would >> probably be better (maybe Zmodem itself needs to be revised). A few >> extra features that I can think of: >> >> o Bidirectional transmission. >> o Encryption >> o Data Compression >> >> These are just off of the top of my head. I think the Zmodem standard >> needs some revision before we do something big like add it to UUCP. >I think it's about time someone made a new UUCP protocol with some of these >features. Especially Bi-directional transmission. It has been done before >for MS-DOS, and i remember and old program for the APPLE II+ that did >bi-directional transfers. Bi-directional transfer would be nice on sites with full duplex modems, but wouldn't work well at all on sites with half duplex, or ping-pong type modems. There are many UUCP sites which use Telebit Trailblazers and T2500s. Bi-directional transfers wouldn't buy these sites anything. It would be nice for people with generic 2400 baud modems though. It would be difficult to implement in the current UUCP though. >The 'g' protocol is a bit outdated. We need something NEW and better. >Some ideas i had - >1) Variable size packets (that work with MNP5) >2) Bi-Directional transmission. >3) A bit of compression perhaps The 'g' protocol is a bit outdated. But it's not as bad as one might think. There is a bit of windowing involved, which makes 'g' much faster than other protocols which also require handshakes after every block (xmodem, ymodem). Zmodem would be a great addition to UUCPs standard protocols though. It would be the perfect protocol for the Telebit high-speed modems! Handshakeing is only done if it NEEDS to be done (a sector error or something). The file is "streamed" with no delays between bytes, and if a transfer is aborted, one can resume it on a block boundry from where it ended! I don't know how easy it would be to work a Zmodem "resume" type transfer into UUCP though. I don't think we need compression. Most news gets batched and compressed offline before it is sent anyway. It would be nice if mail could be compressed though, I suppose. The latest version of Zmodem does have compression built in, but I'm not sure how easy it would be to implement in UUCP, turning it on and off as needed. -- +------------------------------------------------+--------------------------+ | James S. Burwell | | | | "UseNet...A text network | | UUCP: | in a binary world" - Me | | ...!{ames!netsys|rutgers}!faatcrl | | | !jimb | "How do you say | | . | 'multitasking' in | | Internet: . | MS-DOSish? Network | | // jimb@faatcrl.UUCP . ** | File Server!" - Me | | // . **** | | | \\ // GEnie: Airwarior: . .** | <reserved for future> | | \X/ JIMBURWELL Techrat . | <expansion.... > | +------------------------------------------------+--------------------------+
dg@lakart.UUCP (David Goodenough) (10/02/89)
jimb@faatcrl.UUCP (Jim Burwell) sez: > aris@tabbs.UUCP (Aris Stathakis) writes: >>The 'g' protocol is a bit outdated. We need something NEW and better. >>Some ideas i had - > > The 'g' protocol is a bit outdated. But it's not as bad as one might think. > There is a bit of windowing involved, which makes 'g' much faster than > other protocols which also require handshakes after every block Now, let's see. 2400 BPS * 64 data characters per block / 70 actual characters means you can crank along at about 219 CPS, or 91.4 % of available bandwith. A good Ymodem / Xmodem 1K can get up to the same neck of the woods: I usually hit about 214 - 216 CPS on an Xmodem 1K transfer. What _WOULD_ be worth doing, and uucico has the ability, is to increase the packet size above that #@%*! 64 byte limit. 256 byte packets would mean 262 actual: 2400 * 256 / 262 == 234 CPS or 97.7 % used bandwidth. Then if you go to 1024 byte packets ...... 2400 * 1024 / 1030 == 238 CPS, or (all together now :-) ) "ninety nine and fourty four one hundredths per cent pure data" (actually it's 99.42 %, but what's 2 parts in 10,000 between friends) Also the g protocol has the ability to run bidirectionally, what is needed is to adjust the _FILE_ level section to take advantage of this. Maybe, just maybe, one day I'll do this. Of course, you wouldn't want to do this with a pair of TB's running PEP - it'd get really messy :-) Or would it - with the PEP running a packet size the same as the g protocol packet size, it might just work, although it wouldn't gain you anything. ..... Oh well ..... -- dg@lakart.UUCP - David Goodenough +---+ IHS | +-+-+ ....... !harvard!xait!lakart!dg +-+-+ | AKA: dg%lakart.uucp@xait.xerox.com +---+
mjm@atti07.ATT.COM (Michael Matthews x7776) (10/03/89)
In article <1024@faatcrl.UUCP>, jimb@faatcrl.UUCP (Jim Burwell) writes: > aris@tabbs.UUCP (Aris Stathakis) writes: > > >From article <3217@ccnysci.UUCP>, by ciamac@ccnysci.UUCP (Ciamac Moallemi): > >> Why use Zmodem? A protocol that is a superset of Zmodem would > >> probably be better (maybe Zmodem itself needs to be revised). A few > >> extra features that I can think of: > >> > > >I think it's about time someone made a new UUCP protocol with some of these > >features. Especially Bi-directional transmission. It has been done before > We are using a beta uucp variant with G protocol ( ability to set block sizes to utilized over ACCUNET, X.25 ). It seems what is needed before uucp gets inundated with compiled in protocols is a plug-in protocol capabilty. Ex: uucico -p<my-protocol-pathname> .... Or something to that effect, where uucp passes off actual data-passing to another module. The hand-off would have to be spec-ed out thoroughly and be restricted to data passing only or else security would be compromized. Something similar to the lp spooler subsystem print dest interface. I think it's pretty obvious that uucp protocol capabilty must be expanded but let's introduce *real* flexability instead of hacking the way thru a problem. Mike Matthews ATT International
les@chinet.chi.il.us (Leslie Mikesell) (10/05/89)
In article <280@atti07.ATT.COM> mjm@atti07.ATT.COM (Michael Matthews x7776) writes: >It seems what is needed before uucp gets inundated with compiled in >protocols is a plug-in protocol capabilty. > >Ex: >uucico -p<my-protocol-pathname> .... IMHO, this is exactly the *wrong* thing to do. What we need is exactly one protocol, but with handshake on the details of the transfer. i.e. the first packet should contain the details of the max packet size, max window size, required padding, legal character set for the link, and perhaps status about where the transfer ended the last time these machines connected. >I think it's pretty obvious that uucp protocol capabilty must be >expanded but let's introduce *real* flexability instead of hacking >the way thru a problem. How many ways are there to transfer files? The answer must be pretty well known by now. We just need a single program that handles all of them well. Kermit comes close, but it makes some unnesessary assumptions that limit efficiency. These assumptions could be avoided if the first packet were forced into a kermit-style (printable character) exchange and described the limitations of the link. Les Mikesell
les@chinet.chi.il.us (Leslie Mikesell) (10/07/89)
In article <710@lakart.UUCP> dg@lakart.UUCP (David Goodenough) writes: >> The 'g' protocol is a bit outdated. But it's not as bad as one might think. >Now, let's see. 2400 BPS * 64 data characters per block / 70 actual characters >means you can crank along at about 219 CPS, or 91.4 % of available [...] >Then if you go to 1024 byte packets ...... >2400 * 1024 / 1030 == 238 CPS, If you are going to calculate the best case numbers for a transfer, (i.e. no errors) you should also look at the worst case (i.e. the maximum errors tolerable before the protocol drops the line). It is going to take a lot longer to retransmit a bad 1K packet. After all, the ability to detect and correct errors is the reason that packets are used in the first place. Les Mikesell
jimb@faatcrl.UUCP (Jim Burwell) (10/07/89)
dg@lakart.UUCP (David Goodenough) writes: >jimb@faatcrl.UUCP (Jim Burwell) sez: >> aris@tabbs.UUCP (Aris Stathakis) writes: >>>The 'g' protocol is a bit outdated. We need something NEW and better. >>>Some ideas i had - >> >> The 'g' protocol is a bit outdated. But it's not as bad as one might think. >> There is a bit of windowing involved, which makes 'g' much faster than >> other protocols which also require handshakes after every block >Now, let's see. 2400 BPS * 64 data characters per block / 70 actual characters >means you can crank along at about 219 CPS, or 91.4 % of available >bandwith. A good Ymodem / Xmodem 1K can get up to the same neck of the woods: >I usually hit about 214 - 216 CPS on an Xmodem 1K transfer. Yes. I know the short blocks waste a lot of bandwith, but from watching modem lights, etc, it sure seems to me like there is some windowing going on. I'm not sure, but it seems that 'g' continues to send blocks before it gets acked. Either that, or some uucicos spoof it by sending acks before chcking the block or something. I guess I'll have to dig through some uucico source.. >What _WOULD_ be worth doing, and uucico has the ability, is to increase the >packet size above that #@%*! 64 byte limit. 256 byte packets would mean 262 >actual: [stats deleted...] yes. increasing the packet size would really help, but it seems like a band-aid fix. I still want zmodem! (or some other streaming protocol..but why invent a new one ?) >Also the g protocol has the ability to run bidirectionally, what is needed is >to adjust the _FILE_ level section to take advantage of this. Maybe, just >maybe, one day I'll do this. Of course, you wouldn't want to do this with a >pair of TB's running PEP - it'd get really messy :-) Or would it - with the bidirectional transfers would definitely not gain you much with a PEP connection.. I think the back channel is only 300 baud or so. I'd be happy with Zmodem for now :-). -- +------------------------------------------------+--------------------------+ | James S. Burwell | | | | "UseNet...A text network | | UUCP: | in a binary world" - Me | | ...!{ames!netsys|rutgers}!faatcrl | | | !jimb | "How do you say | | . | 'multitasking' in | | Internet: . | MS-DOSish? Network | | // jimb@faatcrl.UUCP . ** | File Server!" - Me | | // . **** | | | \\ // GEnie: Airwarior: . .** | <reserved for future> | | \X/ JIMBURWELL Techrat . | <expansion.... > | +------------------------------------------------+--------------------------+
jeh@simpact.com (10/08/89)
In article <1029@faatcrl.UUCP>, jimb@faatcrl.UUCP (Jim Burwell) writes: [ (many levels of inclusion from previous messages deleted] > Yes. I know the short blocks waste a lot of bandwith, but from watching modem > lights, etc, it sure seems to me like there is some windowing going on. I'm > not sure, but it seems that 'g' continues to send blocks before it gets acked. > Either that, or some uucicos spoof it by sending acks before chcking the block > or something. I guess I'll have to dig through some uucico source.. > > yes. increasing the packet size would really help, but it seems like a > band-aid fix. I still want zmodem! (or some other streaming protocol..but > why invent a new one ?) > > bidirectional transfers would definitely not gain you much with a PEP > connection.. I think the back channel is only 300 baud or so. I'd be happy > with Zmodem for now :-). > uucp 'g' definitely "streams" (or, in more conventional parlance, does windowing with transmit windowsize > 1; 3 is typical and is more than sufficient to keep the transmitter transmitting continuously), and, no, the other end doesn't spoof. (The Telebit Trailblazer in uucp spoofing mode *does* spoof, but that's another issue.) There are a few implementations (e.g. the gnuucp versino which was the basis for DECUS (VMS) uucp) which don't do windowing but these are the exception. An increased packetsize will produce, at best, a marginal improvement. We typically see at least 215 char/sec throughput with 64-byte packets. Allowing 512-byte packets increases the theoretical max from 219.4 char/sec to 237.2, a whopping 8% increase. Not a big deal. And, as someone else said, increasing the packetsize increases the expense of error recovery. How would ZMODEM be a big improvement??? One oft-cited deficiency of 'g' is that error correction is go-back-n rather than selective retransmit; in other words, the receiver windowsize is 1. This wouldn't be so bad, except that most uucp's I've watched on a line analyzer are very shy about sending NAKs (ReJects for you purists); most of the time they just let the sender time out awaiting an ACK (RR), which really costs. Mind you, it doesn't pay to be too aggressive about sending NAKs either, as the NAKs are nonspecific and will overlap with the sender's attempts to resend the current transmit window, so the sender will resend the whole window again, and... The VMS implementation sends a NAK on the first data checksum error for a given packet and on every (transmit windowsize) error after that; this has proved robust on some remarkably bad lines (some artificially generated, some not), and still allows for reasonably quick error recovery. In practice, I typically see the receipt of an ACK or NAK for packet 'n' during the transmission of 'n'+1, so it does not seem to me that either increasing the windowsize or implementing selective retransmit (which, by the way, limits your windowsize to 3, given g's 3-bit sequence numbers) is going to help much. --- Jamie Hanrahan, Simpact Associates, San Diego CA Chair, VMSnet [DECUS uucp] and Internals Working Groups, DECUS VAX Systems SIG Internet: jeh@simpact.com, or if that fails, jeh@crash.cts.com Uucp: ...{crash,scubed,decwrl}!simpact!jeh
jimb@faatcrl.UUCP (Jim Burwell) (10/09/89)
jeh@simpact.com writes: >In article <1029@faatcrl.UUCP>, jimb@faatcrl.UUCP (Jim Burwell) writes: >> lights, etc, it sure seems to me like there is some windowing going on. I'm >> not sure, but it seems that 'g' continues to send blocks before it gets acked. >> Either that, or some uucicos spoof it by sending acks before chcking the block >> or something. I guess I'll have to dig through some uucico source.. >> >> yes. increasing the packet size would really help, but it seems like a >> band-aid fix. I still want zmodem! (or some other streaming protocol..but >> why invent a new one ?) >> >uucp 'g' definitely "streams" (or, in more conventional parlance, does >windowing with transmit windowsize > 1; 3 is typical and is more than Hmm. FYI, I didn't say 'g' "streamed". I said it did some kind of windowing. I refered to zmodem as a streaming protocol, since that's what it is. >An increased packetsize will produce, at best, a marginal improvement. >We typically see at least 215 char/sec throughput with 64-byte packets. >Allowing 512-byte packets increases the theoretical max from 219.4 char/sec ^^^^^^^^^^^ >to 237.2, a whopping 8% increase. Not a big deal. And, as someone else >said, increasing the packetsize increases the expense of error recovery. I think 8% is a big deal.. What if it were an increase in your income tax, and not protocol throughput. I bet it would be a big deal then :-). >How would ZMODEM be a big improvement??? I typically get 237-238 cps @2400 bps zmodem transfers from the Sun 3/160 at work running rz/sz to my Amiga at home running JR-Comm. This isn't 'theoretical', it's real. It is very close to the theoretical cps limit form 2400 baud modems. ['g' error handleing deficiencies deleted] >Mind you, it doesn't pay to be too aggressive about sending NAKs either, >as the NAKs are nonspecific and will overlap with the sender's attempts to >resend the current transmit window, so the sender will resend the whole >window again, and... The VMS implementation sends a NAK on >the first data checksum error for a given packet and on every (transmit >windowsize) error after that; this has proved robust on some remarkably >bad lines (some artificially generated, some not), and still allows for >reasonably quick error recovery. Zmodem is probably the most robust protocol I've seen out there. I've had it survive some SERIOUSELY crappy phone connections. It just keeps trying and trying. >In practice, I typically see the receipt of an ACK or NAK for packet 'n' >during the transmission of 'n'+1, so it does not seem to me that either >increasing the windowsize or implementing selective retransmit (which, >by the way, limits your windowsize to 3, given g's 3-bit sequence numbers) >is going to help much. I think the answer would be to forget about 'g', and include Zmodem into uucico's protocol list. It would help a LOT. Just the throughput increases over packet switched networks would be enough to justify it. (A friend of mine gets his news feed over a packet network, and says it's HORRIBLY slow. Zmodem was designed for networks.) Also, I think we would see a big throughput increase with the many PEP modems out there in Unix land. Even though Telebits do all that funky spoofing, it still adds overhead to the transmission. With Zmodem, there wouldn't be a need for spoofing. It doesn't stop blasting data until it needs to (error). I hope we have it in UUCP soon. Bye. -- +------------------------------------------------+--------------------------+ | James S. Burwell | | | | "UseNet...A text network | | UUCP: | in a binary world" - Me | | ...!{ames!netsys|rutgers}!faatcrl | | | !jimb | "How do you say | | . | 'multitasking' in | | Internet: . | MS-DOSish? Network | | // jimb@faatcrl.UUCP . ** | File Server!" - Me | | // . **** | | | \\ // GEnie: Airwarior: . .** | <reserved for future> | | \X/ JIMBURWELL Techrat . | <expansion.... > | +------------------------------------------------+--------------------------+
les@chinet.chi.il.us (Leslie Mikesell) (10/09/89)
In article <688.252e37c2@simpact.com> jeh@simpact.com writes: >Allowing 512-byte packets increases the theoretical max from 219.4 char/sec >to 237.2, a whopping 8% increase. Not a big deal. And, as someone else >said, increasing the packetsize increases the expense of error recovery. >How would ZMODEM be a big improvement??? The problem with 'g' is that the maximum window of unack'ed data is 7 * 64 char packets, and most hosts won't allow more than 3 packets. When you try to use this protocol over a connection that has a long turn-around time (satellite links, busy packet nets, modems that fake full-duplex by turning the line around, etc.), the sender ends up waiting for ack's instead of driving the link at full speed. Increasing the packet size is a quick and dirty fix, but what we really need is an intelligent handshake between hosts that describes the best way to handle the connection, along with reasonable fall-back if the error rate is excessive at a large block/window size. Les Mikesell
johnl@esegue.segue.boston.ma.us (John R. Levine) (10/09/89)
In article <1032@faatcrl.UUCP> jimb@faatcrl.UUCP (Jim Burwell) writes: >I think the answer would be to forget about 'g', and include Zmodem into >uucico's protocol list. ... Also, I think we would see a big throughput >increase with the many PEP modems out there in Unix land. Even though >Telebits do all that funky spoofing, it still adds overhead to the >transmission. With Zmodem, there wouldn't be a need for spoofing. Zmodem is undoubtedly a better protocol than 'g' for a full-duplex transparent connection such as that provided by 2400 bps modems, 9600 bps V.32 modems, or by packet switch networks. PEP, though, is really a half-duplex protocol, and fakes full-duplex by turning the line around. That means that the zmodem ACK packets cause a performance hit and spoofing would still be a win. If someone who actually understands the details of how Telebit's spoofing works, and what sort of protocol they really use, that would be great. PEP uses a large number of very slow channels, and I don't know whether spoof mode means that they use a few of the channels for the ACKs and the rest for the data, or if they use bigger blocks and still turn the line around. (Gee, Jim, I never had any trouble sucking down news from you using 'g' spoof mode.) -- John R. Levine, Segue Software, POB 349, Cambridge MA 02238, +1 617 492 3869 johnl@esegue.segue.boston.ma.us, {ima|lotus}!esegue!johnl, Levine@YALE.edu Massachusetts has 64 licensed drivers who are over 100 years old. -The Globe
sl@van-bc.UUCP (Stuart Lynne) (10/09/89)
In article <1032@faatcrl.UUCP> jimb@faatcrl.UUCP (Jim Burwell) writes: > >jeh@simpact.com writes: > >gets his news feed over a packet network, and says it's HORRIBLY slow. Zmodem >was designed for networks.) Also, I think we would see a big throughput >increase with the many PEP modems out there in Unix land. Even though Telebits >do all that funky spoofing, it still adds overhead to the transmission. With Perhaps if you're talking to your PEP modem at 9600 bps. But not if you are using 19.2. At that speed uucp with it's overhead should be able to supply enough data to completely fill the bandwidth available for data between the two modems (something like 14kbps before compression). Remember that what two PEP's do to spoof uucp is to talk "g" packet protocol between the modem and the computer. But simply assume an error free link between themselves. Unless they spoof Zmodem you will probably see a slight drop in throughput as the modem now has to transfer the Zmodem framing as data. They didn't have to transfer the uucp framing char's. On another note, other posters have suggested that the packet size be increased. One serendipitous property of the current setup of 3 * 64 plus framing is that all three will fit into the normal amount of room allocated to a serial port for bufferring in CLIST's (256 bytes). This means that if the receiving uucico has been swapped to disk and there's no one there to pull the data out you won't get an overrun. Everything just sits there until uucico swap's back in and acks the received packets. If you run a window size greater than 3 or increase the packet size the tty driver will overrun it's CLIST buffers and dump everything. Then we usually will see a 10 second wait until the sender resends. -- Stuart.Lynne@wimsey.bc.ca uunet!van-bc!sl 604-937-7532(voice) 604-939-4768(fax)
iiitsh@cybaswan.UUCP (Steve Hosgood) (10/09/89)
In article <9745@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: >In article <280@atti07.ATT.COM> mjm@atti07.ATT.COM (Michael Matthews x7776) writes: >>It seems what is needed before uucp gets inundated with compiled in >>protocols is a plug-in protocol capabilty. >> >How many ways are there to transfer files? The answer must be pretty >well known by now. We just need a single program that handles all of >them well. Kermit comes close, but it makes some unnesessary assumptions >that limit efficiency. These assumptions could be avoided if the first >packet were forced into a kermit-style (printable character) exchange and >described the limitations of the link. > I prefer Mike's plug-in approach. It would make it much easier for new improved protocols to be designed and circulated (in this newsgroup for instance). Even users with no source licence could pick them up and add them to his system if it was done correctly. A single-program-that-handles-everything is an Algol-68 style answer, in other words a program so complex that no-one ever gets around to implementing the whole thing - only subsets. That's what we've got now with UUCP, and we all know the limitations. For one thing, the bigger it gets, the buggier it gets, and in an age of network worms, that's the last thing you want! There's no 'one way' to transfer files. It's a compromise between many requirements, and complicated by the different types of transport medium available. Look at (say) the different assumptions made by the 'f' and 'g' protocols. The first assumes a pretty well error-free 7-bit transmission medium, the second assumes only that there's 8-bit transparency, and allows for error recovery. There seems to be no equivalent of the 'g' protocol for 7-bit links. Why doesn't someone go and write one? Answer - because it's not possible to get it passed around to all the other interested UUCP users. With a plug-together UUCP this would be much easier. Similarly, those recent posters suggesting protocols that do compression could be catered for with a such a system. Just allow for a selection of plug-in compressors (separate from the protocol managers). Steve
mju@mudos.ann-arbor.mi.us (Marc Unangst) (10/09/89)
In article <1989Oct9.003603.3693@esegue.segue.boston.ma.us>, johnl@esegue.segue.boston.ma.us (John R. Levine) writes: >PEP, though, is really a >half-duplex protocol, and fakes full-duplex by turning the line around. That >means that the zmodem ACK packets cause a performance hit and spoofing would >still be a win. Sigh. This is why we want Zmodem -- Zmodem is a streaming ACKless protocol. The only time a receiving Zmodem sends anything back to the sender is if it gets a bad block, or at the end of each file. In addition, Zmodem adapts dynamically to noisy lines -- It drops the packet size if it gets a lot of errors, and then will bring it back up (eventually) if it stops getting line hits. -- Marc Unangst Internet: mju@mudos.ann-arbor.mi.us UUCP : ...!uunet!sharkey!mudos!mju Fidonet : Marc Unangst of 1:120/129.0 BBS : The Starship Enterprise, 1200/2400 bps, +1 313-665-2832
caf@omen.UUCP (Chuck Forsberg) (10/09/89)
In article <1989Oct9.003603.3693@esegue.segue.boston.ma.us> johnl@esegue.segue.boston.ma.us (John R. Levine) writes:
:If someone who actually understands the details of how Telebit's spoofing
:works, and what sort of protocol they really use, that would be great. PEP
:uses a large number of very slow channels, and I don't know whether spoof
:mode means that they use a few of the channels for the ACKs and the rest
:for the data, or if they use bigger blocks and still turn the line around.
Telebit's spoofing collects packets at the sending end into
the long packets PEP likes (1-2k I'd guess) and splits the
long PEP packets back into small UUCP packets at the receiving
end. I suspect this process does not waste modem bandwith
with the relatively high overhead of UUCP packets (assuming
19200 bps interface speed).dg@lakart.UUCP (David Goodenough) (10/10/89)
les@chinet.chi.il.us (Leslie Mikesell) sez: > mjm@atti07.ATT.COM (Michael Matthews x7776) writes: >>It seems what is needed before uucp gets inundated with compiled in >>protocols is a plug-in protocol capabilty. > > IMHO, this is exactly the *wrong* thing to do. What we need is exactly > one protocol, but with handshake on the details of the transfer. No - I agree with Mr. Matthews. Look at communications in general: Xmodem, Kermit, Zmodem, Punter Protocol - all do the same basic function: get a file from one system to another. But which one you use depends on several things (like do you have the horsepower to keep Zmodem streaming?, do you have a Punter Protocol implementation available?) The problem with UUCP is that "g" was designed around systems with overlapping disk and serial I/O - To do a "g" implementation when you don't have those is tricky at best (I know - I've done it :-) ). How much easier it would have been for me to just drop in Xmodem and go with it. Faster too: I only get about 160 CPS throughput on "g" at 2400, as opposed to 210 on an Xmodem 1K. The advantage of this is that it keeps compatibility: instead of saying: Ptg you just say: PtgXzqsplat and the master gets to chose. -- dg@lakart.UUCP - David Goodenough +---+ IHS | +-+-+ ....... !harvard!xait!lakart!dg +-+-+ | AKA: dg%lakart.uucp@xait.xerox.com +---+
rick@uunet.UU.NET (Rick Adams) (10/10/89)
Those of you who think that increasing the g protocol packet size is an automatic win would be well advised to see what happens to the error counts. Someone who I trust and can remember his name sent me some statistics that showed that the g protocol error checking became quite weak on larger packets. (I'm talking about undetected errors not the recovery scheme). I'd make damned sure that the error detection algorithm still worked reliably on larger packets. ---rick
dplatt@coherent.com (Dave Platt) (10/10/89)
In article <1989Oct9.003603.3693@esegue.segue.boston.ma.us> johnl@esegue.segue.boston.ma.us (John R. Levine) writes: > Zmodem is undoubtedly a better protocol than 'g' for a full-duplex > transparent connection such as that provided by 2400 bps modems, 9600 bps > V.32 modems, or by packet switch networks. PEP, though, is really a > half-duplex protocol, and fakes full-duplex by turning the line around. That > means that the zmodem ACK packets cause a performance hit and spoofing would > still be a win. In its normal, streaming mode, the ZMODEM protocol does not send ACKs during data transmission... only at the end of the file. NAKs are sent whenever data transmission errors occur. The only time I've found it necessary to switch ZMODEM over into a windowed mode of operation is if the transmitting system is sending data faster than the receiver can gobble the data, and the transmitter doesn't support flow control. In this situation, ZMODEM does use periodic ACKs, and these could (as you suggest) slow down a PEP transfer if they caused more-frequent line turnarounds. I believe that a ZMODEM streaming transmission through a TrailBlazer would not require any more line-turnarounds than the spoofed UUCP protocol through the same modems. > If someone who actually understands the details of how Telebit's spoofing > works, and what sort of protocol they really use, that would be great. PEP > uses a large number of very slow channels, and I don't know whether spoof > mode means that they use a few of the channels for the ACKs and the rest > for the data, or if they use bigger blocks and still turn the line around. The latter (bigger blocks, with occasional line turnarounds). You can hear this quite easily if you configure the modem to leave its speaker turned on during a session. To my ear, a spoofed reception of a big file sounds like "chuffa-chuffa-chuffa-chuffa (pause) CHUF (pause) chuffa-chiffa....". A _long_ block arrives (1-2 seconds worth), the line is turned around, the local modem sends back an ack/nak packet, the line turns around again, and the remote modem sends the next block of data (with, if necessary, any packets from the prior block that required retransmission). I believe that a streamed ZMODEM transmission would sound, and behave, in very much the same manner. The UUCP-spoofing used by the modem has the effect of converting the uucp protocol from a sliding-window, remote-acknowledge protocol into something very similar to a streaming protocol with modem-based flow control. -- Dave Platt VOICE: (415) 493-8805 UUCP: ...!{ames,apple,uunet}!coherent!dplatt DOMAIN: dplatt@coherent.com INTERNET: coherent!dplatt@ames.arpa, ...@uunet.uu.net USNAIL: Coherent Thought Inc. 3350 West Bayshore #205 Palo Alto CA 94303
jimb@faatcrl.UUCP (Jim Burwell) (10/10/89)
johnl@esegue.segue.boston.ma.us (John R. Levine) writes: >Zmodem is undoubtedly a better protocol than 'g' for a full-duplex >transparent connection such as that provided by 2400 bps modems, 9600 bps >V.32 modems, or by packet switch networks. PEP, though, is really a >half-duplex protocol, and fakes full-duplex by turning the line around. That >means that the zmodem ACK packets cause a performance hit and spoofing would >still be a win. Hmm.. Zmodem doesn't send ACK packets back to the sender, unless it's in some silly mode (portal and GEnie seem to use that block/ack mode). Normally, Zmodem just thunders along, sending data, and the reciever sucks it up. The control info (sector number, command sequences, and CRCs) are embedded into the constant stream of data at intervals known to both the sender and receiver (whatever the current packet length is.. Anywhere from 64 {32 ?} bytes to 1Kb). The only time the receiver ever sends data back to the sender is when there is a problem (a bad CRC, sector length, etc, etc), or to ACK the ZFIN (Zmodem end of file packet) at the end of the transfer. >If someone who actually understands the details of how Telebit's spoofing >works, and what sort of protocol they really use, that would be great. PEP >uses a large number of very slow channels, and I don't know whether spoof >mode means that they use a few of the channels for the ACKs and the rest >for the data, or if they use bigger blocks and still turn the line around. PEP is an "error free" protocol between the two PEP modems. The Telebits simply ack every block they get from 'g' on the computer, unless there is a fatal error in the PEP link, in which case they cancel the transfer (I don't know how one cancels a 'g' transfer.. maybe just NAK it out).. In other words, the modem just tells 'g' what it wants to hear, while the real data transfer handshaking/ error correction/etc is done between the modems in PEP. This is how all spoof modes work on Telebits.. >(Gee, Jim, I never had any trouble sucking down news from you using 'g' >spoof mode.) :-). Yeah, but I bet our xfer times would have been MUCH faster if it used Zmodem.. :-). Actually, UUCP could be scrapped all together if Zmodem were used exclusively.. I don't know if it was ever implemented, but in Zmodem, there is a provision for passing commands to a shell through the protocol. Some kind of "command packet" in which a string is sent which gets stuffed into a shell. But forget that! UUCP works fine the way it is, 'cept for the protocols used by uucico, IMHO.. It would be nice to have Zmodem.. sigh.. -- +------------------------------------------------+--------------------------+ | James S. Burwell | | | | "UseNet...A text network | | UUCP: | in a binary world" - Me | | ...!{ames!netsys|rutgers}!faatcrl | | | !jimb | "How do you say | | . | 'multitasking' in | | Internet: . | MS-DOSish? Network | | // jimb@faatcrl.UUCP . ** | File Server!" - Me | | // . **** | | | \\ // GEnie: Airwarior: . .** | <reserved for future> | | \X/ JIMBURWELL Techrat . | <expansion.... > | +------------------------------------------------+--------------------------+
jimb@faatcrl.UUCP (Jim Burwell) (10/10/89)
sl@van-bc.UUCP (Stuart Lynne) writes: >In article <1032@faatcrl.UUCP> jimb@faatcrl.UUCP (Jim Burwell) writes: >> >>jeh@simpact.com writes: >Perhaps if you're talking to your PEP modem at 9600 bps. But not if you are >using 19.2. At that speed uucp with it's overhead should be able to supply >enough data to completely fill the bandwidth available for data between the >two modems (something like 14kbps before compression). Yep. I know that.. We are running 19.2. But your point is taken. The modem's buffer is full before it can even send it over the PEP link. So as long as no PEP bandwidth is used up by the modems processor negotiating 'g' with the computer, no throughput is lost. However, throughput IS still lost using any other modem than a Telebit at 19.2 Kbps, with 'g' spoofing enabled. There are still a lot of plain 2400 baud modems out there which could be gettting better throughput using a better protocol. Not to mention, a lot of buffered, MNP modems which don't do spoofing! I'd HATE to run UUCP on a USR HST Dual-Standard with MNP! Even though it's most likely a faster modem than Telebit's current PEP modems, 'g' would kill it, unless USR put 'g' spoofing into that one. (BTW, does anyone know which modem is faster? The Telebit T2500, or the USR HST Dual-Standard.. My friends stated Zmodem CPS times of 1600 and up lead me to believe that the DS is faster.. I heard you can only get 1600-1800 on a TB on a "good day" :-) >Remember that what two PEP's do to spoof uucp is to talk "g" packet protocol >between the modem and the computer. But simply assume an error free link >between themselves. Yep. I know this. But does the Telebit have a dedicated processor to do this ? Does the 'g' negotiation and PEP transfer occur asynchronousely ? >Unless they spoof Zmodem you will probably see a slight drop in throughput >as the modem now has to transfer the Zmodem framing as data. They didn't >have to transfer the uucp framing char's. Another good point. I think Zmodem sends 32 bytes of framing data per packet... Am I wrong ? That would give 'g' spoofing an advantage over Zm with that specific modem... [unix stuff deleted] >This means that if the receiving uucico has been swapped to disk and there's >no one there to pull the data out you won't get an overrun. Everything just >sits there until uucico swap's back in and acks the received packets. If you >run a window size greater than 3 or increase the packet size the tty driver >will overrun it's CLIST buffers and dump everything. Then we usually will >see a 10 second wait until the sender resends. Yike.. ! That sounds like a Unix problem to me though. I wonder if you can code uucico to forbid the OS from swapping uucico (or buffers, or whatever a CLIST is :-) ? That's scary! I hope Unix doesn't swap device drivers too! :-). I can see it swapping the program doing the high level protocol, but not the drivers ! Is there anyway to force it not to swap your poor program ? Bye Jim -- +------------------------------------------------+--------------------------+ | James S. Burwell | | | | "UseNet...A text network | | UUCP: | in a binary world" - Me | | ...!{ames!netsys|rutgers}!faatcrl | | | !jimb | "How do you say | | . | 'multitasking' in | | Internet: . | MS-DOSish? Network | | // jimb@faatcrl.UUCP . ** | File Server!" - Me | | // . **** | | | \\ // GEnie: Airwarior: . .** | <reserved for future> | | \X/ JIMBURWELL Techrat . | <expansion.... > | +------------------------------------------------+--------------------------+
caf@omen.UUCP (Chuck Forsberg) (10/10/89)
In article <25@van-bc.UUCP> sl@van-bc.UUCP (Stuart Lynne) writes:
:Unless they spoof Zmodem you will probably see a slight drop in throughput
:as the modem now has to transfer the Zmodem framing as data. They didn't
:have to transfer the uucp framing char's.
When I made a comparision between UUCP spoofing and ZMODEM on
TrailBlazers, ZMODEM was somewhat faster. I'd like to run the
tests on a pair of T2500's but haven't received any yet.
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:CAFjeh@simpact.com (10/10/89)
In article <672.2530C0D4@mudos.ann-arbor.mi.us>, mju@mudos.ann-arbor.mi.us (Marc Unangst) writes: > In article <1989Oct9.003603.3693@esegue.segue.boston.ma.us>, johnl@esegue.segue.boston.ma.us (John R. Levine) writes: > >PEP, though, is really a > >half-duplex protocol, and fakes full-duplex by turning the line around. That > >means that the zmodem ACK packets cause a performance hit and spoofing would > >still be a win. > > Sigh. This is why we want Zmodem -- Zmodem is a streaming ACKless protocol. > The only time a receiving Zmodem sends anything back to the sender is if > it gets a bad block, or at the end of each file. > This may be a concern for other types of modems, but not for Telebits in PEP/uucp spoofing mode. The uucp acks and naks do NOT get sent end-to-end; the modems do their own ACKs, NAKs, and retransmission; a few of the PEP channels are reserved for "supervisory data" in both directions, and so line turnaround is not required. ZMODEM fans take note: I never said that it wouldn't be worthwhile to do ZMODEM under uucp. I expect that most uucp sites wouldn't find it all that beneficial (perhaps for reasons having nothing to do with technical merit), but if it'll solve some problems for some, go with it! That's why uucp supports multiple protocol options! Only, please make sure that the problems and solutions are real... preferably by experiment and measurement rather than theorizing. (Note that ZMODEM performance with dedicated systems, ie when at least one end is a PC, is not necessarily indicative of what will happen when both ends are multiuser timesharing systems.) As I've said, I have my doubts that ZMODEM will be all that big an improvement, but I'm just theorizing myself... --- Jamie Hanrahan, Simpact Associates, San Diego CA Chair, VMSnet [DECUS uucp] and Internals Working Groups, DECUS VAX Systems SIG Internet: jeh@simpact.com, or if that fails, jeh@crash.cts.com Uucp: ...{crash,scubed,decwrl}!simpact!jeh
peter@ficc.uu.net (Peter da Silva) (10/11/89)
In article <754@cybaswan.UUCP> iiitsh@cybaswan.UUCP (Steve Hosgood) writes: > A single-program-that-handles-everything is an Algol-68 style answer, in other > words a program so complex that no-one ever gets around to implementing the > whole thing - only subsets. That's what we've got now with UUCP... Actually, the UUCP protocol suite is pretty modular. You have a file transfer program, a queueing program, a batch execution program, and so on. It could certainly be more modular, yes. But by contrast with other, similar, programs I've used (UUPC, Fido) it's clean. Now that I've said that, I do think protocol modules (and dial modules, and chat modules, etc...) are a good idea. Among other advantages... With ANI, and a modem that understands it, it might be possible some day to make email as convenient as FAX: "mail 7134385018!peter". If you know the number a caller used, you can feel fairly safe about letting him in. -- Peter da Silva, *NIX support guy @ Ferranti International Controls Corporation. Biz: peter@ficc.uu.net, +1 713 274 5180. Fun: peter@sugar.hackercorp.com. `-_-' 'U` Quote: Structured Programming is a discipline -- not a straitjacket.
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (10/11/89)
In article <688.252e37c2@simpact.com>, jeh@simpact.com writes: | uucp 'g' definitely "streams" (or, in more conventional parlance, does | windowing with transmit windowsize > 1; 3 is typical and is more than | sufficient to keep the transmitter transmitting continuously), and, no, This depends on your situation, when I installed a new version of UNIX I forgot to set the windows to seven, and the throughput was down around 200cps. Going to seven brought it back to 220. This makes even more diference in MNP mode. Don't ask why, I just read the xferstats. | the other end doesn't spoof. (The Telebit Trailblazer in uucp spoofing | mode *does* spoof, but that's another issue.) There are a few implementations | (e.g. the gnuucp versino which was the basis for DECUS (VMS) uucp) which | don't do windowing but these are the exception. And the performance is pretty poor, too. | | An increased packetsize will produce, at best, a marginal improvement. | We typically see at least 215 char/sec throughput with 64-byte packets. | Allowing 512-byte packets increases the theoretical max from 219.4 char/sec | to 237.2, a whopping 8% increase. Not a big deal. And, as someone else | said, increasing the packetsize increases the expense of error recovery. I agree with your technical comments, but 8% can be important if (a) you pay out of your own pocket, or (b) you are talking a large phone bill. Some sites have bills of $6000+/month, and they could justify a few days of someone's time if it were that simple. Note, I don't say it necessarily is, and faster modems seem to be more cost effective with spoofing, but don't think the 8% would be unimportant to everyone. [ much good explanation of NAK frequency tradeoffs ] -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "The world is filled with fools. They blindly follow their so-called 'reason' in the face of the church and common sense. Any fool can see that the world is flat!" - anon
peter@ficc.uu.net (Peter da Silva) (10/11/89)
Rather than adding a 'z==zmodem' protocol, how about adding a 'z==external',
with some sort of handshake like this:
PROTO fgz --->
<--- PROTO z
PROTO "foobar" --->
<--- NO
PROTO "zmodem" --->
<--- OK
...
(continues with ZMODEM setup)
Or if no external protocol is agreed on,
PROTO "kermit" --->
<--- NO
PROTO fg --->
<--- PROTO g
--
Peter da Silva, *NIX support guy @ Ferranti International Controls Corporation.
Biz: peter@ficc.uu.net, +1 713 274 5180. Fun: peter@sugar.hackercorp.com. `-_-'
'U`
Quote: Structured Programming is a discipline -- not a straitjacket.syd@DSI.COM (Syd Weinstein) (10/11/89)
jimb@faatcrl.UUCP (Jim Burwell) writes: >sl@van-bc.UUCP (Stuart Lynne) writes: >>This means that if the receiving uucico has been swapped to disk and there's >>no one there to pull the data out you won't get an overrun. Everything just >>sits there until uucico swap's back in and acks the received packets. If you >>run a window size greater than 3 or increase the packet size the tty driver >>will overrun it's CLIST buffers and dump everything. Then we usually will >>see a 10 second wait until the sender resends. >Yike.. ! That sounds like a Unix problem to me though. I wonder if you can >code uucico to forbid the OS from swapping uucico (or buffers, or whatever a >CLIST is :-) ? That's scary! I hope Unix doesn't swap device drivers too! :-). Ok, now we get to some real stuff, End to End, Zmodem/UUCP-G/UUCP-F are all fine in abstract, but remember uucp-g was designed for the limitations of unix. In the DOS world, the computer is listening all the time and dedicated to that job at the interrupt level, so running out of buffer space is not as much of a problem. In Unix, the uucico program is just that a user program. It posts a read, and Unix sets up buffers for that read, those buffers are called CLISTs or Character Lists. It just so happens that Unix was designed to allow a serial port to get about 256 characters ahead before deciding that the an input overflow has occurred and then it throws away the entire input queue, remember Unix is designed for human typists at terminals, so it does output an overflow message. Any multitasking O/S has an input queue length that can be exceeded if the user task is preempted for too long and the input keeps arriving. Unix choose 256 bytes, it could be tuned, and sometimes intelligent I/O boards add extra buffering in addition to that 256 bytes. UUCP g protocol ties in to that 256 byte limit, and in fact the parameters for g were designed with that in mind. Its not that the device driver gets locked out, but that the device driver must store the characters somewhere and it runs out of room to store them in the buffer (CLIST) preallocated for the read. Thus on a busy system, ZMODEM is bound to have problems if the zmodem task (user level task) is preempted for longer than 256 character times. On a lightly loaded system, its unlikely to stay prempted for that long. Also, please remember that end to end times matter, not just CPS. Much of the time in uucp is dead time deciding which file to transfer and acquiring permission for that transfer. With most mail files being rather short, this is substantial. A better gain could be in using BSMTP for mail instead of rmail. Measure the length of the phone call for the bytes transferred, and you will see that the 8% cps improvement might turn out to only be a 1% call time improvement, and not worth all the extra effort. Again, long compressed batches of news skew some numbers, but also remember that many links are limited by the speed of the computer. Most sites running at 19200 cannot really exchange data at that rate, but really at 1100 or 1200 cps, each character being sent at 19200, but delays between bursts of characters slow it down. Thus the spoofing of a Telebit actually ends up waiting for the computer much of the time. -- ===================================================================== Sydney S. Weinstein, CDP, CCP Elm Coordinator Datacomp Systems, Inc. Voice: (215) 947-9900 syd@DSI.COM or {bpa,vu-vlsi}!dsinc!syd FAX: (215) 938-0235
caf@omen.UUCP (Chuck Forsberg) (10/11/89)
In article <690.25315ee6@simpact.com> jeh@simpact.com writes:
:PEP/uucp spoofing mode. The uucp acks and naks do NOT get sent end-to-end;
:the modems do their own ACKs, NAKs, and retransmission; a few of the PEP
:channels are reserved for "supervisory data" in both directions, and so line
:turnaround is not required.
Perhaps this has changed in newer models, but the TrailBlazers I have
turn the line around when spoofing UUCP.
To answer a previous question about ZMODEM framing overhead I must give
some basics of ZMODEM. When ZMODEM is in full streaming operation, the
data in a file is sent as a ZDATA header followed by 0 or more data
subpackets whose lengths are 0-1024 bytes. So in a 16K file with no
errors we could have one ZDATA header (about 11 bytes if CRC-32 is used)
and 16 data subpackets. Each data subpacket is terminated by two bytes
and CRC. In a long file sent with CRC-32, the framing overhead approaches
6/1024, or about 0.6 per cent.
To support network operations, ZMODEM protects XON, XOFF, and DLE in both
parities. This adds just under 3 per cent overhead on typical compressed
files.tp@mccall.uucp (Terry Poot) (10/11/89)
In article <975@crdos1.crd.ge.COM>, davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) writes: > In article <688.252e37c2@simpact.com>, jeh@simpact.com writes: > | (e.g. the gnuucp versino which was the basis for DECUS (VMS) uucp) which > | don't do windowing but these are the exception. > And the performance is pretty poor, too. I get from 215 to 217 cps over a 2400 baud modem using DECUS (VMS) uucp to talk to a 4.3bsd system and an SCO Xenix system. These numbers are pretty close to what a previous posting gave for unix performance, so either his implementation doesn't do windowing either, or the lack of it doesn't make too much difference. I wouldn't say my performance is poor. -- Terry Poot (800)255-2762, in Kansas (913)776-3683 The McCall Pattern Company, 615 McCall Rd., Manhattan, KS 66502, USA UUCP: rutgers!ksuvax1!mccall!tp Internet: tp%mccall@ksuvax1.cis.ksu.edu
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (10/12/89)
In article <342@mccall.uucp>, tp@mccall.uucp (Terry Poot) writes: | implementation doesn't do windowing either, or the lack of it doesn't make | too much difference. I wouldn't say my performance is poor. You are certainly getting good throughput. My comments were based on previous experience with someone who wanted to get a dowload from me to a VMS system. You may have a better version, better connection, or less loaded machine. All I can comment on is what I have observed, which was slow. In general slow line turnaround caused by communications or machine load will severely impact thruput, and adding buffers will improve performance under these conditions. I thought the recent discussion covered this pretty well without a lot of qualifiers. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "The world is filled with fools. They blindly follow their so-called 'reason' in the face of the church and common sense. Any fool can see that the world is flat!" - anon
paul@frcs.UUCP (Paul Nash) (10/13/89)
In article <688.252e37c2@simpact.com>, jeh@simpact.com writes: > One oft-cited deficiency of 'g' is that error correction is go-back-n > rather than selective retransmit; in other words, the receiver windowsize One advantage of `ZMODEM' in particular, that everyone seems to have overlooked, is the ability to use `recover' mode. If you have ever had a phone line (or modem) die on you near the end of a news feed (or better still, big source code transfer), you will value the ability to restart where you left off. This can save megaBucks on phone bills, aswell as lots and lots of time. Maybe your phone lines and modems never break, but mine give endless trouble, to the extent where I use proYAM and Zmodem rather than uucp for transfers from machines that have `rz/sz'. --------------------------------------------------------------------- ...!uunet!ddsw1!olsa99!tabbs!frcs!paul paul@frcs.UUCP
jimb@faatcrl.UUCP (Jim Burwell) (10/14/89)
syd@DSI.COM (Syd Weinstein) writes: >Any multitasking O/S has an input queue length that can be exceeded if >the user task is preempted for too long and the input keeps arriving. >Unix choose 256 bytes, it could be tuned, and sometimes intelligent >I/O boards add extra buffering in addition to that 256 bytes. Hmm.. I've only had good experiances with Zmodem from our sun 3/160 to my Amiga 500 at home. Both run multi-tasking operation systems, though the Amiga isn't multi-user.. I regularly get the best CPS sending to, and recieving from our Sun. The best I get anywhere.. That includes the many PC BBSs I call, some of them running on '386s, which are faster than the 68020 in our sun 3. And the 386 is running MS-DOS, and isn't loaded down with a multi-user/tasking OS. I've never gotten above 236 CPS (2400 bps) from the PC systems.. I regularly get 238 and 239 CPS from our Sun.. >Its not that the device driver gets locked out, but that the device >driver must store the characters somewhere and it runs out of room >to store them in the buffer (CLIST) preallocated for the read. Would it be difficult to increase the buffer length to say 4K or so... That way you wouldn't have to worry about it.. What about DMA? I suppose they make serial boards which cache all the data comeing into the uart, and DMA into the system at some point... am I correct ? >Thus on a busy system, ZMODEM is bound to have problems if the >zmodem task (user level task) is preempted for longer than 256 >character times. On a lightly loaded system, its unlikely to stay >prempted for that long. Can't say I've done a Zmodem transfer with 6 users on the system while it's unbatching a load of news :-). But that kind of character level stuff usually goes pretty fast on the Sun, even when moderately loaded down.. >Also, please remember that end to end times matter, not just CPS. >Much of the time in uucp is dead time deciding which file to transfer >and acquiring permission for that transfer. With most mail files >being rather short, this is substantial. A better gain could be >in using BSMTP for mail instead of rmail. Measure the length of the >phone call for the bytes transferred, and you will see that the 8% >cps improvement might turn out to only be a 1% call time improvement, >and not worth all the extra effort. Again, long compressed batches >of news skew some numbers, but also remember that many links are limited >by the speed of the computer. Most sites running at 19200 cannot really >exchange data at that rate, but really at 1100 or 1200 cps, each character >being sent at 19200, but delays between bursts of characters slow it down. >Thus the spoofing of a Telebit actually ends up waiting for the computer >much of the time. I've always thought that mail was inefficiant too. I often wonder why mail isn't batched the same way news is, on a site level, between polls. Perhaps the UseNet gods will re-implement or upgrade mail some day... As for the 1% improvement, I doubt it would always be that low. But there are many other advantages Zmodem would give us, which have been outlined previousely in this thread. Those advantatges alone are worth the "effort" I think. We already have Zmodem in the form of rz/sz. That could be called in a number of ways, or simply included on a source level into the current uucp, unless of course, Chuck objects :-). Zmodem is a modern, robust protocol. It is the most popular protocol in the personal computer world, and it's inevitable that it will find its way into UseNet/uucp somehow. CUL, -- +------------------------------------------------+--------------------------+ | James S. Burwell | | | | "UseNet...A text network | | UUCP: | in a binary world" - Me | | ...!{ames!netsys|rutgers}!faatcrl | | | !jimb | "How do you say | | . | 'multitasking' in | | Internet: . | MS-DOSish? Network | | // jimb@faatcrl.UUCP . ** | File Server!" - Me | | // . **** | | | \\ // GEnie: Airwarior: . .** | <reserved for future> | | \X/ JIMBURWELL Techrat . | <expansion.... > | +------------------------------------------------+--------------------------+
jimb@faatcrl.UUCP (Jim Burwell) (10/14/89)
caf@omen.UUCP (Chuck Forsberg) writes: >Perhaps this has changed in newer models, but the TrailBlazers I have >turn the line around when spoofing UUCP. Do you have uucp spoofing mode turned on ? On a Telebit T2500, you would set s111 to 30 for the 'g' protocol. >To answer a previous question about ZMODEM framing overhead I must give >some basics of ZMODEM. When ZMODEM is in full streaming operation, the >data in a file is sent as a ZDATA header followed by 0 or more data >subpackets whose lengths are 0-1024 bytes. So in a 16K file with no >errors we could have one ZDATA header (about 11 bytes if CRC-32 is used) >and 16 data subpackets. Each data subpacket is terminated by two bytes >and CRC. In a long file sent with CRC-32, the framing overhead approaches >6/1024, or about 0.6 per cent. Yow! I assumed that each 1k packet had that long control string embedded in it ("**B############", etc). Zmodem is even more efficient than I thought! One day I'll sit down and read my zmodem description textfile thouroughly :-). >To support network operations, ZMODEM protects XON, XOFF, and DLE in both >parities. This adds just under 3 per cent overhead on typical compressed >files. One of the many reasons I use Zmodem every day. Great prot. Chuck! CU, -- +------------------------------------------------+--------------------------+ | James S. Burwell | | | | "UseNet...A text network | | UUCP: | in a binary world" - Me | | ...!{ames!netsys|rutgers}!faatcrl | | | !jimb | "How do you say | | . | 'multitasking' in | | Internet: . | MS-DOSish? Network | | // jimb@faatcrl.UUCP . ** | File Server!" - Me | | // . **** | | | \\ // GEnie: Airwarior: . .** | <reserved for future> | | \X/ JIMBURWELL Techrat . | <expansion.... > | +------------------------------------------------+--------------------------+
allbery@NCoast.ORG (Brandon S. Allbery) (10/15/89)
As quoted from <690.25315ee6@simpact.com> by jeh@simpact.com: +--------------- | Only, please make sure that the problems and solutions are real... preferably | by experiment and measurement rather than theorizing. (Note that ZMODEM | performance with dedicated systems, ie when at least one end is a PC, is not | necessarily indicative of what will happen when both ends are multiuser | timesharing systems.) As I've said, I have my doubts that ZMODEM will be | all that big an improvement, but I'm just theorizing myself... +--------------- It seems to be an improvement, but that's subjective. I'll make some timing tests between a Telebit UUCP connection and my mini-comm program with Zmodem. (Please don't ask me for it, it's EXTREMELY unfinished but Zmodem makes it useful for me even as it is.) --except that the modem on one end of the connection will be a T1000, thus no 19.2 link from computer to modem and no compression. But for e.g. news, compression won't buy you anything anyway. ++Brandon -- Brandon S. Allbery, moderator of comp.sources.misc allbery@NCoast.ORG uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu bsa@telotech.uucp 161-7070 (MCI), ALLBERY (Delphi), B.ALLBERY (GEnie), comp-sources-misc@backbone [comp.sources.misc-related mail should go ONLY to comp-sources-misc@<backbone>] *Third party vote-collection service: send mail to allbery@uunet.uu.net (ONLY)*
caf@omen.UUCP (Chuck Forsberg) (10/15/89)
In article <1042@faatcrl.UUCP> jimb@faatcrl.UUCP (Jim Burwell) writes: :caf@omen.UUCP (Chuck Forsberg) writes: : : :>Perhaps this has changed in newer models, but the TrailBlazers I have :>turn the line around when spoofing UUCP. : :Do you have uucp spoofing mode turned on ? On a Telebit T2500, you would :set s111 to 30 for the 'g' protocol. Yes, this is with UUCP spoofing. The line turns around every 1-5 seconds (not once per UUCP packet). That's an incredible improvement over non-spoofing, but the line still turns aound. There is no evidence of a few carriers being assigned to a reverse channel.
les@chinet.chi.il.us (Leslie Mikesell) (10/18/89)
In article <713@lakart.UUCP> dg@lakart.UUCP (David Goodenough) writes: >No - I agree with Mr. Matthews. Look at communications in general: >Xmodem, Kermit, Zmodem, Punter Protocol - all do the same basic >function: get a file from one system to another. But which one you >use depends on several things [...] [ ..adding protocols..] >The advantage of this is that it keeps compatibility: instead of saying: > >Ptg > >you just say: > >PtgXzqsplat > >and the master gets to chose. Likewise it would keep compatibility to say Ptgn (where "n" is the new protocol I would like to see) and if "n" is accepted, then negotiate the block and window size, flow control and character set independently within the protocol. That allows each item to be set optimally without making an alphabet soup of protocols. I don't really expect to see any such thing released from a company that has a vested interest in our long distance calls, though. Les Mikesell
allbery@NCoast.ORG (Brandon S. Allbery) (10/20/89)
As quoted from <9809@chinet.chi.il.us> by les@chinet.chi.il.us (Leslie Mikesell): +--------------- | making an alphabet soup of protocols. I don't really expect | to see any such thing released from a company that has a vested | interest in our long distance calls, though. +--------------- What cave have *you* been hiding in since 1982???? ++Brandon -- Brandon S. Allbery, moderator of comp.sources.misc allbery@NCoast.ORG uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu bsa@telotech.uucp 161-7070 (MCI), ALLBERY (Delphi), B.ALLBERY (GEnie), comp-sources-misc@backbone [comp.sources.misc-related mail should go ONLY to comp-sources-misc@<backbone>] *Third party vote-collection service: send mail to allbery@uunet.uu.net (ONLY)*
dg@lakart.UUCP (David Goodenough) (10/21/89)
Going off at a slight tangent from the main thread of this subject, I do have one question about adding Xmodem / Zmodem / Kermit. uucico (as I look at it) is in one respect a two layer program: down at the bottom is the "g" (or whatever) protocol driver, that simply moves data from one end to the other. Above this is the file level, which knows about C. requests, and how to process them, understands "S file file" messages, "SY" "SN2" "CY" etc. etc. etc. Now, in a Zmodem environment, what would be done about the "bidirectionality" of the link, i.e. would uucico still use the: "S file file" ----> <---- "SY" <send data> ----> <---- "CY" convention, or would some other system be used. Same applies to Xmodem (moreso perhaps, because S requests are easy, but R requests would get to be fun under Xmodem). -- dg@lakart.UUCP - David Goodenough +---+ IHS | +-+-+ ....... !harvard!xait!lakart!dg +-+-+ | AKA: dg%lakart.uucp@xait.xerox.com +---+