* [Bloat] Network latency experiments
@ 2011-02-21 23:27 Dan Siemon
2011-02-22 9:26 ` Florian Lohoff
0 siblings, 1 reply; 3+ messages in thread
From: Dan Siemon @ 2011-02-21 23:27 UTC (permalink / raw)
To: bloat
[-- 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 --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Bloat] Network latency experiments
2011-02-21 23:27 [Bloat] Network latency experiments Dan Siemon
@ 2011-02-22 9:26 ` Florian Lohoff
2011-02-25 20:47 ` Jesper Dangaard Brouer
0 siblings, 1 reply; 3+ messages in thread
From: Florian Lohoff @ 2011-02-22 9:26 UTC (permalink / raw)
To: Dan Siemon; +Cc: bloat
[-- 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 --]
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2011-02-25 20:47 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-02-21 23:27 [Bloat] Network latency experiments Dan Siemon
2011-02-22 9:26 ` Florian Lohoff
2011-02-25 20:47 ` Jesper Dangaard Brouer
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox