[Cerowrt-devel] Torrents are too fast

[Cerowrt-devel] Torrents are too fast

[Dane Medic]

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

Hi,

what lines do I have to add to simple.qos script on cerowrt to slow down
bulk traffic from a specific IP address (172.30.42.6) and from a specific
port (18224)?


Thank you guys

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

Re: [Cerowrt-devel] Torrents are too fast

[dpreed]

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


In other words, rather than share the capacity of the link "fairly" among flows (as TCP would if you eliminated excess buffer-bloat), you want to impose control on an endpoint from the middle?
 
This seems counterproductive... what happens when the IP address changes, new services arise, and more ports are involved?
 
TCP and other protocols generally are responsive when packets are dropped at a congested point, and they generally end up sharing the available capacity relatively fairly.  If you want even more fairness, use fq_codel. It should do pretty much what you want without even having to identify the source addresses.


On Monday, November 3, 2014 2:53am, "Dane Medic" <dm70dm@gmail.com> said:





Hi,

what lines do I have to add to simple.qos script on cerowrt to slow down bulk traffic from a specific IP address (172.30.42.6) and from a specific port (18224)?


Thank you guys

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

[Cerowrt-devel] Torrents are too fast

[Dane Medic]

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

dpreed, thank you for response. I'm already using fq_codel with cerowrt and
I don't think it does what I want (or maybe I want too much :)

So the steps I've made:
flashed wndr3700v2 with cerowrt 3.10.50-1 then I've measured:

root@cerowrt:/usr/lib/CeroWrtScripts# sh betterspeedtest.sh -p wlan-si.net
-t 120
2014-11-20 12:18:34 Testing against netperf.bufferbloat.net (ipv4) with 5
simultaneous sessions while pinging wlan-si.net (120 seconds in each
direction)
.........................................................................................................................
 Download:  3.78 Mbps
  Latency: (in msec, 119 pings, 0.00% packet loss)
      Min: 13.077
    10pct: 251.522
   Median: 317.851
      Avg: 308.497
    90pct: 371.033
      Max: 376.132
............................................................................................................................
   Upload:  0.48 Mbps
  Latency: (in msec, 103 pings, 0.00% packet loss)
      Min: 12.278
    10pct: 12.727
   Median: 18.359
      Avg: 23.256
    90pct: 33.971
      Max: 180.303

Then I've put these commands:

uci set sqm.ge00.enabled=1
uci set sqm.ge00.download=3200
uci set sqm.ge00.qdisc=nfq_codel
uci commit sqm
reboot

And another measure:

root@cerowrt:/usr/lib/CeroWrtScripts# sh betterspeedtest.sh -p wlan-si.net
-t 120
2014-11-20 12:49:05 Testing against netperf.bufferbloat.net (ipv4) with 5
simultaneous sessions while pinging wlan-si.net (120 seconds in each
direction)
.........................................................................................................................
 Download:  2.74 Mbps
  Latency: (in msec, 121 pings, 0.00% packet loss)
      Min: 12.210
    10pct: 13.002
   Median: 15.077
      Avg: 15.095
    90pct: 16.968
      Max: 18.599
.............................................................................................................................
   Upload:  0.49 Mbps
  Latency: (in msec, 101 pings, 0.00% packet loss)
      Min: 12.255
    10pct: 12.684
   Median: 16.679
      Avg: 23.100
    90pct: 34.019
      Max: 170.173

The tests doesn't look bad, but the problem is I watch a video clip on
youtube and my sister starts torrent client, I can't watch anymore.

Cheers

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

Re: [Cerowrt-devel] Torrents are too fast

[Dave Taht]

I would be surprised if you could tolerate a *single* big download
while watching a movie, at 4mbit/512k, much less torrents, which are 6
or more.

That said, most torrent clients are configurable in several ways.

1) You can limit the number of download flows to something far less
than 6. Try 1 or 2.

2) You can typically rate limit them in the client to a lower rate
during the day and a higher rate at night.

3) You can tell them to mark the torrents as background (QoS marking
CS1), but that only helps on uploads vs the simple.qos script.

At the router itself, you can try things like identifying torrent
traffic via a consistent port number (if you have one) to toss it into
the background queue , or try qos-scripts which has a layer 7 dpi
tool.




On Thu, Nov 20, 2014 at 6:13 AM, Dane Medic <dm70dm@gmail.com> wrote:
> dpreed, thank you for response. I'm already using fq_codel with cerowrt and
> I don't think it does what I want (or maybe I want too much :)
>
> So the steps I've made:
> flashed wndr3700v2 with cerowrt 3.10.50-1 then I've measured:
>
> root@cerowrt:/usr/lib/CeroWrtScripts# sh betterspeedtest.sh -p wlan-si.net
> -t 120
> 2014-11-20 12:18:34 Testing against netperf.bufferbloat.net (ipv4) with 5
> simultaneous sessions while pinging wlan-si.net (120 seconds in each
> direction)
> .........................................................................................................................
>  Download:  3.78 Mbps
>   Latency: (in msec, 119 pings, 0.00% packet loss)
>       Min: 13.077
>     10pct: 251.522
>    Median: 317.851
>       Avg: 308.497
>     90pct: 371.033
>       Max: 376.132
> ............................................................................................................................
>    Upload:  0.48 Mbps
>   Latency: (in msec, 103 pings, 0.00% packet loss)
>       Min: 12.278
>     10pct: 12.727
>    Median: 18.359
>       Avg: 23.256
>     90pct: 33.971
>       Max: 180.303
>
> Then I've put these commands:
>
> uci set sqm.ge00.enabled=1
> uci set sqm.ge00.download=3200
> uci set sqm.ge00.qdisc=nfq_codel
> uci commit sqm
> reboot
>
> And another measure:
>
> root@cerowrt:/usr/lib/CeroWrtScripts# sh betterspeedtest.sh -p wlan-si.net
> -t 120
> 2014-11-20 12:49:05 Testing against netperf.bufferbloat.net (ipv4) with 5
> simultaneous sessions while pinging wlan-si.net (120 seconds in each
> direction)
> .........................................................................................................................
>  Download:  2.74 Mbps
>   Latency: (in msec, 121 pings, 0.00% packet loss)
>       Min: 12.210
>     10pct: 13.002
>    Median: 15.077
>       Avg: 15.095
>     90pct: 16.968
>       Max: 18.599
> .............................................................................................................................
>    Upload:  0.49 Mbps
>   Latency: (in msec, 101 pings, 0.00% packet loss)
>       Min: 12.255
>     10pct: 12.684
>    Median: 16.679
>       Avg: 23.100
>     90pct: 34.019
>       Max: 170.173
>
> The tests doesn't look bad, but the problem is I watch a video clip on
> youtube and my sister starts torrent client, I can't watch anymore.
>
> Cheers
>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>



