Development issues regarding the cerowrt test router project
 help / color / mirror / Atom feed
From: Dave Taht <dave.taht@gmail.com>
To: cerowrt-devel@lists.bufferbloat.net
Subject: [Cerowrt-devel] Fixing simple_qos.sh
Date: Sun, 27 Jan 2013 04:28:47 -0800	[thread overview]
Message-ID: <CAA93jw5k095Li8sF0tCZ62dqabuFdtbWrbDOi+5F3vD8BSGzBg@mail.gmail.com> (raw)

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

A couple things:

It has long been my plan to integrate simple_qos (call it ceroshaper) into
the gui, and have a test run automatically to determine the uplink/downlink
bandwidth, and store that in upnp.

The gui interface stuff has long defeated me, as well as finding enough
servers to be the backend portion of the test. as for the latter portion, I
have got a couple linode boxes up and hope to get some more boxes from
another resource. as for the gui, I'm just hopeless there.

As for the shaper script...

One thing I notice right now is that an awful lot of stuff ends up in the
background bin for some reason.

Similar things are happening on (unshaped) wifi. There's a bug there I
think.

It's been my hope to finish cake (simple_qos poured into C and made more 32
bit cpu oriented) for a month now. I hope that will fix the background bin
thing as it does full diffserv classification - but I don't know when I'll
be done, so it would be nice to figure out what's going on.

One thing that testing (actually kathie) revealed last week is that 1024
nfq_codel flows may be excessive. 32 works pretty good, actually, and
provides a defense indirectly, against bittorrent eating your life. Why
that works is that codel works pretty good against one or a few flows in a
single bin, and 32 bins limits the amount of delay that can be injected
into the system that is unmanagable via codel. I'd been trying for "perfect
isolation" between flows, but that meant that in an extreme overload
situation with 100s of flows, and low bandwidth, delay could get out of
hand.

Heck, 16 bins might be enough. Don't know.

-- 
Dave Täht

Fixing bufferbloat with cerowrt:
http://www.teklibre.com/cerowrt/subscribe.html

[-- Attachment #2: Type: text/html, Size: 1917 bytes --]

             reply	other threads:[~2013-01-27 12:28 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-27 12:28 Dave Taht [this message]
2013-01-29 21:21 ` Sebastian Moeller
2013-01-30 12:20   ` Maciej Soltysiak
2013-01-30 12:50     ` Török Edwin
2013-01-30 19:07     ` Sebastian Moeller

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/cerowrt-devel.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAA93jw5k095Li8sF0tCZ62dqabuFdtbWrbDOi+5F3vD8BSGzBg@mail.gmail.com \
    --to=dave.taht@gmail.com \
    --cc=cerowrt-devel@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