Re: Measuring bandwidth

Alan Cox <alan@lxorguk.ukuu.org.uk> Mon, 06 May 2002 15:09 UTC

Subject: Re: Measuring bandwidth
To: ovishnepolsky@doubleclick.net (Vishnepolsky, Oleg)
Date: Mon, 6 May 2002 16:09:20 +0100 (BST)
Cc: tcp-impl@grc.nasa.gov
In-Reply-To: <03E81ABDC8C2D31192C9009027D5B86E08ADB87E@NYC-EX03> from "Vishnepolsky, Oleg" at May 06, 2002 09:11:26 AM
X-Mailer: ELM [version 2.5 PL6]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <E174k76-0005PE-00@the-village.bc.nu>
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
Sender: owner-tcp-impl@grc.nasa.gov
Precedence: bulk
Status: RO
Content-Length: 743
Lines: 15

> interactivity. In request-response protocols, such as HTTP, there is not a
> lot of opportunity to measure bandwidth and latency on the responder side.

Also a large number of users access via caches which totally crap on the
goal in the first place.

> Has anyone tackled these issues, say, with web servers ? Surely this is a
> very practical matter. If you serve images, you want to server "nicer"
> versions to folks with higher bandwidth. 

It can be done for some things - notably streaming video/audio where you get
enough history. Even back to 1994 or so there was a lovely italian streaming
gif setup that used the actual throughput (viewed from userspace by the
getsockopt() calls and write returns) to change the data rates.

Alan

Measuring bandwidth Vishnepolsky, Oleg
Re: Measuring bandwidth Alan Cox
Re: Measuring bandwidth Bogdan Ghita
Re: Measuring bandwidth Fred Baker