Path: utzoo!dciem!nrcaer!scs!spl1!ddsw1!karl
From: karl@ddsw1.UUCP (Karl Denninger)
Newsgroups: comp.dcom.modems
Subject: Re: more real data for Trailblazers and Argentina
Message-ID: <1196@ddsw1.UUCP>
Date: 8 Jun 88 04:43:18 GMT
Article-I.D.: ddsw1.1196
References: <14605@uunet.UU.NET> <10127@mcdchg.UUCP>
Reply-To: karl@ddsw1.UUCP (Karl Denninger)
Organization: Macro Computer Solutions, Inc., Mundelein, IL
Lines: 44
Summary: Wall-clock time is the only one you pay for; others can be misleading.

In article <10127@mcdchg.UUCP> heiby@mcdchg.UUCP (Ron Heiby) writes:
>Rick Adams (rick@uunet.UU.NET) writes:
>
>[apparent 1/2 speed transfer on Telebit]
>
>Now, I know that there is some additional
>time used to send a short overhead file with uucp, but it really seems to
>me that there's an awful lot of think time going on between transfers.
>Although I haven't gone to the trouble of calculating it, watching the
>lights blink on my Telebit gives me the same impression.  Anyone have
>any thoughts on the matter?  It looks to me like with a reliable link,
>that bigger files are even more of a win with Telebit speeds than with
>1200 bps modems.

I also find that the actual transfer time, in bytes sent / wall clock
seconds is substantially lower than the "sending the file" time.  This seems
to be due to a couple of things:

1) The modem has a decent-sized buffer.  When you're sending a file, the
   last 10k or so is "free" in that it can be absorbed by the modem at a 
   higher rate than the phone line can transmit it.  If your files are
   short, you get *really* impressive times -- I've hit 16-17kbaud on files
   < 10k (we run a 19.2K locked line).  This also means that you see a pause
   at the end of a file while the modem "catches up" before you get back the
   "OK" confirmation from the other end....  

2) The system does do some 'crunching' between files.  For a loaded system,
   this can be very substantial.  Our machine is usually lightly loaded, and
   thus it's not significant here.  On calls to heavily-loaded hosts,
   though, you can wait for a bit.....

The big files get you more time between "2"s -- the perceived benefit from 
small files is really not there, as the timing doesn't take into account 
the buffering of the data....(unless you use wall-clock time).

This also depends on the speeds of the respective ends of the connection 
as well.  If one end is running a 9600-baud interface and the other is 
at 19.2K the faster end can easily saturate the link and cause the
hardware flow control to come into effect....  Compression, if you're
sending files which are "agreeable" to it, can make things even better.

--
Karl Denninger (ihnp4!ddsw1!karl) Data: (312) 566-8912, Voice: (312) 566-8910
Macro Computer Solutions, Inc.    "Quality solutions for work or play"