Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!purdue!decwrl!decvax!ima!cfisun!lakart!dg
From: dg@lakart.UUCP (David Goodenough)
Newsgroups: comp.sys.cbm
Subject: Re: ZMODEM using REUs
Message-ID: <527@lakart.UUCP>
Date: 1 May 89 16:15:46 GMT
References: <2289.245A8619@isishq.FIDONET.ORG>
Organization: Lakart Corporation, Newton, MA
Lines: 30

From article <2289.245A8619@isishq.FIDONET.ORG>, by izot@f171.n221.z1.FIDONET.ORG (Geoffrey Welsh):
> 
>  > From: dg@lakart.UUCP (David Goodenough)
>  > Message-ID: <514@lakart.UUCP>
>  
>  > If you read the ZMODEM documentation, overlapping disk access and serial
>  > I/O is not required for ZMODEM, it just makes it go faster.
>  
>    Irrelevant. Streaming (which requires simultaneous modem & disk I/O) is 
> ZMODEM's performance edge. Without it, ZMODEM offers no performance advantage 
> over YMODEM.

Not strictly true. _CONTINUOUS_ streaming requires overlapping disk
I/O and serial I/O. But suppose you're working (as I do in QTERM) with
8K reads and writes at a time. In Ymodem, over a packet switch network
(i.e. PC-Pursuit) you can take as much as 6 - 7 seconds per K at
2400BPS: 4 to send the data, and 3 to wait for the ACK to come back.
So a 16K file takes 96 seconds, plus disk access time. Now with Zmodem,
you _CAN_ acheive 4 seconds per packet, and lose three to six seconds
per 8K for holding up, and writing. So you now get the file down in 70
to 75 seconds, i.e. about a 25% improvement.

In effect I could keep up the streaming for 30 seconds at a time, and
then go off & do some disk access, because anyone can stream while
they're not talking to the disk. Of course, if you write each sector
to disk as it arrives, all bets are off (but that's much harder on the
system in general, and takes longer - hence my choice of 8K buffers).

BTW these are real figures: I've received stuff using Ymodem over PC-P
and it is sloooooooowwwwwww.