>From: "Simon Byrnand" <simon@igrin.co.nz>
> This is a good example of the not-so-obvious limitations of 128Kbit
upstream.
>
> Assuming that the 128Kbit limit is here to stay for the forseeable
> future the only choice is to do QoS on on the upstream traffic and
> give prioritization to acks, and for good measure do something like
> sfq as well to avoid any one stream from hogging the available bandwidth.

I don't think giving outgoing ACKs priority will help much.

A web browser usually opens 4 sockets to a web server and sends multiple
HTTP requests to download all the components of a web page. Often these
components are from other web sites so more three way hand shakes and HTTP
requests are required to download the page.

An HTTP request will usually be 100 .. 200 bytes, the response may be a
small component of the web page (e.g. a 200 to 500 byte GIF image). So you
have sent 200 bytes to get 200 bytes back. Under this scenario the maximum
download speed for some web pages may be not much more than your upload
speed.

If an outgoing email starts competing with the outgoing HTTP requests
everything will grind to a halt. Rather than giving ACKs priority I would
give outgoing HTTP requests the priority.

Amazing isn't it, we are now confronted with an Internet topology in NZ that
is barely usable. The "headline" speeds are bullshit, in reality a 2mbit UBS
connect probably performs at the same speed as a 256k UBS connection under
"average business" conditions due to the fact that the bottleneck is in the
128k upload path. Combine this with a minumum Round Trip Time increase from
40ms (Jetstream) to 80ms (UBS) and you can see why business users are
complaining.

Cheers

BG

-- 
This message is part of the NZ ADSL mailing list. 
see http://unixathome.org/adsl/ for archives, FAQ, 
and various documents. 
To unsubscribe: send mail to majordomo@lists.unixathome.org 
with "unsubscribe adsl" in the body of the message