From: Jim Gettys <jg@freedesktop.org>
To: bloat@lists.bufferbloat.net
Subject: Re: [Bloat] new network deploy
Date: Mon, 31 Jan 2011 08:55:31 -0500 [thread overview]
Message-ID: <4D46BF53.5060205@freedesktop.org> (raw)
In-Reply-To: <AANLkTi=mEsBTeWbmD6VaCX3Fg1_+J1rgoReUDLfbWo5t@mail.gmail.com>
On 01/31/2011 04:52 AM, Luca Dionisi wrote:
> Hi all
>
> I am starting to deploy a local TCP/IP network in order to test a new
> routing protocol.
> Info on the routing protocol: www.netsukuku.org
> Info on the network being deployed: pyntk.blogspot.com
> It is separated from the Internet at the moment.
>
> I ask for advices on how to make it as free as possible from the
> bufferbloat problem.
> I would also make some tests on this network and report here what I
> find out about bufferbloat.
>
> Further information:
> * every node active on the network will be a modern linux host.
> * all of the links between nodes will be on wifi or on cables owned
> by the users. That is, no VPN links over the Internet.
> * if it is needed I can list the actual chipset of ethernet cards
> and radio devices.
> * most of the wifi links will be managed by radio chipset installed
> in linux hosts (mostly ad-hoc, no strange do-it-all out-of-control
> embedded-router-bridge-repeater devices)
>
> There is also a particular case. Two linux nodes are connected via a
> VPN at layer 2 (I use tinc) over another network with static addresses
> and routing. This network is formed by the 2 linux hosts and 2
> embedded radio devices, from Ubiquity, which run AirOS, a derived of
> OpenWRT.
> In this particular case, where do I have to look for possible buffers?
> Is it enough to look the tx-queue of the virtual nic or do I have to
> check also the settings of the Ubiquity devices?
>
>
Everywhere; here are places where we know buffers hide (on some hardware
or an other).
o transmit queue
o ring buffers in the hardware
Additionally, using the OLPC wireless as an example, it also buffered:
o one packet in the device driver itself (aiding locking issues)
o four packets out in its mesh wireless module.
So I'd start by making sure I understood where buffering is in the
system, and putting some reasonable upper bound on their size.
As to solving it for real, here you have a more difficult problem. We
don't have existing algorithms that "just work" for wireless. RED won't
suffice; the situation is too dynamic, and the dynamic range of the
goodput on wireless, particularly in a mesh, is orders of magnitude, so
any static upper bound, which may be much better than nothing, will
still often be much too large.
There are two ways forward there toward real solutions.
1) is the unpublished nRED algorithm Van thinks will work. I will
continue to nag Van Jacobson about finishing his paper up.
2) the following is running code that Van came across in December.
On 01/06/2011 01:50 PM, Van Jacobson wrote:
> Jim,
>
> Here's the Doug Leith paper I mentioned. As I said on the phone I
> think there's an easier, more robust way to accomplish the same
> thing but they have running code and I don't. You can get their
> mad-wifi implementation at
> http://www.hamilton.ie/tianji_li/buffersizing.html
>
> - van
Best regards,
- Jim
next prev parent reply other threads:[~2011-01-31 14:00 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-31 9:52 Luca Dionisi
2011-01-31 13:55 ` Jim Gettys [this message]
2011-01-31 14:53 ` Dave Täht
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=4D46BF53.5060205@freedesktop.org \
--to=jg@freedesktop.org \
--cc=bloat@lists.bufferbloat.net \
/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