General list for discussing Bufferbloat
 help / color / mirror / Atom feed
From: xnor <xnoreq@gmail.com>
To: "bloat@lists.bufferbloat.net" <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] Inaccurate rates with HTB/HFSC+fq_codel on router due to VLAN?
Date: Fri, 17 Mar 2017 19:15:25 +0000	[thread overview]
Message-ID: <emef0be563-edd0-4bfd-850b-f61f47d79236@gaming> (raw)
In-Reply-To: <57A046A6-C0F2-4209-93E5-CA728F4C64EE@gmx.de>

Hey,

please reply to the list address so that everyone can see it.


>  Just a guess, but I believe /sys/class/net/eth0.2/statistics/rx_bytes 
>shows the data before HTB/HFSC had a chance to touch the packets.
Of course. So? HTB/HFSC don't shrink packages, and since I'm only doing 
TCP and also use fq_codel it should shape ingress quite nicely to my 
configured rate.

>  it would be interesting to repeat the tests but run tcpdump on the 
>interface that delivers the traffic to the test machine on the internal 
>LAN. My prediction is that on that port you will pretty much see the 
>18000Kbps you expect.
The LAN is connected through eth0.1 which is part of a bridge interface 
br-lan (this bridge is the only other interface with an IP address 
besides eth0.2).

With 160 download connections I've just measured (also included the 
average bytes per packet, short bpp):

eth0.2: 20.3 Mbps download (~1400 bpp)
eth0: 21.6 Mbps download (~800 bpp), 19 Mbps upload (~780 bpp)
eth0.1: 18 Mbps upload (~1490 bpp)
br-lan: 18 Mbps upload (~1490 bpp)

(all numbers approx. accurate to about +/- 0.1 Mbps)

This is completely saturating the 20 Mbps link and ruins performance.

I've tested to decrease the rate to make it work in the above scenario: 
I had to back off with the rate to about 14 Mbps (!) because then, as 
you can guess, measured eth0.2 bandwidth drops to below the 20 Mbps link 
speed.

With less connections the measured eth0.2 bandwidth is closer to the 
configured 18 Mbps and so works fine..


>  This seems old, if your router is supported you might want to try lede 
>(https://lede-project.org/releases/17.01/start#), then you could also 
>use the cake qdisc which has a few new tricks up its sleeve, nicer than 
>HTB and HFSC...
I am planning to upgrade, but I highly doubt it'll help and it also 
doesn't help me clear up the confusion with what is going on here.


It's definitely shaping something. The question is: what?


  parent reply	other threads:[~2017-03-17 19:15 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-16 22:14 xnor
     [not found] ` <57A046A6-C0F2-4209-93E5-CA728F4C64EE@gmx.de>
2017-03-17 19:15   ` xnor [this message]
2017-03-17 19:22     ` Jonathan Morton
2017-03-17 20:11     ` Sebastian Moeller
2017-03-17 21:15 ` Eric Dumazet
2017-03-18 15:34   ` xnor
2017-03-18 15:46     ` Jonathan Morton
2017-03-24 18:18       ` xnor
2017-03-25  0:10         ` Jonathan Morton

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=emef0be563-edd0-4bfd-850b-f61f47d79236@gaming \
    --to=xnoreq@gmail.com \
    --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