Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!m.cs.uiuc.edu!vela!rdthomps
From: rdthomps@vela.acs.oakland.edu (Robert D. Thompson)
Newsgroups: comp.dcom.modems
Subject: Re: zmodem vs kermit
Message-ID: <6989@vela.acs.oakland.edu>
Date: 10 Jun 91 21:43:09 GMT
References: <9106080216.AA26357@Kodak.COM> <1991Jun9.011029.9635@hou.amoco.com>
Organization: Oakland University, Rochester MI.
Lines: 44

In article <1991Jun9.011029.9635@hou.amoco.com> zjdg11@hou.amoco.com (Jim Graham) writes:
>In article <9106080216.AA26357@Kodak.COM> ctchou@Kodak.COM writes:
>[....]
>> recently I found out that changing the kermit's packet
>> length from the default value (80) to 1000 increased the transfer rate by a
>> factor of 5 or so. 
>
>true...assuming the line conditions are good.  the reason you see an increased
>throughput is the simple fact that you are sending a lot less overhead per
>a given amount of real data.  if, on the other hand, the line was really bad,
>suddenly you waste a lot of time every time you have to retransmit an errored
>packet.  somewhere in between is a good compromise, which Zmodem tries to
>find.

	[ and the discussion goes on... ]
>
>   --jim
>
>Standard disclaimer....These thoughts are mine, not my employer's, and I'm
>on my time...not my employer's.
>
Thanks for the post Jim!!!

Now,

	You would be doing me a very big favor if you could 
	discuss these implications for high-speed transfers, say
	on 9600/V32.bis.

	You may remember a few days back the postings about
	YMODEM Batch.

	From what I gathered, YMODEM Batch (or is it G) provides
	a streaming protocol...which I guess is sending without waiting
	for an acknowledge.

	Please elaborate (your posting above was very informative,
	thanks!).

	Regards |(8>
---
Robert
rdthomps@vela.acs.oakland.edu