Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!bionet!ames!apple!sun-barr!newstop!texsun!texbell!sugar!ficc!karl
From: karl@ficc.uu.net (karl lehenbauer)
Newsgroups: comp.dcom.modems
Subject: Re: How to speed up uucp with Telebits(only getting 800 chars/sec )
Message-ID: <5041@ficc.uu.net>
Date: 17 Jul 89 17:51:46 GMT
References: <200038@hrc.UUCP> <1160@intercon.UUCP> <9585@alice.UUCP> <60403@uunet.UU.NET>
Organization: Ferranti International Controls
Lines: 23

In article <60403@uunet.UU.NET>, rick@uunet.UU.NET (Rick Adams) writes:
> In my (quite extensive) experience, the probabilites are about 85%
> receiving system, 10% modems and 5% sending system.
 
> Typically the problem is with the receiving system. E.g. just
> because your system supports an interface speed of 19.2 kbps,
> has absolutely nothing to do with its ability to receive data
> at that speed (DEC systems are especially bad about this as are
> most PCs without "smart" IO cards)

Agreed.  The sender doesn't lose data if it's really busy, but the receiver can.
Consequently, the sender may slow down a little under load, but if the
receiver gets overruns, one'll get into the relatively lengthy retry business,
and throughput suffers dramatically.  Watch your modem lights for it --
it's pretty distinctive -- everything stops, then after a while you see a
blip on transmit, followed by a squirt from the remote.  If there
isn't another retry required right away, you're back to speed.

I could not get 19.2 kbps to work reliably on an unloaded 16 MHz 386 equipped
with a zero-wait cache and a dumb board.  It's OK with a smart one, at least
so far (load is still pretty low.)
-- 
-- uunet!ficc!karl