Conference hydra::amiga_v1

3690.0. "Zmodem downloads need ACKs for large files" by BBQ::GERAGHTY (Simon Geraghty, Sydney) Thu Apr 19 1990 00:25

    I have had continual troubles using Zmodem downloads (VAX -> Amiga) but
    I finally found a solution that works a treat, so here it is (from
    memory, so I might get something a little wrong).
    
    Problem:
    ========
    
    Zmodem downloads (VAX -> Amiga) worked Ok up to 16KB. Above that, I
    consistently got errors (Bad checksum, retries, bad escape character).
    Zmodem patiently retried until it got things right, and in 99% of cases
    I got a valid transfer. The same thing happened whether I used
    VT100v2.9 (external SZ/RZ) or VLTjr (xprzmodem). With VLTjr I was able
    to notice that the transfer rate dropped from ~220cps (@2400 baud) to
    ~170cps when it got into heavy error handling.
    
    The line was clean.
    
    Another thing I had noticed independently was that if I typed a really
    long file from DCL to the Amiga, after about 16-20 pages the text
    started dropping characters in a big way. The problem was even worse at
    1200 baud (after ~5 pages).
    
    I seem to recall my kermit transfers (VT100v2.6, Handshake) also having
    errors during large transfers.
    
    Diagnosis:
    ==========
    
    It's got to be data overruns, right?
    
    I increased my serial buffer size in preferences.
    I tried no handshaking, XON/XOFF, 7-wire, XON/XOFF+7-wire.
    I fiddled with every conceivable parameter at the DECserver 200 port
    and using SET TERMINAL.
    
    No joy.
    
    Solution:
    =========
    
    RTFM! (for SZ/RZ which came with VT100v2.9)
    
    The SZ manual says you can specify ACKs for transfers but you must
    specify the buffer and frame sizes. Without going into the long
    details, the default for SZ/RZ is a buffer of 16K (sounds familiar!)
    and no ACKs (that's how it gets to be fast). 
    
    So in VLTjr I get the external protocol options requester up, change
    the buffer size to 1 (1K), set the frame size to 1024 (1K) and because
    that's not 0 it knows to use ACKs. I already had the option set to do
    autoactivate on send. At the VAX end I specify a frame size of 1024
    	$ SZ "l" 1024 filename ...
    and bingo! the thing works, with a throughput of ~180cps. Not one
    error, for loads up to 800K.
    
    The "l" in the DCL command has to be in quotes, otherwise it's changed
    to uppercase by the VMS CLI and that means something completely
    different to SZ.
    
    So this is what I think is happening. The handshaking somewhere between
    my modem at home (through the other modem,server,VAX,decnet
    link,VAX,etc) and the SZ or TYPE executable at the VAX end is falling
    to bits (excuse the pun!). I'm assured by the systems guys at this end
    that this can't happen, but my guess is it's somewhere in the coms
    around the dial-in area.
    
    I still have the problem typing long files, but my transfers work like
    a dream. I haven't tried it with VT100v2.9 (external SZ/RZ) but my
    guess is it will work there too.
    
    regards,
    
    Simon.