From: fadden@uts.amdahl.com (Andy McFadden)
Newsgroups: comp.sys.apple2
Subject: Max throughput with ProTERM 3.0
Date: 23 Jul 92 20:58:24 GMT
Reply-To: fadden@amdahl.uts.amdahl.com (Andy McFadden)
Organization: Amdahl Corporation, Sunnyvale CA

(this is Brendan's response to my article; some other stuff follows)

----- forwarded message -----
From: Brendan_Hoar@notes.pw.com
Date: Thu, 23 Jul 92 09:50:52 PDT
To: fadden@uts.amdahl.com

I replied to this via globalnet/proline, but since it'll take a while to 
reach you I figured I'd mail it from work instead...

>I've been playing with a v.32bis/v.42bis connection for the past couple
>of days (that's 14.4Kbps with compression) and ProTERM 3.0, and it seems that
>the maximum possible throughput is around 2700 chars per second.

What?  Ick.  With a 10MHz/64ksplit Zip and a RF 2.0 with a Quantum 105 drive, 
I've gotten over 4000cps downloading a very compressible file from the Hayes 
toll free BBS/test system.  I had PT3 set to hardware flow control (using the 
Okidata 9600 RTS/CTS driver with an init string appropriate for my ZyXEL 
modem) and 57600bps with Greg's macro.  I wish I had written down the 
numbers...I'll try it again tonight after I get back from a meeting if I have 
time...

>Basically I've got the port set at 38.4 and am downloading a file containing
>200,000 asterisks from a UNIX host using Ymodem-G (Zmodem gave similar

Oh...a UNIX host.  That changes everything...were *sh, login and sz/sb/sx the 
only processes running?  If not, other processes may have been stealing 
enough cycles away from sz or the kernel (which controls serial I/O) to slow 
down the transfer.  What kind of serial board were you using in the host?  
Was it through a terminal server (unlikely since they usually aren't set up 
for 57600 bps use!).


>results, so don't tell me to go do that).  As far as I can tell, ProTERM
>does something like:
>
>    accept data until the recv buffer is full
>    drop RTS
>    wait for a bit to make sure nothing has come through while we were busy
>        setting the pot
I dunno about that part.  We'd have to ask Greg what it is doing while it is
waiting...

>    write the stuff to disk
>    raise RTS
Otherwise, everything else looks like it does the right thing...

>
>The halt to write data was about 1.5 - 2 seconds, happening once every 64K.
>Writing to /ram5 had about the same results as writing to my RamFAST.
>
>It's possible that the compression isn't squashing stuff as small as 
possible,
>but sending /usr/dict/words was accomplished in one run at 2698 cps -- almost
>exactly what the asterisks file got.  Even if you add a bit for Ymodem
>overhead, it's nowhere near the theoretical max (3840 cps).
>
>I'm not entirely sure what to make of it.  I know that having bursts for file
>updates (and there were at least four of them during the transfer) is going
>to affect the overall rate.  However, the "rd" light wasn't fully on except
>for the first few seconds right after RTS was raised, so perhaps it's a mix
>of a non-optimal compression dictionary with the lack of asynchronous I/O.

What modems were you using?  Do they begin with 'S'?

>
>So I dunno.  But if you've gone significantly beyond 2700cps (that's about
>158K per minute), I'd be interested in hearing what you did.  It does make
>me wonder whether the 57.6K fix for ProTERM has any value other than for a
>null modem cable.

Well, the answer is yes...if you like test files... :)
(Or are planning on getting a V.FAST modem when they come out...)

>--
>fadden@uts.amdahl.com (Andy McFadden)
>[ Above opinions are mine, Amdahl has nothing to do >with them, etc, etc. ]

badbunny@gnh-starport.cts.com
----- end forwarded message -----


The Unknown User also suggested doing a "MEM 9058,255" to change the
high-water mark for the receive buffer.  I'll try the 57.6K mod and this
one and see what difference it makes.

-- 
fadden@uts.amdahl.com (Andy McFadden)
[ Above opinions are mine, Amdahl has nothing to do with them, etc, etc. ]