From: GitHub <noreply@github.com>
To: cerowrt-commits@lists.bufferbloat.net
Subject: [dtaht/ceropackages-3.3] b142be: Added babelm branch which contains a new smoothed ...
Date: Sun, 08 Jul 2012 11:24:47 -0700 [thread overview]
Message-ID: <4ff9d06f2f38c_39ff1082af4104881@sh2.rs.github.com.mail> (raw)
[-- Attachment #1: Type: text/plain, Size: 2154 bytes --]
Branch: refs/heads/master
Home: https://github.com/dtaht/ceropackages-3.3
Commit: b142be5189554e29f3a93f6ff36674aa57315260
https://github.com/dtaht/ceropackages-3.3/commit/b142be5189554e29f3a93f6ff36674aa57315260
Author: Dave Taht <dave.taht@bufferbloat.net>
Date: 2012-07-08 (Sun, 08 Jul 2012)
Changed paths:
A net/babelm/Makefile
A net/babelm/files/babeld.conf
A net/babelm/files/babeld.config
A net/babelm/files/babeld.init
A net/babelm/patches/0001-Mark-packets-as-ECN-capable.patch
R net/babelz/Makefile
R net/babelz/files/babeld.conf
R net/babelz/files/babeld.config
R net/babelz/files/babeld.init
R net/babelz/patches/0001-Mark-packets-as-ECN-capable.patch
Log Message:
-----------
Added babelm branch which contains a new smoothed metric algo
I note that this experimental package also contains a patch
to mark babel packets as ECN capable, when in reality they
are not, at present.
In the words of Juliusz:
"that's a horrible kludge. You're applying AQM to locally-originated data in
order to compensate for the lack of backpressure, and then falsely
asserting ECN in order to bypass the AQM policy."
As for the first statement, queues are necessary at multiple layers
in the stack, so I can think of no effective means of supplying
backpressure at insertion time that will work. I can think of means of
supplying congestion related drop indications to babel, but that is as
yet, unimplemented.
As to the second objection, yes this is bypassing AQM policy, however,
at some point, using ECN marking in babel could be used for something.
The udp markings can be easily obtained with pktinfo in userspace,
and I do need to produce a patch for that.
In the interim, the problem I am trying to solve is that when a rate
change happens in wifi, it is abrupt and can take a long time (with
the fq_codel aqm rapidly ramping up packet drop) to drop the backlog back to
a normal level for the new rate. IMHO it is better to have a radio
continue to function rather that potentially stop entirely because it
dropped a bunch of babel packets while seeking a new equilibrium.
reply other threads:[~2012-07-08 18:24 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4ff9d06f2f38c_39ff1082af4104881@sh2.rs.github.com.mail \
--to=noreply@github.com \
--cc=cerowrt-commits@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