Historic archive of defunct list cerowrt-users@lists.bufferbloat.net
 help / color / mirror / Atom feed
From: Dave Taht <dave.taht@gmail.com>
To: Jeremy Tourville <organ_dr@hotmail.com>
Cc: "cerowrt-users@lists.bufferbloat.net"
	<cerowrt-users@lists.bufferbloat.net>
Subject: Re: [Cerowrt-users] SQM Setup and Performance
Date: Thu, 30 Jan 2014 09:42:10 -0800	[thread overview]
Message-ID: <CAA93jw6FvH0-HRjdRsVkzCvjRC3=rTt4cu=yCMV5c_BFFs-+_w@mail.gmail.com> (raw)
In-Reply-To: <BLU175-W83264DBB20827095EB653F3AF0@phx.gbl>

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

On Thu, Jan 30, 2014 at 9:06 AM, Jeremy Tourville <organ_dr@hotmail.com>wrote:

> Hello, I followed your excellent instructions here -
>
> http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_SQM_for_CeroWrt_310
>
> I am using build 3.10.24-8
>
> I am using a DSL line rated at 6 Mbps down and 512kbps up.  My real
> throughput without SQM enabled is 5.7Mbps down and 450kbps up.
>
> After enabling SQM my throughput has dropped to approximately 4.5Mbps down
> and 350 kbps up.  Does this seem like an amount that is expected? (within
> norms?)
>

I recommend tuning, using reasonable benchmarks, like rrul.

Generally you can get pretty close to your provider's provided bandwidth,
but repeated tuning is something we try really hard to avoid. We know 85%
always works. :)

Hopefully we'll come up with a tool or approach that works dynamically one
day, but we're not there yet.

So create a setting, run a benchmark, change a knob, run the benchmark,
until you get something satisfying

example:

http://snapon.lab.bufferbloat.net/~cero2/jimreisert/results.html

notes:

At the moment nfq_codel is a mildly bigger win than fq_codel is at
bandwidths below 1mbit.

there was a change to sqm in releases after this ( I think ). It used to
allocate a fairly large
amount of bandwidth for priority traffic (64kbit I recall), now it does 12
or so.  rrul exercises all queues.

you might want to fiddle with target a little (target 20ms)


> It would seem reasonable that I should expect some performance loss at the
> expense of better bufferbloat management based on setting 85-95% of actual
> download/upload speeds.  Please correct me if I am wrong. :-)  But my
> question is, how much is too much?  The setting of SQM does fix the
> bufferbloat issue as evidenced by ping testing and times for packets.  With
> SQM on all packets were 100ms or less.  With SQM off the times jumped to
> over 500ms or more during the speed testing.
>
> For reference I have set the parameters as indicated in the screenshots.
> I have changed only two variables and tested after each change as indicated
> in the grid below.
>
>    Que setup script Per packet overhead test results  Test #1 simple.qos
> 40 no buffer, less throughput <100ms, 4.5mbps down  Test #2  simple.qos 44 no
> buffer, less throughput <100ms, 4.5mbps down  Test #3 simplest.qos 40 no
> buffer, less throughput <100ms, 4.5mbps down  Test #4 simplest.qos 44 no
> buffer, less throughput <100ms, 4.5mbps down
>
>

whether overhead of 44 or 40 is correct for your provider...


> I also read your statement-
> >>>"The CeroWrt development team has been working to nail down a
> no-brainer set of instructions for eliminating bufferbloat - the
> lag/latency that kills voice & video chat, gaming, and overall network
> responsiveness. The hard part is that optimal configuration of the Smart
> Queue Management (SQM) link is difficult - there are tons of options an ISP
> can set. Although CeroWrt can adapt to any of them, it's difficult to find
> out the exact characteristics of the link you have."
>
> What info do I need to get from my ISP to best optimize my connection?
>

Ask 'em to do their own benchmarking with cero & rrul, adopt fq_codel on
their dslams and (especially) rate-limiters, and publish their results for
each tier they sell?

>I also recognize that this could be an issue that requires multiple
changes at once.  I am curious to know from the experts what your thoughts
are on this.  Many thanks in advance!

I think you can get closer than you got.


>
> -Jeremy
>
> _______________________________________________
> Cerowrt-users mailing list
> Cerowrt-users@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-users
>
>


-- 
Dave Täht

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

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

  reply	other threads:[~2014-01-30 17:42 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-30 17:06 Jeremy Tourville
2014-01-30 17:42 ` Dave Taht [this message]
2014-01-30 19:29 ` 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

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

  git send-email \
    --in-reply-to='CAA93jw6FvH0-HRjdRsVkzCvjRC3=rTt4cu=yCMV5c_BFFs-+_w@mail.gmail.com' \
    --to=dave.taht@gmail.com \
    --cc=cerowrt-users@lists.bufferbloat.net \
    --cc=organ_dr@hotmail.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