-- 
Dave Täht

thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks

Re: [Cerowrt-devel] Torrents are too fast

[Dane Medic]

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

Thank you for advice Dave. I'm just looking around how to set-up layer 7
inspection, I've also found this ->
http://luci.subsignal.org/trac/browser/luci/trunk/contrib/package/freifunk-p2pblock?rev=
It would be very nice if someone could "merge" this with simple.qos, I
don't really know how, yet.

2014-11-20 15:40 GMT+01:00 Dave Taht <dave.taht@gmail.com>:

> I would be surprised if you could tolerate a *single* big download
> while watching a movie, at 4mbit/512k, much less torrents, which are 6
> or more.
>
> That said, most torrent clients are configurable in several ways.
>
> 1) You can limit the number of download flows to something far less
> than 6. Try 1 or 2.
>
> 2) You can typically rate limit them in the client to a lower rate
> during the day and a higher rate at night.
>
> 3) You can tell them to mark the torrents as background (QoS marking
> CS1), but that only helps on uploads vs the simple.qos script.
>
> At the router itself, you can try things like identifying torrent
> traffic via a consistent port number (if you have one) to toss it into
> the background queue , or try qos-scripts which has a layer 7 dpi
> tool.
>
>
>
>
> On Thu, Nov 20, 2014 at 6:13 AM, Dane Medic <dm70dm@gmail.com> wrote:
> > dpreed, thank you for response. I'm already using fq_codel with cerowrt
> and
> > I don't think it does what I want (or maybe I want too much :)
> >
> > So the steps I've made:
> > flashed wndr3700v2 with cerowrt 3.10.50-1 then I've measured:
> >
> > root@cerowrt:/usr/lib/CeroWrtScripts# sh betterspeedtest.sh -p
> wlan-si.net
> > -t 120
> > 2014-11-20 12:18:34 Testing against netperf.bufferbloat.net (ipv4) with
> 5
> > simultaneous sessions while pinging wlan-si.net (120 seconds in each
> > direction)
> >
> .........................................................................................................................
> >  Download:  3.78 Mbps
> >   Latency: (in msec, 119 pings, 0.00% packet loss)
> >       Min: 13.077
> >     10pct: 251.522
> >    Median: 317.851
> >       Avg: 308.497
> >     90pct: 371.033
> >       Max: 376.132
> >
> ............................................................................................................................
> >    Upload:  0.48 Mbps
> >   Latency: (in msec, 103 pings, 0.00% packet loss)
> >       Min: 12.278
> >     10pct: 12.727
> >    Median: 18.359
> >       Avg: 23.256
> >     90pct: 33.971
> >       Max: 180.303
> >
> > Then I've put these commands:
> >
> > uci set sqm.ge00.enabled=1
> > uci set sqm.ge00.download=3200
> > uci set sqm.ge00.qdisc=nfq_codel
> > uci commit sqm
> > reboot
> >
> > And another measure:
> >
> > root@cerowrt:/usr/lib/CeroWrtScripts# sh betterspeedtest.sh -p
> wlan-si.net
> > -t 120
> > 2014-11-20 12:49:05 Testing against netperf.bufferbloat.net (ipv4) with
> 5
> > simultaneous sessions while pinging wlan-si.net (120 seconds in each
> > direction)
> >
> .........................................................................................................................
> >  Download:  2.74 Mbps
> >   Latency: (in msec, 121 pings, 0.00% packet loss)
> >       Min: 12.210
> >     10pct: 13.002
> >    Median: 15.077
> >       Avg: 15.095
> >     90pct: 16.968
> >       Max: 18.599
> >
> .............................................................................................................................
> >    Upload:  0.49 Mbps
> >   Latency: (in msec, 101 pings, 0.00% packet loss)
> >       Min: 12.255
> >     10pct: 12.684
> >    Median: 16.679
> >       Avg: 23.100
> >     90pct: 34.019
> >       Max: 170.173
> >
> > The tests doesn't look bad, but the problem is I watch a video clip on
> > youtube and my sister starts torrent client, I can't watch anymore.
> >
> > Cheers
> >
> > _______________________________________________
> > Cerowrt-devel mailing list
> > Cerowrt-devel@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/cerowrt-devel
> >
>
>
>
> --
> Dave Täht
>
> thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks
>

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

Re: [Cerowrt-devel] Torrents are too fast

[Sebastian Moeller]

HI Dane hi Dave,


On Nov 20, 2014, at 17:25 , Dane Medic <dm70dm@gmail.com> wrote:

> Thank you for advice Dave. I'm just looking around how to set-up layer 7 inspection, I've also found this -> http://luci.subsignal.org/trac/browser/luci/trunk/contrib/package/freifunk-p2pblock?rev=
> It would be very nice if someone could "merge" this with simple.qos, I don't really know how, yet.

See the last comment in https://dev.openwrt.org/ticket/8590 it seems that L7 filters are on the way out in openwrt. If I understand correctly L7 does regular expression search of each packet (which are documented as not perfect and potentially slow), I would not be amazed if that would be really costly on your wndr. You might be “saved” though by your slow link ;) .  Also L& filters doe not really work with encrypted packets, so a malicious (actually mischievous would be enough) torrent client could mask its packets out of the filter match by encryption.


