🚀 go-pugleaf

In article <8e940B5w165w@linear.mv.com> linear@linear.mv.com (Robert Henney) writes:

>One thing I wouldn't mind knowing is why on other systems when I connect
>at 14.4k/V.42BIS/LAP-M, file transfers of precompressed (ie.ZIP) go at
>around 1700cps, yet the same connection (14.4k/V.42BIS/LAP-M) using
>UUCICO.EXE results in an average of 600cps.  Error correction is not
>having any (or very little) effect on tranfers under a normal terminal
>program.  Why should they be so greatly affected under UUCICO.EXE.

First, I'm assuming that when you're not using UUCICO (ie. when you're calling
a BBS), you're downloading with Zmodem or Ymodem-G.

One of the major differences between these protocols is that the standard 'g'
protocol has a maximum block size of 64 bytes, and it must _wait_ for the
acknowledgement after each block is sent (much like Xmodem, except that
Xmodem (obviously) has 128 byte blocks).  With Zmodem or Ymodem-G, the block
size (obviously) is 1024 bytes, and (I believe) Zmodem doesn't have to wait
for acknowledgement after each block (I'm not positive about this, however).

The only way to speed up the 'g' protocol is to find a host who can support
non-standard 'g' protocol block sizes (ie. who can support block sizes other
than the standard 64 byte ones).

--
  =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  |  Christian Henry...           |  e-mail: henryc@io.org              |
  |       ...North York, Ontario  |      or: henryc@reality.mtlnet.org  |
  =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=