4 ms·

yeah -- I came across their site the other day. Would love to see some quantitative / qualitative numbers from that project.

by sheraz 14y ago

krakensden 14y ago
They've done a bunch of work on reducing buffers and setting up AQM by default, and I've heard mumblings about improvements but can't find numbers. Closest thing I could find was this github repo: https://github.com/dtaht/deBloat/tree/master/test https://github.com/dtaht/deBloat/tree/master/test with lots of tests but no comparisons (stock OpenWRT vs ceroWRT would be interesting, for instance).
- rb12345 14y ago
  It's been a while since this was done, but as well as the AQM and Byte Queue Limit support, a lot of work was done on minimising unaligned access traps (http://www.bufferbloat.net/issues/360 http://www.bufferbloat.net/issues/360). The Linux networking stack assumes that IP packets are word-aligned, but Ethernet headers are usually 14 bytes. The specific Atheros chipset used in the WNDR3700/WNDR3800 does not pad Ethernet packets and does not support misaligned DMA, and so a lot of misaligned access traps were triggered. Fixing that resulted in a 15% increase in speed for IPv4, and a doubling in speed for IPv6 (https://lists.openwrt.org/pipermail/openwrt-devel/2012-April/015025.html https://lists.openwrt.org/pipermail/openwrt-devel/2012-April...). As far as I can see, those patches did not get accepted into upstream OpenWRT, since these changes really should be made more generic and possibly pushed upstream. The patches would also hurt performance slightly in the case of properly-aligned packets.
  - dtaht2 14y ago
    I have not had the time to generalize these patches. I do note that alternate ideas for this problem landed in Linux 3.5 which are impossible to backport into Linux 3.3, so I have shelved the idea of working on generalization. These patches were specific to the ar71xx hardware and unneeded on most other devices.
- dtaht2 14y ago
  (dave taht here) Given that core components of what we were trying to do (BQL and the codel and fq_codel qdiscs) have only just landed in the mainline linux kernels, doing comprehensive benchmarks would have been misleading. Secondly - cerowrt's intent is a research project - everything that works we try to get into openwrt - so while the qos implementations differ, both are using fq_codel now. It's my hope that tomato and gargoyle and dd-wrt - indeed as many router distros - adopt fq_codel or something like it as their underlying qdisc. http://queue.acm.org/detail.cfm?id=2209336 http://queue.acm.org/detail.cfm?id=2209336 thirdly - for the kinds of things we are trying to fix (bufferbloat, mesh networks, dns, ipv6) not a lot of good benchmarks exist.
- dtaht2 14y ago
  As for benchmarks, I have not taken the time to publish the results we currently get with fq_codel. However they are better in every respect than our previous attempt with sfqred and comparable to the qfq work we also did. It's not every day you go around seeing orders of magnitude improvements in anything... http://www.teklibre.com/~d/bloat/pfifo_fast_vs_sfq_qfq_log.png http://www.teklibre.com/~d/bloat/pfifo_fast_vs_sfq_qfq_log.p...
  - krakensden 14y ago
    That is a sexy, sexy graph.

yeah -- I came across their site the other day. Would love to see some quantitative / qualitative numbers from that project.

by sheraz 14y ago

yeah -- I came across their site the other day. Would love to see some quantitative / qualitative numbers from that project.

krakensden 14y ago

They've done a bunch of work on reducing buffers and setting up AQM by default, and I've heard mumblings about improvements but can't find numbers. Closest thing I could find was this github repo: https://github.com/dtaht/deBloat/tree/master/test https://github.com/dtaht/deBloat/tree/master/test with lots of tests but no comparisons (stock OpenWRT vs ceroWRT would be interesting, for instance).

rb12345 14y ago
It's been a while since this was done, but as well as the AQM and Byte Queue Limit support, a lot of work was done on minimising unaligned access traps (http://www.bufferbloat.net/issues/360 http://www.bufferbloat.net/issues/360). The Linux networking stack assumes that IP packets are word-aligned, but Ethernet headers are usually 14 bytes. The specific Atheros chipset used in the WNDR3700/WNDR3800 does not pad Ethernet packets and does not support misaligned DMA, and so a lot of misaligned access traps were triggered. Fixing that resulted in a 15% increase in speed for IPv4, and a doubling in speed for IPv6 (https://lists.openwrt.org/pipermail/openwrt-devel/2012-April/015025.html https://lists.openwrt.org/pipermail/openwrt-devel/2012-April...). As far as I can see, those patches did not get accepted into upstream OpenWRT, since these changes really should be made more generic and possibly pushed upstream. The patches would also hurt performance slightly in the case of properly-aligned packets.
- dtaht2 14y ago
  I have not had the time to generalize these patches. I do note that alternate ideas for this problem landed in Linux 3.5 which are impossible to backport into Linux 3.3, so I have shelved the idea of working on generalization. These patches were specific to the ar71xx hardware and unneeded on most other devices.
dtaht2 14y ago
(dave taht here) Given that core components of what we were trying to do (BQL and the codel and fq_codel qdiscs) have only just landed in the mainline linux kernels, doing comprehensive benchmarks would have been misleading. Secondly - cerowrt's intent is a research project - everything that works we try to get into openwrt - so while the qos implementations differ, both are using fq_codel now. It's my hope that tomato and gargoyle and dd-wrt - indeed as many router distros - adopt fq_codel or something like it as their underlying qdisc. http://queue.acm.org/detail.cfm?id=2209336 http://queue.acm.org/detail.cfm?id=2209336 thirdly - for the kinds of things we are trying to fix (bufferbloat, mesh networks, dns, ipv6) not a lot of good benchmarks exist.
dtaht2 14y ago
As for benchmarks, I have not taken the time to publish the results we currently get with fq_codel. However they are better in every respect than our previous attempt with sfqred and comparable to the qfq work we also did. It's not every day you go around seeing orders of magnitude improvements in anything... http://www.teklibre.com/~d/bloat/pfifo_fast_vs_sfq_qfq_log.png http://www.teklibre.com/~d/bloat/pfifo_fast_vs_sfq_qfq_log.p...
- krakensden 14y ago
  That is a sexy, sexy graph.