> 
> 2014-11-20 15:40 GMT+01:00 Dave Taht <dave.taht@gmail.com>:
> I would be surprised if you could tolerate a *single* big download
> while watching a movie, at 4mbit/512k, much less torrents, which are 6
> or more.
> 
> That said, most torrent clients are configurable in several ways.
> 
> 1) You can limit the number of download flows to something far less
> than 6. Try 1 or 2.
> 
> 2) You can typically rate limit them in the client to a lower rate
> during the day and a higher rate at night.
> 
> 3) You can tell them to mark the torrents as background (QoS marking
> CS1), but that only helps on uploads vs the simple.qos script.

	I think this is the best approach to take, actively configure the torrent client to be a good citizen...

> 
> At the router itself, you can try things like identifying torrent
> traffic via a consistent port number (if you have one) to toss it into
> the background queue , or try qos-scripts which has a layer 7 dpi
> tool.

	If you have just a single torrent application you are concerned with you could capture a few incoming and outgoing packets and see whether you can find a “signature” for these packets in the data and then create “tc filter” invocations just against your specific torrent application…
	I fear there is no automatic solution that will get all this right, and hence the prudent way would be for SQM to use the background queue as the default queue for everything (instead of the best effort queue) and then selectively promote reasonable traffic to the other queues. (But that means everything not classified will share a queue /suffer with the torrents until special cased by a promotion rule). 


Best Regards
	Sebastian

> 
> 
> 
> 
> On Thu, Nov 20, 2014 at 6:13 AM, Dane Medic <dm70dm@gmail.com> wrote:
> > dpreed, thank you for response. I'm already using fq_codel with cerowrt and
> > I don't think it does what I want (or maybe I want too much :)
> >
> > So the steps I've made:
> > flashed wndr3700v2 with cerowrt 3.10.50-1 then I've measured:
> >
> > root@cerowrt:/usr/lib/CeroWrtScripts# sh betterspeedtest.sh -p wlan-si.net
> > -t 120
> > 2014-11-20 12:18:34 Testing against netperf.bufferbloat.net (ipv4) with 5
> > simultaneous sessions while pinging wlan-si.net (120 seconds in each
> > direction)
> > .........................................................................................................................
> >  Download:  3.78 Mbps
> >   Latency: (in msec, 119 pings, 0.00% packet loss)
> >       Min: 13.077
> >     10pct: 251.522
> >    Median: 317.851
> >       Avg: 308.497
> >     90pct: 371.033
> >       Max: 376.132
> > ............................................................................................................................
> >    Upload:  0.48 Mbps
> >   Latency: (in msec, 103 pings, 0.00% packet loss)
> >       Min: 12.278
> >     10pct: 12.727
> >    Median: 18.359
> >       Avg: 23.256
> >     90pct: 33.971
> >       Max: 180.303
> >
> > Then I've put these commands:
> >
> > uci set sqm.ge00.enabled=1
> > uci set sqm.ge00.download=3200
> > uci set sqm.ge00.qdisc=nfq_codel
> > uci commit sqm
> > reboot
> >
> > And another measure:
> >
> > root@cerowrt:/usr/lib/CeroWrtScripts# sh betterspeedtest.sh -p wlan-si.net
> > -t 120
> > 2014-11-20 12:49:05 Testing against netperf.bufferbloat.net (ipv4) with 5
> > simultaneous sessions while pinging wlan-si.net (120 seconds in each
> > direction)
> > .........................................................................................................................
> >  Download:  2.74 Mbps
> >   Latency: (in msec, 121 pings, 0.00% packet loss)
> >       Min: 12.210
> >     10pct: 13.002
> >    Median: 15.077
> >       Avg: 15.095
> >     90pct: 16.968
> >       Max: 18.599
> > .............................................................................................................................
> >    Upload:  0.49 Mbps
> >   Latency: (in msec, 101 pings, 0.00% packet loss)
> >       Min: 12.255
> >     10pct: 12.684
> >    Median: 16.679
> >       Avg: 23.100
> >     90pct: 34.019
> >       Max: 170.173
> >
> > The tests doesn't look bad, but the problem is I watch a video clip on
> > youtube and my sister starts torrent client, I can't watch anymore.
> >
> > Cheers
> >
> > _______________________________________________
> > Cerowrt-devel mailing list
> > Cerowrt-devel@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/cerowrt-devel
> >
> 
> 
> 
> --
> Dave Täht
> 
> thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks
> 
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] Torrents are too fast

[Dane Medic]

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

hm, it looks like somebody is still maintaining the l7-protocols package in
openwrt ->
https://github.com/openwrt/packages/blob/5600fdeeeec861c0359d6d53d1a1518b1817630d/net/l7-protocols/Makefile
https://github.com/gwlim/wr1043nd-chaos-calmer-patch/blob/master/openwrt-patch/037-fix-l7-filter.patch

2014-11-21 12:51 GMT+01:00 Sebastian Moeller <moeller0@gmx.de>:

