[Bloat] Network latency experiments

[Bloat] Network latency experiments

[Dan Siemon]

[-- Attachment #1: Type: text/plain, Size: 442 bytes --]

I spent some time over the weekend playing around with different network
configurations and collecting latency results. Hopefully this is
interesting to the people on this list.

http://www.coverfire.com/archives/2011/02/21/network-latency-experiments/

Experiments
1) Linux defaults
2) Reduce buffers
3) Reduce buffers + SFB
4) Reduce buffers + SFQ

Each was tested under upstream load, downstream load and bidirectional
load.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [Bloat] Network latency experiments

[Florian Lohoff]

[-- Attachment #1: Type: text/plain, Size: 2274 bytes --]


Hi,

On Mon, Feb 21, 2011 at 06:27:04PM -0500, Dan Siemon wrote:
> I spent some time over the weekend playing around with different network
> configurations and collecting latency results. Hopefully this is
> interesting to the people on this list.
> 
> http://www.coverfire.com/archives/2011/02/21/network-latency-experiments/
> 
> Experiments
> 1) Linux defaults
> 2) Reduce buffers
> 3) Reduce buffers + SFB
> 4) Reduce buffers + SFQ
> 
> Each was tested under upstream load, downstream load and bidirectional
> load.

Hmmm - interesting - I am playing with tc and shaping on my upstream PPP for
a while. The problem which i was fighting was that there is no real link
from the PPPoEs bandwidth to the real DSL Bandwidth as the underlying physic
is a 100MBit/s Ethernet so whatever your queue size is you push it out quite 
fast and the queue building up at some point in the DSL modem which is 
beyong the scope of tuning on the linux stack. So reducing the ethernet or
ppp tx queue should not help anything here.

I solved it with a "tc" htb with a 128kbit rate/ceil which is my upstream
speed and a short queue (in the tc).

One of the problems i see is missing backpressure due to completely unrelated
layer speeds. Id like to see DSL modems support something like ANCP to
signal current up/downstream bandwidth towards the CPE - i could then
add a rate limiter based on the current upstream bandwidth to 
not overflow the DSL modem with upstream traffic, or in case of
bufferbloat fixed DSL modems let the CPE choose packet scheduling not
the dumb FIFO based DSL modem.

Solving the DSL upstream buffer bload it possible with linux standard
mechanisms - but its not "consumer friendly" or easy to use in some
scenarios. "Open" DSL profiles are getting more and more common so your
up and downstream bandwidth may change over time which makes it impossible
to use fixed rate limiters. Solving this needs fixing the buffers in the
intermediate devices like DSL and Cable Modems and some protocol to communicate
the bandwidth to the IP layer for queue/scheduler configuration.

Flo
-- 
Florian Lohoff                                                 f@zz.de
                 Professionell gesehen bin ich zu haben ....

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: [Bloat] Network latency experiments

[Jesper Dangaard Brouer]

On Tue, 2011-02-22 at 10:26 +0100, Florian Lohoff wrote:
> I solved it with a "tc" htb with a 128kbit rate/ceil which is my
> upstream speed and a short queue (in the tc).

Please remember to used the option "linklayer adsl" plus the "overhead"
tc options when shaping on ADSL links.  Or else you will loose queue
control due to the special ADSL linklayer (ATM) overhead properties.

Detailed info available on http://www.adsl-optimizer.dk.

-- 
Best regards
  Jesper Brouer
  ComX Networks A/S
  Linux Network Kernel Developer
  Cand. Scient Datalog / MSc.CS
  Author of http://adsl-optimizer.dk
  LinkedIn: http://www.linkedin.com/in/brouer