From: Sebastian Moeller <moeller0@gmx.de>
To: Dane Medic <dm70dm@gmail.com>
Cc: "cerowrt-devel@lists.bufferbloat.net"
<cerowrt-devel@lists.bufferbloat.net>
Subject: Re: [Cerowrt-devel] Torrents are too fast
Date: Fri, 21 Nov 2014 13:17:54 +0100 [thread overview]
Message-ID: <889067ED-7F57-40A0-8AC2-55A38C3B9F8F@gmx.de> (raw)
In-Reply-To: <CABsdH_F_hz0gOjM_581yQUevavYKNA5=YonYFK5U6Tek+dK21A@mail.gmail.com>
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
>
>
next prev parent reply other threads:[~2014-11-21 12:17 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-20 14:13 Dane Medic
2014-11-20 14:40 ` Dave Taht
2014-11-20 16:25 ` Dane Medic
2014-11-21 11:51 ` Sebastian Moeller
2014-11-21 12:04 ` Dane Medic
2014-11-21 12:17 ` Sebastian Moeller [this message]
2014-11-21 11:16 ` Sebastian Moeller
2014-11-21 11:51 ` Dane Medic
2014-11-21 12:14 ` Sebastian Moeller
-- strict thread matches above, loose matches on Subject: below --
2014-11-03 7:53 Dane Medic
2014-11-03 13:33 ` dpreed
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=889067ED-7F57-40A0-8AC2-55A38C3B9F8F@gmx.de \
--to=moeller0@gmx.de \
--cc=cerowrt-devel@lists.bufferbloat.net \
--cc=dm70dm@gmail.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