> HI Dane hi Dave,
>
>
> On Nov 20, 2014, at 17:25 , Dane Medic <dm70dm@gmail.com> wrote:
>
> > Thank you for advice Dave. I'm just looking around how to set-up layer 7
> inspection, I've also found this ->
> http://luci.subsignal.org/trac/browser/luci/trunk/contrib/package/freifunk-p2pblock?rev=
> > It would be very nice if someone could "merge" this with simple.qos, I
> don't really know how, yet.
>
> See the last comment in https://dev.openwrt.org/ticket/8590 it seems that
> L7 filters are on the way out in openwrt. If I understand correctly L7 does
> regular expression search of each packet (which are documented as not
> perfect and potentially slow), I would not be amazed if that would be
> really costly on your wndr. You might be “saved” though by your slow link
> ;) .  Also L& filters doe not really work with encrypted packets, so a
> malicious (actually mischievous would be enough) torrent client could mask
> its packets out of the filter match by encryption.
>
>
> >
> > 2014-11-20 15:40 GMT+01:00 Dave Taht <dave.taht@gmail.com>:
> > I would be surprised if you could tolerate a *single* big download
> > while watching a movie, at 4mbit/512k, much less torrents, which are 6
> > or more.
> >
> > That said, most torrent clients are configurable in several ways.
> >
> > 1) You can limit the number of download flows to something far less
> > than 6. Try 1 or 2.
> >
> > 2) You can typically rate limit them in the client to a lower rate
> > during the day and a higher rate at night.
> >
> > 3) You can tell them to mark the torrents as background (QoS marking
> > CS1), but that only helps on uploads vs the simple.qos script.
>
>         I think this is the best approach to take, actively configure the
> torrent client to be a good citizen...
>
> >
> > At the router itself, you can try things like identifying torrent
> > traffic via a consistent port number (if you have one) to toss it into
> > the background queue , or try qos-scripts which has a layer 7 dpi
> > tool.
>
>         If you have just a single torrent application you are concerned
> with you could capture a few incoming and outgoing packets and see whether
> you can find a “signature” for these packets in the data and then create
> “tc filter” invocations just against your specific torrent application…
>         I fear there is no automatic solution that will get all this
> right, and hence the prudent way would be for SQM to use the background
> queue as the default queue for everything (instead of the best effort
> queue) and then selectively promote reasonable traffic to the other queues.
> (But that means everything not classified will share a queue /suffer with
> the torrents until special cased by a promotion rule).
>
>
> Best Regards
>         Sebastian
>
> >
> >
> >
> >
> > On Thu, Nov 20, 2014 at 6:13 AM, Dane Medic <dm70dm@gmail.com> wrote:
> > > dpreed, thank you for response. I'm already using fq_codel with
> cerowrt and
> > > I don't think it does what I want (or maybe I want too much :)
> > >
> > > So the steps I've made:
> > > flashed wndr3700v2 with cerowrt 3.10.50-1 then I've measured:
> > >
> > > root@cerowrt:/usr/lib/CeroWrtScripts# sh betterspeedtest.sh -p
> wlan-si.net
> > > -t 120
> > > 2014-11-20 12:18:34 Testing against netperf.bufferbloat.net (ipv4)
> with 5
> > > simultaneous sessions while pinging wlan-si.net (120 seconds in each
> > > direction)
> > >
> .........................................................................................................................
> > >  Download:  3.78 Mbps
> > >   Latency: (in msec, 119 pings, 0.00% packet loss)
> > >       Min: 13.077
> > >     10pct: 251.522
> > >    Median: 317.851
> > >       Avg: 308.497
> > >     90pct: 371.033
> > >       Max: 376.132
> > >
> ............................................................................................................................
> > >    Upload:  0.48 Mbps
> > >   Latency: (in msec, 103 pings, 0.00% packet loss)
> > >       Min: 12.278
> > >     10pct: 12.727
> > >    Median: 18.359
> > >       Avg: 23.256
> > >     90pct: 33.971
> > >       Max: 180.303
> > >
> > > Then I've put these commands:
> > >
> > > uci set sqm.ge00.enabled=1
> > > uci set sqm.ge00.download=3200
> > > uci set sqm.ge00.qdisc=nfq_codel
> > > uci commit sqm
> > > reboot
> > >
> > > And another measure:
> > >
> > > root@cerowrt:/usr/lib/CeroWrtScripts# sh betterspeedtest.sh -p
> wlan-si.net
> > > -t 120
> > > 2014-11-20 12:49:05 Testing against netperf.bufferbloat.net (ipv4)
> with 5
> > > simultaneous sessions while pinging wlan-si.net (120 seconds in each
> > > direction)
> > >
> .........................................................................................................................
> > >  Download:  2.74 Mbps
> > >   Latency: (in msec, 121 pings, 0.00% packet loss)
> > >       Min: 12.210
> > >     10pct: 13.002
> > >    Median: 15.077
> > >       Avg: 15.095
> > >     90pct: 16.968
> > >       Max: 18.599
> > >
> .............................................................................................................................
> > >    Upload:  0.49 Mbps
> > >   Latency: (in msec, 101 pings, 0.00% packet loss)
> > >       Min: 12.255
> > >     10pct: 12.684
> > >    Median: 16.679
> > >       Avg: 23.100
> > >     90pct: 34.019
> > >       Max: 170.173
> > >
> > > The tests doesn't look bad, but the problem is I watch a video clip on
> > > youtube and my sister starts torrent client, I can't watch anymore.
> > >
> > > Cheers
> > >
> > > _______________________________________________
> > > Cerowrt-devel mailing list
> > > Cerowrt-devel@lists.bufferbloat.net
> > > https://lists.bufferbloat.net/listinfo/cerowrt-devel
> > >
> >
> >
> >
> > --
> > Dave Täht
> >
> > thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks
> >
> > _______________________________________________
> > Cerowrt-devel mailing list
> > Cerowrt-devel@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
>

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

Re: [Cerowrt-devel] Torrents are too fast

[Sebastian Moeller]

Hi Dane,


On Nov 21, 2014, at 13:04 , Dane Medic <dm70dm@gmail.com> wrote:

> hm, it looks like somebody is still maintaining the l7-protocols package in openwrt -> https://github.com/openwrt/packages/blob/5600fdeeeec861c0359d6d53d1a1518b1817630d/net/l7-protocols/Makefile
> https://github.com/gwlim/wr1043nd-chaos-calmer-patch/blob/master/openwrt-patch/037-fix-l7-filter.patch

	I think that is the user maintained openwrt repository, but you are right l7 filters are available in recent openwrt’s then. But the actual filter definitions are from 2009 let’s just hope the content of the torrent headers has not changed sufficiently in the last 5 years ;) 


Best Regards
	Sebastian


