root@zswamp.uucp (Geoffrey Welsh) (06/05/91)
In a letter to All, Robert D. Thompson (rdthomps@vela.acs.oakland.edu ) wrote: >So are streaming protocols like ZMODEM and YMODEM-G better >than say Kermit when it comes to transfer performance. Streaming protocols have the advantage that their efficiencies remain high no matter what the baud rate is. Simple block-wait protocols like XMODEM and the original Kermit have a pause built in between every block; as the baud rate goes up, the time to transmit the block goes up with it, but the pause in between stays about the same. The net result is that an increasingly *smaller* fraction of the time is spend sending data and the protocol's efficiency (the number of data bytes actually transferred per second over the theoretical maximum bytes that the carrier could have transmitted) goes down as the baud rate goes up. So, while XMODEM may have a typical 75% efficiency at 2400 bps, it can drop to as little as 50% at 9600 bps. Protocols like SEAlink and 'sliding windows Kermit' try to solve this problem by sending several blocks and then waiting for the oldest to be acknowledged. "Window size" refers to the number of blocks that the transmitter will try to keep ahead of the receiver. At low baud rates, this permits the transmitter to send data almost continuously but, as the baud rate goes up, the time to transmit the window goes down but the delay before the ACK doesn't... so eack protocol has a speed beyond which its efficiency will not remain near 100%. The larger the window, the better the protocol will hold up at higher baud rates... SEAlink offers 96% efficiency at 2400 bps, but it begins to drop away at higher baud rates. That's where streaming protocols come in. YMODEM-G and ZMODEM (in its most common usage) simply start talking and continue to do so until interrupted. The sender doesn't wait for a signal from the receiver until the file is sent, so a streaming protocol can always maintain its high efficiency (as long as the sender can read the data off disk fast enough to keep up with the bit stream and the receiver can process the incoming data as fast as it comes in). Within those limitations, YMODEM-G can maintain near-99% efficiencies at all speeds, and ZMODEM (which has higher overhead in order to maintain compatibility with somewhat less friendly data paths) remains near 95% efficient (higher with Chuck's MobyTurbo extensions). There are fringe benefits as well. Half duplex (e.g. PEP, V.29, Hayes V-9600) modems take time to switch the direction of data flow and, with block-wait protocols, two reversals are required for every block, further slowing down the transfer; windowed protocols can sometimes perform slightly better. Some modems, like the Telebit Trailblazer use a technique called "spoofing" to get around this problem, but that essentially means converting block-wait and windowed protocols into streaming protocols for the physical transfer. >I know that ZMODEM is faster in general, but is it >specifically better for transfer over V.32bis Modems? What I've given above are general rules to to use when assessing what a protocol's efficiency might be at a given baud rate. V.32bis modems don't have special needs per se, except that they are the fastest dialup modems available today and therefore will display most clearly the performance difference that I talk about above. >What are the advantages and disadvantages of each protocol in >terms of high-speed transfers of pre-compressed files (like *.ZIP)? Most file transfer protocols simply transfer the data bytes verbatim, so the contents (i.e. precompressed or text) has no effect on the transfer rate. The ZMODEM specification now includes a compression option that may boost throughput on certain files, and some protocols (like the 'fad' ones being installed on BBSes) are based on compression techniques... but I like to quote figures that *don't* count on compression from either the file transfer protocol or from compression supplements to error correcting protocols (such as MNP5 or V.42bis) because most of the data transferred by people who ak such questions is precompressed and another level of compression doesn't help much. I hope that I've answered some of your questions. I also hope that Chuck Forsberg, author of ZMODEM, will also try to provide some explanations... he'll probably do a better job of it. -- Geoffrey Welsh - Operator, Izot's Swamp BBS (FidoNet 1:221/171) root@zswamp.uucp or ..uunet!watmath!xenitec!zswamp!root 602-66 Mooregate Crescent, Kitchener, ON, N2M 5E6 Canada (519)741-9553 "He who claims to know everything can't possibly know much" -me
larry@nstar.rn.com (Larry Snyder) (06/16/91)
Craig.Steven.Bell@f98.n250.z1.FidoNet.Org (Craig Steven Bell) writes: >If you use BiModem, you can expect @1775cps going in BOTH directions. using uucp or zmodem with v.32bis and v.42bis yields slightly higher transfers.. has bimodem been ported to unix? -- Larry Snyder, NSTAR Public Access Unix 219-289-0287/317-251-7391 HST/PEP/V.32/v.32bis/v.42bis regional UUCP mapping coordinator {larry@nstar.rn.com, ..!uunet!nstar.rn.com!larry}
zjdg11@hou.amoco.com (Jim Graham) (06/17/91)
In article <1991Jun16.133026.15529@nstar.rn.com> larry@nstar.rn.com (Larry Snyder) writes: >Craig.Steven.Bell@f98.n250.z1.FidoNet.Org (Craig Steven Bell) writes: >>If you use BiModem, you can expect @1775cps going in BOTH directions. >has bimodem been ported to unix? would somebody please email me the sources? I'd like to try it out, and none of the local bbs machines seem to have bimodem src, or bimodem support, for that matter. if it is better than Zmodem (etc), I can use it! thanks in advance.... --jim Standard disclaimer....These thoughts are mine, not my employer's. ------------------------------------------------------------------------------ Share and Enjoy! (Sirius Cybernetics Corporation, complaints division) 73, de n5ial Internet: zjdg11@hou.amoco.com or grahj@gagme.chi.il.us Amateur Radio: TCP/IP: jim@n5ial.ampr.org (44.72.47.193) Packet: BBS went QRT for good...still searching for new one. ------------------------------------------------------------------------------