Path: utzoo!attcan!uunet!zephyr.ens.tek.com!tektronix!nosun!qiclab!m2xenix!news
From: news@m2xenix.psg.com (Randy Bush)
Newsgroups: comp.dcom.modems
Subject: Re: Can we back up a sec?
Message-ID: <1990Oct25.033248.28581@m2xenix.psg.com>
Date: 25 Oct 90 03:32:48 GMT
References: <1288.27204357@zswamp.fidonet.org>
Organization: Pacific Systems Group, Portland Oregon US
Lines: 26

root@zswamp.fidonet.org (Geoffrey Welsh) writes:

> The question at hand is whether the full-duplex nature of V.32 extends this
> situation to 9600 bps.  I know that the data packets need not be interrupted
> to send ACKs, but even a 7-packet window would take less than half a second
> to transmit at 9600 bps; it's entirely possible that the ACK packets might
> not arrive before the pending window reaches its limit, causing the
> transmitter to pause.  This, of course, would prevent you from getting the
> maximum theoretically possible throughput (1100-1200 CPS on V.32, using
> synchronous framing a la MNP3 or V.42).

I use V.32 and PEP for many connects a day.  I normally use a T2500, but have
also used Intel's new 9600EX (damn nice modem, and damn inexpensive, BTW).  A
local V.32 connect is as fast as PEP.  A long distance V.32 connect is
significantly slower.  I.e., local V.32 gets over 1,000 cps, while a looong
distance one (i.e., Oregon to Africa) gets 550 cps.

What I want is a Xenix uucico with a bigger window, say 20 or 30.

If you are dealing with a *lot* of mail as I do, O(10^2) messages per session,
then a nice trick such as batched and compressed mail using fake BSMTP is the
biggest win.  Uucp-g's inter-file delays are absolutely disgusting, PEP, V.32,
or whatever.

-- 
..!{uunet,qiclab,intelhf}!m2xenix!news