> 
> 2014-11-21 12:51 GMT+01:00 Sebastian Moeller <moeller0@gmx.de>:
> HI Dane hi Dave,
> 
> 
> On Nov 20, 2014, at 17:25 , Dane Medic <dm70dm@gmail.com> wrote:
> 
> > Thank you for advice Dave. I'm just looking around how to set-up layer 7 inspection, I've also found this -> http://luci.subsignal.org/trac/browser/luci/trunk/contrib/package/freifunk-p2pblock?rev=
> > It would be very nice if someone could "merge" this with simple.qos, I don't really know how, yet.
> 
> See the last comment in https://dev.openwrt.org/ticket/8590 it seems that L7 filters are on the way out in openwrt. If I understand correctly L7 does regular expression search of each packet (which are documented as not perfect and potentially slow), I would not be amazed if that would be really costly on your wndr. You might be “saved” though by your slow link ;) .  Also L& filters doe not really work with encrypted packets, so a malicious (actually mischievous would be enough) torrent client could mask its packets out of the filter match by encryption.
> 
> 
> >
> > 2014-11-20 15:40 GMT+01:00 Dave Taht <dave.taht@gmail.com>:
> > I would be surprised if you could tolerate a *single* big download
> > while watching a movie, at 4mbit/512k, much less torrents, which are 6
> > or more.
> >
> > That said, most torrent clients are configurable in several ways.
> >
> > 1) You can limit the number of download flows to something far less
> > than 6. Try 1 or 2.
> >
> > 2) You can typically rate limit them in the client to a lower rate
> > during the day and a higher rate at night.
> >
> > 3) You can tell them to mark the torrents as background (QoS marking
> > CS1), but that only helps on uploads vs the simple.qos script.
> 
>         I think this is the best approach to take, actively configure the torrent client to be a good citizen...
> 
> >
> > At the router itself, you can try things like identifying torrent
> > traffic via a consistent port number (if you have one) to toss it into
> > the background queue , or try qos-scripts which has a layer 7 dpi
> > tool.
> 
>         If you have just a single torrent application you are concerned with you could capture a few incoming and outgoing packets and see whether you can find a “signature” for these packets in the data and then create “tc filter” invocations just against your specific torrent application…
>         I fear there is no automatic solution that will get all this right, and hence the prudent way would be for SQM to use the background queue as the default queue for everything (instead of the best effort queue) and then selectively promote reasonable traffic to the other queues. (But that means everything not classified will share a queue /suffer with the torrents until special cased by a promotion rule).
> 
> 
> Best Regards
>         Sebastian
> 
> >
> >
> >
> >
> > On Thu, Nov 20, 2014 at 6:13 AM, Dane Medic <dm70dm@gmail.com> wrote:
> > > dpreed, thank you for response. I'm already using fq_codel with cerowrt and
> > > I don't think it does what I want (or maybe I want too much :)
> > >
> > > So the steps I've made:
> > > flashed wndr3700v2 with cerowrt 3.10.50-1 then I've measured:
> > >
> > > root@cerowrt:/usr/lib/CeroWrtScripts# sh betterspeedtest.sh -p wlan-si.net
> > > -t 120
> > > 2014-11-20 12:18:34 Testing against netperf.bufferbloat.net (ipv4) with 5
> > > simultaneous sessions while pinging wlan-si.net (120 seconds in each
> > > direction)
> > > .........................................................................................................................
> > >  Download:  3.78 Mbps
> > >   Latency: (in msec, 119 pings, 0.00% packet loss)
> > >       Min: 13.077
> > >     10pct: 251.522
> > >    Median: 317.851
> > >       Avg: 308.497
> > >     90pct: 371.033
> > >       Max: 376.132
> > > ............................................................................................................................
> > >    Upload:  0.48 Mbps
> > >   Latency: (in msec, 103 pings, 0.00% packet loss)
> > >       Min: 12.278
> > >     10pct: 12.727
> > >    Median: 18.359
> > >       Avg: 23.256
> > >     90pct: 33.971
> > >       Max: 180.303
> > >
> > > Then I've put these commands:
> > >
> > > uci set sqm.ge00.enabled=1
> > > uci set sqm.ge00.download=3200
> > > uci set sqm.ge00.qdisc=nfq_codel
> > > uci commit sqm
> > > reboot
> > >
> > > And another measure:
> > >
> > > root@cerowrt:/usr/lib/CeroWrtScripts# sh betterspeedtest.sh -p wlan-si.net
> > > -t 120
> > > 2014-11-20 12:49:05 Testing against netperf.bufferbloat.net (ipv4) with 5
> > > simultaneous sessions while pinging wlan-si.net (120 seconds in each
> > > direction)
> > > .........................................................................................................................
> > >  Download:  2.74 Mbps
> > >   Latency: (in msec, 121 pings, 0.00% packet loss)
> > >       Min: 12.210
> > >     10pct: 13.002
> > >    Median: 15.077
> > >       Avg: 15.095
> > >     90pct: 16.968
> > >       Max: 18.599
> > > .............................................................................................................................
> > >    Upload:  0.49 Mbps
> > >   Latency: (in msec, 101 pings, 0.00% packet loss)
> > >       Min: 12.255
> > >     10pct: 12.684
> > >    Median: 16.679
> > >       Avg: 23.100
> > >     90pct: 34.019
> > >       Max: 170.173
> > >
> > > The tests doesn't look bad, but the problem is I watch a video clip on
> > > youtube and my sister starts torrent client, I can't watch anymore.
> > >
> > > Cheers
> > >
> > > _______________________________________________
> > > Cerowrt-devel mailing list
> > > Cerowrt-devel@lists.bufferbloat.net
> > > https://lists.bufferbloat.net/listinfo/cerowrt-devel
> > >
> >
> >
> >
> > --
> > Dave Täht
> >
> > thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks
> >
> > _______________________________________________
> > Cerowrt-devel mailing list
> > Cerowrt-devel@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/cerowrt-devel
> 
> 

Re: [Cerowrt-devel] Torrents are too fast

[Sebastian Moeller]

Hi Dane,


On Nov 20, 2014, at 15:13 , Dane Medic <dm70dm@gmail.com> wrote:

