From: Florian Lohoff <f@zz.de>
To: Dan Siemon <dan@coverfire.com>
Cc: bloat@lists.bufferbloat.net
Subject: Re: [Bloat] Network latency experiments
Date: Tue, 22 Feb 2011 10:26:23 +0100 [thread overview]
Message-ID: <20110222092623.GA11764@pax.zz.de> (raw)
In-Reply-To: <1298330824.4443.17.camel@ganymede.coverfire.com>
[-- 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 --]
next prev parent reply other threads:[~2011-02-22 22:24 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-21 23:27 Dan Siemon
2011-02-22 9:26 ` Florian Lohoff [this message]
2011-02-25 20:47 ` Jesper Dangaard Brouer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/bloat.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110222092623.GA11764@pax.zz.de \
--to=f@zz.de \
--cc=bloat@lists.bufferbloat.net \
--cc=dan@coverfire.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox