home *** CD-ROM | disk | FTP | other *** search
- Xref: sparky comp.dcom.modems:13094 comp.unix.sysv386:14159 comp.protocols.misc:672 biz.comp.telebit:906
- Path: sparky!uunet!sun-barr!olivea!xenitec!zswamp!geoff
- From: geoff@zswamp.UUCP (Geoffrey Welsh)
- Newsgroups: comp.dcom.modems,comp.unix.sysv386,comp.protocols.misc,biz.comp.telebit
- Subject: Re: uucico w/v32bis vs zmodem w/v32bis
- Message-ID: <3aVqqB6w165w@zswamp.UUCP>
- Date: 7 Sep 92 18:45:49 GMT
- References: <1992Sep06.232941.7956@ksmith.uucp>
- Organization: Izot's Swamp
- Lines: 27
-
- keith@ksmith.uucp (Keith Smith) writes:
-
- > In article <Bu40L8.47w@gator.rn.com> larry@gator.rn.com (Larry Snyder) writes
- > >regular zmodem doesn't do so how with todays high speed modems with
- > >DTE speeds > 38400. For example, with my TurboPEP modems, zmodem maxes
- > >out at around 2100 cps while ymodem-g can exceed that. What we need is
- > >a large packet zmodem (like Wazoo -- from Fidonet) with 8K packets to
- > >take advantage of todays modems and 115200 baud DTE speeds
- >
- > Couldn't almost the same thing be accomplished by increasing the window
- > size to a very large number?
-
- ZMODEM operates in streaming mode... essentially it already has a window of
- infinite size.
-
- > Doesn't Zmodem allow for 1K packets?
-
- That's what Larry was talking about: increasing subpacket size (the size of
- blocks, which are used only for error correction) to reduce the ratio of
- framing and checsum overhead to real data bytes. However, I am certain that
- the framing overhead is small compared to the dozen or more bytes that are
- circumvented by multibyte escape sequences.
-
- Geoffrey Welsh, 7 Strath Humber Court, Islington, Ontario, M9A 4C8 Canada
- geoff@zswamp.uucp, [xenitec.on.ca|m2xenix.psg.com]!zswamp!geoff (416)258-8467
- Coincidentally, most people who fight for "fairness" would be
- significantly better off under the system they call "fair"...
-