> dpreed, thank you for response. I'm already using fq_codel with cerowrt and I don't think it does what I want (or maybe I want too much :)
> 
> So the steps I've made:
> flashed wndr3700v2 with cerowrt 3.10.50-1 then I've measured:
> 
> root@cerowrt:/usr/lib/CeroWrtScripts# sh betterspeedtest.sh -p wlan-si.net -t 120
> 2014-11-20 12:18:34 Testing against netperf.bufferbloat.net (ipv4) with 5 simultaneous sessions while pinging wlan-si.net (120 seconds in each direction)
> .........................................................................................................................
>  Download:  3.78 Mbps
>   Latency: (in msec, 119 pings, 0.00% packet loss)
>       Min: 13.077 
>     10pct: 251.522 
>    Median: 317.851 
>       Avg: 308.497 
>     90pct: 371.033 
>       Max: 376.132
> ............................................................................................................................
>    Upload:  0.48 Mbps
>   Latency: (in msec, 103 pings, 0.00% packet loss)
>       Min: 12.278 
>     10pct: 12.727 
>    Median: 18.359 
>       Avg: 23.256 
>     90pct: 33.971 
>       Max: 180.303
> 
> Then I've put these commands:
> 
> uci set sqm.ge00.enabled=1
> uci set sqm.ge00.download=3200
> uci set sqm.ge00.qdisc=nfq_codel
> uci commit sqm
> reboot
> 
> And another measure:
> 
> root@cerowrt:/usr/lib/CeroWrtScripts# sh betterspeedtest.sh -p wlan-si.net -t 120
> 2014-11-20 12:49:05 Testing against netperf.bufferbloat.net (ipv4) with 5 simultaneous sessions while pinging wlan-si.net (120 seconds in each direction)
> .........................................................................................................................
>  Download:  2.74 Mbps
>   Latency: (in msec, 121 pings, 0.00% packet loss)
>       Min: 12.210 
>     10pct: 13.002 
>    Median: 15.077 
>       Avg: 15.095 
>     90pct: 16.968 
>       Max: 18.599
> .............................................................................................................................
>    Upload:  0.49 Mbps
>   Latency: (in msec, 101 pings, 0.00% packet loss)
>       Min: 12.255 
>     10pct: 12.684 
>    Median: 16.679 
>       Avg: 23.100 
>     90pct: 34.019 
>       Max: 170.173
> 
> The tests doesn't look bad, but the problem is I watch a video clip on youtube and my sister starts torrent client, I can't watch anymore.

	Could you post the content of /etc/config/sqm from after activating SQM please. It looks like you did not activate shaping on egress (its not in the “ici set *” above and the upload statistics look identical to the first unshaped example). You really need to control the buffer in both directions to get rid of nasty latency spikes (especially with torrents that I assume  will try to use both directions maximally if left to their own devices). Also 4M/512K sounds like a DSL link, if so you might find the link layer adjustments helpful (if there are question what to fill in just ask). Also if you have a linux or macosx computer available I would recommend to install netperf-wrapper and use the RRUL test to simultaneously load down- and up-link (or alternatively netperfrunner.sh) as this will show bloated buffers more clearly than the individual tests for each direction as performed by betterspeedtest.sh.

Best Regards
	Sebastian


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

Re: [Cerowrt-devel] Torrents are too fast

[Dane Medic]

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

Hi,

correct, I've left egress on 4000 (I thought I should test only ingress
first), but when I did the test with youtube + torrent transfer, I've had
set upload to very small number (I think 10 kbytes/s).

Yes I have DSL line (VDSL2 as I've read ISP info), I'll try to set the
linklayer option on ethernet with overhead of 8, like it says on
http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_SQM_for_CeroWrt_310
I have linux machine so I'll install netperf-wrapper and test things

sqm configuration:

root@cerowrt:~# uci show sqm
sqm.ge00=queue
sqm.ge00.interface=ge00
sqm.ge00.qdisc=fq_codel
sqm.ge00.script=simple.qos
sqm.ge00.qdisc_advanced=1
sqm.ge00.ingress_ecn=ECN
sqm.ge00.egress_ecn=NOECN
sqm.ge00.qdisc_really_really_advanced=1
sqm.ge00.itarget=auto
sqm.ge00.etarget=auto
sqm.ge00.linklayer=none
sqm.ge00.download=3100
sqm.ge00.upload=4000
sqm.ge00.enabled=1

Thank you guys,
Dane

2014-11-21 12:16 GMT+01:00 Sebastian Moeller <moeller0@gmx.de>:

> Hi Dane,
>
>
> On Nov 20, 2014, at 15:13 , Dane Medic <dm70dm@gmail.com> wrote:
>
> > dpreed, thank you for response. I'm already using fq_codel with cerowrt
> and I don't think it does what I want (or maybe I want too much :)
> >
> > So the steps I've made:
> > flashed wndr3700v2 with cerowrt 3.10.50-1 then I've measured:
> >
> > root@cerowrt:/usr/lib/CeroWrtScripts# sh betterspeedtest.sh -p
> wlan-si.net -t 120
> > 2014-11-20 12:18:34 Testing against netperf.bufferbloat.net (ipv4) with
> 5 simultaneous sessions while pinging wlan-si.net (120 seconds in each
> direction)
> >
> .........................................................................................................................
> >  Download:  3.78 Mbps
> >   Latency: (in msec, 119 pings, 0.00% packet loss)
> >       Min: 13.077
> >     10pct: 251.522
> >    Median: 317.851
> >       Avg: 308.497
> >     90pct: 371.033
> >       Max: 376.132
> >
> ............................................................................................................................
> >    Upload:  0.48 Mbps
> >   Latency: (in msec, 103 pings, 0.00% packet loss)
> >       Min: 12.278
> >     10pct: 12.727
> >    Median: 18.359
> >       Avg: 23.256
> >     90pct: 33.971
> >       Max: 180.303
> >
> > Then I've put these commands:
> >
> > uci set sqm.ge00.enabled=1
> > uci set sqm.ge00.download=3200
> > uci set sqm.ge00.qdisc=nfq_codel
> > uci commit sqm
> > reboot
> >
> > And another measure:
> >
> > root@cerowrt:/usr/lib/CeroWrtScripts# sh betterspeedtest.sh -p
> wlan-si.net -t 120
> > 2014-11-20 12:49:05 Testing against netperf.bufferbloat.net (ipv4) with
> 5 simultaneous sessions while pinging wlan-si.net (120 seconds in each
> direction)
> >
> .........................................................................................................................
> >  Download:  2.74 Mbps
> >   Latency: (in msec, 121 pings, 0.00% packet loss)
> >       Min: 12.210
> >     10pct: 13.002
> >    Median: 15.077
> >       Avg: 15.095
> >     90pct: 16.968
> >       Max: 18.599
> >
> .............................................................................................................................
> >    Upload:  0.49 Mbps
> >   Latency: (in msec, 101 pings, 0.00% packet loss)
> >       Min: 12.255
> >     10pct: 12.684
> >    Median: 16.679
> >       Avg: 23.100
> >     90pct: 34.019
> >       Max: 170.173
> >
> > The tests doesn't look bad, but the problem is I watch a video clip on
> youtube and my sister starts torrent client, I can't watch anymore.
>
>         Could you post the content of /etc/config/sqm from after
> activating SQM please. It looks like you did not activate shaping on egress
> (its not in the “ici set *” above and the upload statistics look identical
> to the first unshaped example). You really need to control the buffer in
> both directions to get rid of nasty latency spikes (especially with
> torrents that I assume  will try to use both directions maximally if left
> to their own devices). Also 4M/512K sounds like a DSL link, if so you might
> find the link layer adjustments helpful (if there are question what to fill
> in just ask). Also if you have a linux or macosx computer available I would
> recommend to install netperf-wrapper and use the RRUL test to
> simultaneously load down- and up-link (or alternatively netperfrunner.sh)
> as this will show bloated buffers more clearly than the individual tests
> for each direction as performed by betterspeedtest.sh.
>
> Best Regards
>         Sebastian
>
>
> >
> > Cheers
> > _______________________________________________
> > Cerowrt-devel mailing list
> > Cerowrt-devel@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
>

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

Re: [Cerowrt-devel] Torrents are too fast

[Sebastian Moeller]

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

Hi Dane,

On Nov 21, 2014, at 12:51 , Dane Medic <dm70dm@gmail.com> wrote:

> Hi,
> 
> correct, I've left egress on 4000 (I thought I should test only ingress first),

	A reasonable approach, I just predict that it will only work well once you have shapers on bothe ingress and egress configured correctly.

> but when I did the test with youtube + torrent transfer, I've had set upload to very small number (I think 10 kbytes/s).

	I am confused, you restricted the egress speed to 10 Kbps and wonder why performance was less than satisfactory? :) I you just want to be sure that you are not limited by bloated buffers restricting the bandwidth to 50% of link rates (or even rougher of the transfer estates of betterspeedtest.sh) should be a good starting point. At that rate you will only be able to send 6.66666666667 full sized packets per second each taking 150 ms.

