Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!know!news.cs.indiana.edu!maytag!xenitec!zswamp!root
From: root@zswamp.fidonet.org (Geoffrey Welsh)
Newsgroups: comp.dcom.modems
Subject: Re: V.32bis and V.17 approved by CCITT
Message-ID: <7102.27F0270F@zswamp.fidonet.org>
Date: 26 Mar 91 19:41:33 GMT
Organization: Izot's Swamp BBS - Kitchener, Ontario
Lines: 59

Larry Snyder (larry@nstar.rn.com ) wrote:

LS>Now - UUCP on these modems is another story - in the HST 
LS>modem at best throughput is 350 cps, while V.32 on non
LS>v.42bis and non v.32bis connections runs around 880 cps.

GW> ... which I consider decent throughput for what is essentially a 9600 bps 
GW>modem, don't you? 

LS>Not bad - hopefully v.32bis and v.42bis will bump the 
LS>throughput up there around 1600 cps

   Not likely, for the same reason that XMODEM won't get much faster over 
V.32bis than over V.32: dead air doesn't get any faster with increased 
carrier speed.

   At 2400 bps, the UUCP-g window (7 packets, each a couple more than 64 
bytes) takes nearly two seconds to transmit.  It is not only possible but 
quite likely that the data will have arrived at the other end and an ACK for 
the first block will have been received in that two seconds, allowing the 
sender to transmit the next block and carry on continuously in that manner.

   Now let's look at a V.32bis modem.  *I know that this model is flawed in 
detail, but I believe that the principles hold and that the model is useful in 
describing why non-streaming protocols don't benefit as much from high speed 
modems*

   14,400 bps synchronous means the potential equivalent of 1800 CPS 
asynchronous, so the data in the window will be sent in about a quarter of a 
second.  I'd like to speculate on the reasons why, but let's just accept for 
the time being that the ACK simply isn't going to make it back within a 
quarter of a second.

   So... the sender shuts up until the ACK arrives.  When that ACK arrives, it 
will be followed closely by the other six, and the second window of data will 
be sent almost contiguously.  In effect, UUCP-g's seven-packet window 
degenerates at high baud rate to the point where it is comparable to a 
non-windowing protocol with 512-byte packets.

   You can make the carrier as fast as you want, you will increase the 
throughput marginally and the wasted bandwith significantly.  I like to 
describe the bandwidth vs. throughput rate for non-streaming protocols as a 
a plot of a logarithm... there is a horizontal asymptote and increasing the 
baud rate brings throughput closer to it, but you can never quite reach it.  
Of course, the actual value of the asymptote depands on the protocol and the 
system using it, so you can't give absolute figures (though that doesn't 
stop USR from quoting some in its Courier high-speed modem manual!)

   Comments from my learned correspondents?
 

--  
UUCP:     watmath!xenitec!zswamp!root | 602-66 Mooregate Crescent
Internet: root@zswamp.fidonet.org     | Kitchener, Ontario
FidoNet:  SYSOP, 1:221/171            | N2M 5E6 CANADA
Data:     (519) 742-8939              | (519) 741-9553
The mile is traversed not by a single leap, but by a procession of coherent 
steps; those who insist on making the trip in a single element will be failing 
long after you and I have discovered new worlds.        - me