#17807: qos codel patch noecn to eth1 (wan) and qos-scripts question
-------------------------+------------------------
Reporter: robnitro@… | Owner: developers
Type: defect | Status: new
Priority: normal | Milestone:
Component: packages | Version: Trunk
Resolution: | Keywords:
-------------------------+------------------------
Comment (by dtaht):
OK, will try to comment on 3 comments
(please note that I pay WAY more attention to email on the cerowrt-devel
list than here)
1) I would hope sqm-scripts remains compatible with bb for a while until I
(or someone) gets around to polishing it up for mainline openwrt.
2) Well, we've settled on 300 as a decent value overall. If you look at
the packet curve distributions for most traffic you will see a sharp knee
in the curve starting about there and rapidly going to 1280, then 1500, so
300 seemed ideal.
2a) Turning off ecn by default is the safe choice. Although we've had
extensive testing by now, notably in mosh, and free.fr, and in cerowrt - I
don't blame nbd for turning it off. That said, I have no reports of
leaving it on hurting anyone for over 2 years now, and certainly feel it
does no harm on the ingress interface, so, feel free to bug him to put it
back in.
2c) debloat really needs to get debloated. I mean, it's enormous, needs
lua and is mostly broken, with tons of ideas that didn't work out (like
the qfq stuff). I have a shell script that does almost all that is needed.
Fiddling with BQL is less necessary now, I generally let it autotune at
100Mbit and up, and measure whatever a box comes up with. Certainly 3000
seemed about right at 100Mbit on everything I tried.
A possibly more useful thing to fiddle with is the size of the tx ring. I
have had it set as low as 4 packets with sometimes useful results,
sometimes with slightly higher overhead, but better mixing.
2d) as for txqueuelen, using nearly any other qdisc than pfifo_fast, means
it ignores the txqueuelen setting entirely. No need to bother.
3) As for torrent, what I have generally done has turned on CS1 marking in
my torrent *client(s)*, and walla! no more work needed at the router, sqm-
scripts tosses it in the background queue. For example, the transmission
client supports this, you set a rule in the
.config/transmission/settings.json for it.
I agree that a more elaborate classifier section would be useful in some
instances, however my overall goal in developing fq_codel, sqm, etc, was
to try and have something as simple as possible, that worked across a
broad a range of traffic as possible, before getting elaborate.
You can, rather than doing it in sqm, add an iptables rule to the outbound
torrent port if you like, also, in /etc/firewall.user, something like
iptables -I POSTROUTING -t mangle -p the_torrent_port -o ge00 -j DSCP
--set-class CS1
ip6tables the_same_stuff # and the above line might be a bit wrong, but
you get the idea...
Or is it the download torrent killing you? In that case a hook into upnp
might be worthwhile, to generate the right lines.
We regarded torrent as a huge problem when the work started, and the only
solution we came up with back then was this sort of client specification
of the diffserv value, or doing port numbers, or dpi:
http://perso.telecom-paristech.fr/~drossi/paper/rossi13tma-b.pdf
Lastly...
I have asked Bram to mark bittorrent's stuff by default as CS1, also.
--
Ticket URL: <https://dev.openwrt.org/ticket/17807#comment:8>
OpenWrt <http://openwrt.org>
Opensource Wireless Router Technology
_______________________________________________
openwrt-tickets mailing list
[email protected]
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-tickets