> 
> Yes I have DSL line (VDSL2 as I've read ISP info),

	Hard to believe that any ISP will give you VDSL2 at around 4M/512K as at that speed you are either so far away from the DSLAM that VDSL2 is not any better than ADSL, probably worse, or you link is faster and your ISP throttles your bandwidth due to contract. But you could run the attached script overnight from a linux or macosx machine to test whether your link used ATM encapsulation. A link using ATM will really improve by specifying the correct link layer adjustments and overhead, VDSL2 not so much. If you run this script I am happy to help you analyze it to figure out whether your link uses ATM or not. Oh by the way most ISP modems/routers have a web page that offers (technical)  information about the link it would be great if you could find and post that.

[-- Attachment #2: ping_sweeper7.sh --]
[-- Type: application/octet-stream, Size: 4042 bytes --]

#! /bin/bash
# TODO use seq or bash to generate a list of the requested sizes (to alow for non-equdistantly spaced sizes)

# just an identifier for the ping log
TECH=ADSL
# finding a proper target IP is somewhat of an art, just traceroute a remote site 
# and find the nearest host reliably responding to pings showing the smallet variation of pingtimes
# for this I typically run "traceroute 8.8.8.8", and then select the first host on the ISP side (typically after 
# the first large RTT increment) and test its response by "ping -c 10 -s 16 NNN.NNN.NNN.NNN", if this host does not repsond 
# I pick the next host along the route to 8.8.8.8. I assume the closer the host the less disturbed by other traffic the 
# response will be.


if [ ! $# == 1 ]; then
    echo "To run measurements supply the TARGET IP address as first agument to ${0} this script."
    echo "Use traceroute 8.8.8.8 to get a list of increasingly distant hosts, pick the first host out of your network (ideally the DSLAM)."
    echo "Test whether the selected host responds to ping: 'ping -s16 -c 1 target.IP.address.quad' : this needs to actually return non zero RTTs."
    echo "If the hosts does not reply to the pings take the next host from the traceroute (movin closer to 8.8.8.8), repeat until you find a replying host."
    echo "Once the main script is started have a quick look at the logfile, to see whether the RTTs stay close to the initial test RTT."
    echo "If the RTTs have increased a lot, the PINGPERIOD might be too short, and the host might have put us on a slow path; either increase PINGPERIOD or try the next host..."
    echo ""
    echo "Here is the traceroute (might take a while):"
    echo ""
    traceroute 8.8.8.8
    echo ""
    echo "Alternatively you might try to use googles infrastructure by running: ${0} gstatic.com "
    
    exit 0
else
    TARGET=${1}		# Replace by an appropriate host
fi


DATESTR=`date +%Y%m%d_%H%M%S`	# to allow multiple sequential records
LOG=ping_sweep_${TECH}_${DATESTR}.txt

MAX_PREIP_OVERHEAD_SIZE=44	# as far as I can tell 44 bytes is the maximum pre IP header overhead for an ATM based carrier
IP4_HEADER_SIZE=20		# 20 bytes
IDEAL_MTU=1500			#  what the MTU should look like

# by default non-root ping will only end one packet per second, so work around that by calling ping independently for each package
# empirically figure out the shortest period still giving the standard ping time (to avoid being slow-pathed by our host)
# at 100 packets/s of 116 + 28 + 40 we would need 4 ATM cells = 192byte * 100/s = 150kbit/s
# at 100 packets/s of 16 + 28 + 40nwe would need 2 ATM cells = 96byte * 100/s = 75kbit/s
# on average we need 150 + 75 * 0.5 = 112.5 Kbit/s, increase the ping period if uplinh < 112.5 Kbit/s
PINGPERIOD=0.01		# reduce if uplink slower than roughly 200Kbit/s
PINGSPERSIZE=10000	# the higher the link rate the more samples we need to reliably detect the increasingly smaller ATM quantisation steps. Can be reduced for slower links

# Start, needed to find the per packet overhead dependent on the ATM encapsulation
# to reliably show ATM quantization one would like to see at least two steps, so cover a range > 2 ATM cells (so > 96 bytes)
# Note to be more robust use 3
SWEEPMINSIZE=16		# 64bit systems seem to require 16 bytes of payload to include a timestamp...
SWEEPMAXSIZE=116
SWEEPMAXSIZE=166	# this contains 3 full cells so more transitions to pin the quantization offset to...
    

n_SWEEPS=`expr ${SWEEPMAXSIZE} - ${SWEEPMINSIZE}`


i_sweep=0
i_size=0

while [ ${i_sweep} -lt ${PINGSPERSIZE} ]
do
    (( i_sweep++ ))
    echo "Current iteration: ${i_sweep}"
    # now loop from sweepmin to sweepmax
    i_size=${SWEEPMINSIZE}
    while [ ${i_size} -le ${SWEEPMAXSIZE} ]
    do
	echo "${i_sweep}. repetition of ping size ${i_size}"
	ping -c 1 -s ${i_size} ${TARGET} >> ${LOG} &
	(( i_size++ ))
	# we need a sleep binary that allows non integer times (GNU sleep is fine as is sleep of macosx 10.8.4)
	sleep ${PINGPERIOD}
    done
done

#tail -f ${LOG}

echo "Done... ($0)
"

[-- Attachment #3: Type: text/plain, Size: 4921 bytes --]




> I'll try to set the linklayer option on ethernet with overhead of 8, like it says on http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_SQM_for_CeroWrt_310
> I have linux machine so I'll install netperf-wrapper and test things

	If you really have a VDSL2 link the overhead will not make much of a difference.


Best Regards
	Sebastian

> 
> sqm configuration:
> 
> root@cerowrt:~# uci show sqm
> sqm.ge00=queue
> sqm.ge00.interface=ge00
> sqm.ge00.qdisc=fq_codel
> sqm.ge00.script=simple.qos
> sqm.ge00.qdisc_advanced=1
> sqm.ge00.ingress_ecn=ECN
> sqm.ge00.egress_ecn=NOECN
> sqm.ge00.qdisc_really_really_advanced=1
> sqm.ge00.itarget=auto
> sqm.ge00.etarget=auto
> sqm.ge00.linklayer=none
> sqm.ge00.download=3100
> sqm.ge00.upload=4000

	You should probably set this to 480 or 400 to be on the save side, for you initial tests (judged from the speed tests) and later try to see how far up you can push this without destroying latency under load...

> sqm.ge00.enabled=1
> 
> Thank you guys,
> Dane
> 
> 2014-11-21 12:16 GMT+01:00 Sebastian Moeller <moeller0@gmx.de>:
> Hi Dane,
> 
> 
> On Nov 20, 2014, at 15:13 , Dane Medic <dm70dm@gmail.com> wrote:
> 
> > dpreed, thank you for response. I'm already using fq_codel with cerowrt and I don't think it does what I want (or maybe I want too much :)
> >
> > So the steps I've made:
> > flashed wndr3700v2 with cerowrt 3.10.50-1 then I've measured:
> >
> > root@cerowrt:/usr/lib/CeroWrtScripts# sh betterspeedtest.sh -p wlan-si.net -t 120
> > 2014-11-20 12:18:34 Testing against netperf.bufferbloat.net (ipv4) with 5 simultaneous sessions while pinging wlan-si.net (120 seconds in each direction)
> > .........................................................................................................................
> >  Download:  3.78 Mbps
> >   Latency: (in msec, 119 pings, 0.00% packet loss)
> >       Min: 13.077
> >     10pct: 251.522
> >    Median: 317.851
> >       Avg: 308.497
> >     90pct: 371.033
> >       Max: 376.132
> > ............................................................................................................................
> >    Upload:  0.48 Mbps
> >   Latency: (in msec, 103 pings, 0.00% packet loss)
> >       Min: 12.278
> >     10pct: 12.727
> >    Median: 18.359
> >       Avg: 23.256
> >     90pct: 33.971
> >       Max: 180.303
> >
> > Then I've put these commands:
> >
> > uci set sqm.ge00.enabled=1
> > uci set sqm.ge00.download=3200
> > uci set sqm.ge00.qdisc=nfq_codel
> > uci commit sqm
> > reboot
> >
> > And another measure:
> >
> > root@cerowrt:/usr/lib/CeroWrtScripts# sh betterspeedtest.sh -p wlan-si.net -t 120
> > 2014-11-20 12:49:05 Testing against netperf.bufferbloat.net (ipv4) with 5 simultaneous sessions while pinging wlan-si.net (120 seconds in each direction)
> > .........................................................................................................................
> >  Download:  2.74 Mbps
> >   Latency: (in msec, 121 pings, 0.00% packet loss)
> >       Min: 12.210
> >     10pct: 13.002
> >    Median: 15.077
> >       Avg: 15.095
> >     90pct: 16.968
> >       Max: 18.599
> > .............................................................................................................................
> >    Upload:  0.49 Mbps
> >   Latency: (in msec, 101 pings, 0.00% packet loss)
> >       Min: 12.255
> >     10pct: 12.684
> >    Median: 16.679
> >       Avg: 23.100
> >     90pct: 34.019
> >       Max: 170.173
> >
> > The tests doesn't look bad, but the problem is I watch a video clip on youtube and my sister starts torrent client, I can't watch anymore.
> 
>         Could you post the content of /etc/config/sqm from after activating SQM please. It looks like you did not activate shaping on egress (its not in the “ici set *” above and the upload statistics look identical to the first unshaped example). You really need to control the buffer in both directions to get rid of nasty latency spikes (especially with torrents that I assume  will try to use both directions maximally if left to their own devices). Also 4M/512K sounds like a DSL link, if so you might find the link layer adjustments helpful (if there are question what to fill in just ask). Also if you have a linux or macosx computer available I would recommend to install netperf-wrapper and use the RRUL test to simultaneously load down- and up-link (or alternatively netperfrunner.sh) as this will show bloated buffers more clearly than the individual tests for each direction as performed by betterspeedtest.sh.
> 
> Best Regards
>         Sebastian
> 
> 
> >
> > Cheers
> > _______________________________________________
> > Cerowrt-devel mailing list
> > Cerowrt-devel@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/cerowrt-devel
> 
>