Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 16 Oct 1997 15:02:34 PDT
From:      Bill Fenner <fenner@parc.xerox.com>
To:        Nate Williams <nate@mt.sri.com>
Cc:        Garrett Wollman <wollman@khavrinen.lcs.mit.edu>, Donald Burr <dburr@poboxes.com>, ports@freebsd.org
Subject:   Re: 8 days until 2.2.5... Administrative notices. 
Message-ID:  <97Oct16.150242pdt.177487@crevenia.parc.xerox.com>
In-Reply-To: Your message of "Wed, 15 Oct 97 09:03:58 PDT." <199710151603.KAA11877@rocky.mt.sri.com> 

next in thread | previous in thread | raw e-mail | index | archive | help
Ok, I just modified fetch to keep a moving average of throughput over
the last 25 seconds, and print KB/s and time remaining, and fetched a
file from ftp.freebsd.org .  Maybe the moving average has to be over
a longer interval, but I certainly wasn't happy with the output I got:

Receiving X331lk98.tgz (4602996 bytes):  2% (2.5KBps) 29.4m remain
Receiving X331lk98.tgz (4602996 bytes):  6% (8.9KBps) 8.1m remain
Receiving X331lk98.tgz (4602996 bytes): 12% (18.7KBps) 3.6m remain
Receiving X331lk98.tgz (4602996 bytes): 19% (27.1KBps) 2.3m remain
Receiving X331lk98.tgz (4602996 bytes): 24% (31.6KBps) 1.8m remain
Receiving X331lk98.tgz (4602996 bytes): 31% (37.2KBps) 85s remain
Receiving X331lk98.tgz (4602996 bytes): 36% (39.0KBps) 74s remain
Receiving X331lk98.tgz (4602996 bytes): 42% (40.7KBps) 65s remain
Receiving X331lk98.tgz (4602996 bytes): 48% (42.3KBps) 56s remain
Receiving X331lk98.tgz (4602996 bytes): 54% (45.3KBps) 46s remain
Receiving X331lk98.tgz (4602996 bytes): 56% (36.0KBps) 55s remain
Receiving X331lk98.tgz (4602996 bytes): 58% (17.7KBps) 1.8m remain
Receiving X331lk98.tgz (4602996 bytes): 60% (15.7KBps) 1.9m remain
Receiving X331lk98.tgz (4602996 bytes): 65% (14.8KBps) 1.8m remain
Receiving X331lk98.tgz (4602996 bytes): 65% (9.9KBps) 2.6m remain
Receiving X331lk98.tgz (4602996 bytes): 71% (18.0KBps) 73s remain
Receiving X331lk98.tgz (4602996 bytes): 71% (4.0KBps) 5.5m remain
Receiving X331lk98.tgz (4602996 bytes): 78% (14.7KBps) 68s remain
Receiving X331lk98.tgz (4602996 bytes): 82% (19.7KBps) 40s remain
Receiving X331lk98.tgz (4602996 bytes): 85% (20.3KBps) 33s remain
Receiving X331lk98.tgz (4602996 bytes): 86% (9.1KBps) 69s remain
Receiving X331lk98.tgz (4602996 bytes): 92% (19.1KBps) 17s remain
Receiving X331lk98.tgz (4602996 bytes): 96% (20.4KBps) 7s remain
Receiving X331lk98.tgz (4602996 bytes): 99% (15.2KBps) 2s remain
Receiving X331lk98.tgz (4602996 bytes): 100%

4602996 bytes transfered in 232.7 seconds  (19.32 Kbytes/s)

(I replaced the \r's with \n's to make it clear; the user still only
sees the one line repeating over and over).

TCP's normal behavior is to find a steady state, and transfer at
that rate until a packet gets dropped, and then try to discover
the new steady state.  The recovery from dropping a packet can
take a while, and during said recovery throughput drops into
the toilet.  After recovering, throughput goes back to (somewhere
near) where it was.  So, when it said that 5.5 minutes remained,
it was actually only about 1.5 minutes, and it was fooled into saying
5.5 because it was busy recovering from a loss.

Maybe I'll try playing with the length of the moving average, but
I have to say I'm not in love with it as it is.  And, since it's
a naive implementation, it will leave the last throughput number
on your screen (and the last time estimate) if the network goes
away; you could turn off your modem and still appear to be getting
2KBps...

  Bill



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?97Oct16.150242pdt.177487>