SPACE 1/SPACE - Library 1 - Volume 1.iso/utilitys/93/ppaccell/pcpaccel.doc

ST Writer Document | 1987-10-12 | 5.4 KB | 99 lines

Do Run Run STWRITER.PRG
Accellerating Xmodem Page @
ACCELLERATING XMODEM TRANSFERS USING TIMED DELAYS
     by Thomas Zerucha / 24075 Lee Baker / Southfield, MI 48075
The problem:
     Telenet will not send a packet unless one of two things occurs:
     1. 128 characters fill a complete packet
     2. A programmable timeout occurs, normally 1/10th of a second
        (this is set as 1/20th of a second multiplied by parameter
          4, as in @SET 4:2<cr> is .1 sec, 4:3 is .15, 4:4 is .2 etc.).
     When transmitting Xmodem packets, the data will collect at your
     end until 128 characters have been sent, and then be sent over the
     network, and be sent (starting from the first character) out at the
     far end.  Note that the first character goes out at the far end
     AFTER the 128th character is sent (and usually later, since Telenet
     is not instantaneous).  This 128 character delay is over 1 sec at
     1200 baud, and 4-1/4 seconds at 300 baud.
     Fortunately, there is a way to speed things up a little by taking
     advantage of the second transmit condition.
     WARNING: this method increases the number of packets sent.  Under
     non-flat-rate conditions you are more likely to exceed your kilo-
     packet limit and that may prove costly.  This is intended for
     normal (evening and weekend) PC Pursuit hours.
A Partial Solution:
     What would happen if we added a .1 second delay in the middle of
     the block?  The packet would be sent half sooner.  So if we can
     set up delays so that data would always be at the far end, and
     the first packet would be sent as soon as possible, we would speed
     up Xmodem transferrs quite a bit.  We have to be careful about
     packing, as the following diagram shows:
     Transmitter:
     TTTTTTTTTTTT---TTTTTTTTTTTT---.................*TTTTTTT->
     Receiver:
               RRRRRRRRRRRR---RRRRRRRRRRRR*---
     * ack     '---' timeout delay
     Note that there is a delay in the receiver, not good if we want
     peak performance.  The best way to fix this is to use shrinking
     packets, the last packet being between 1 and 2 times the delay
     time in length, i.e. a number of characters that would take
     between .1 and .2 seconds to send, and then lengthening each
     packet until the full XModem packet length is contained.  This
     impacts the number of characters in the first packet - in the
     last packet, it can be 4-7 characters and qualify.  But 4+8+...
     adds to either 112 or 144.  Making the first packet too short
     wouldn't speed things up as much as making everything perfect.
     so we have to add characters to each packet:
          112 =  28  24  20  16  12   8   4
          +3 on each
          133 =  31  27  23  19  15  11   7
     note that they still decrease by exactly 4.  If checksum is used
     and 132 characters (which don't add exactly), any subpacket or group
     of successive subpackets can be shortened by one, i.e for 130 chars
          130 =  30  26  22  19  15  11   7
     This will cause the following:
     TTTTTTTTTTTT---ttttttttt---TTTTTT---ttt---........*
               RRRRRRRRRRRRrrrrrrrrrRRRRRRrrr*---
     Values which work for 1200 Baud (the above is for 300) are
          133 = 52 39 27 15
     This works because each group fits within it's previous subpacket.
     Whatever delays inherent in the network will remain, however, there
     will be a savings of .63 sec/Xmodem block @ 1200 Baud, and 2.2 sec
     at 300 Baud.  This will not apply if Telenet is constantly changing
     it's load, but this is rare in the off hours.  Graphically:
     TTTTTTTTTTTT---ttttttttt---TTTTTT---ttt---........*
                 ppp        pppppp   p
                 RRRRRRRRRRRR...rrrrrrrrrRRRRRRrrr*---
     p is the time it takes Telenet to send a packet
     But with a constant delay using accelleration:
     TTTTTTTTTTTT---ttttttttt---TTTTTT---ttt---.............*
                 ppp        ppp      ppp   ppp         ppp
                 RRRRRRRRRRRRrrrrrrrrrRRRRRRrrr*---
     The normal way:
     TTTTTTTTTTTTtttttttttTTTTTTttt---....................................*
                         ppp ppp                      ppp
                         RRRRRRRRRRRRrrrrrrrrrRRRRRRrrr*---
Notes:
     This technique is effective at accelerating any subpacket that can
     be broken so that the largest packet is less than 128 characters
     (minus .1 sec worth of characters - 116 for 1200 baud, or 124 for
     300 baud).  So this will not help Ymodem (1k) packets, but will help
     256 byte packets.  Also remember to add characters up to the maximum
     length of .2 seconds, with many splits this can be significant.
     (3 chars/block at 300 baud, 11 c/blk at 1200).  At 1200 Baud:
          133 = 52 39 27 15     <= optimal
                 5  5  5 -15
          133 = 57 44 32
     Note that both of these hold the property we are looking for, but
     the first is 5 characters (.4 sec) longer for the first packet.
     If the first number would be greater than 128, then the method
     would not help significantly (since the delay would be 0 for the
     129th character, but .1 sec otherwise).
     If we try to divide finer, we end up with packets smaller than the
     delay, or bigger than the previous packet + delay:
          133 = 48 36 24 12 13
                 1  1  1  1 -4
          133 = 49 37 25 13  9
                 3  2  2  2 -9
          133 = 52 39 27 15     <= optimal