[Cerowrt-devel] cerowrt 3.3.8-17: nice latency improvements, some issues with bind

[Török Edwin]

On 08/13/2012 09:08 AM, Dave Taht wrote:
> I'm too tired to write up a full set of release notes, but I've been
> testing it all day,
> and it looks better than -10 and certainly better than -11, but I won't know
> until some more folk sit down and test it, so here it is.
> 
> http://huchra.bufferbloat.net/~cero1/3.3/3.3.8-17/
> 
> fresh merge with openwrt, fix to a bind CVE, fixes for 6in4 and quagga
> routing problems,
> and a few tweaks to fq_codel setup that might make voip better.
> 
> Go forth and break things!

Hi,

This is the first cerowrt that I tried on my router (was using Openwrt before), and I'm quite happy
with the latency improvements on WiFi (see below).

However I've encountered some issues with bind. After powering on the router this morning DNS wasn't working,
and logread showed a lot of errors from bind about a broken trust chain on every domain name.
Unfortunately the syslog buffer was at its default 16k (increased it to 256k now) so the exact sequence of errors was lost.
I restarted bind (/etc/init.d/named restart), and then DNS was working again. Ping times from the router to google were between 30ms and 450ms,
but ping times from my desktop to google (through same router) was 8ms.
I rebooted the router to try to reproduce the bind issue, but it didn't occur again. Pings from the router to google are also normal again.

Any idea what could've caused this behaviour?

Note that my internet connection is through PPPoE, so when bind starts on boot it might not have IPv4 network connectivity yet.
There's also a tiny delay between IPv4 and IPv6 connectivity, because IPv6 prefix is obtained using dhcp6c after PPPoE has connected.

Another minor issue is that p910nd and luci-app-p910nd were not available via opkg install, but I found them on openwrt.org, so that works now.
DHCPv6-PD had to be configured manually of course, same as with openwrt, the difference is that I only get IPv6 on wired interfaces now,
and not on wireless.
That seems to be by design because the interfaces are not bridged anymore and I get only a /64 from my ISP (slan_len 0), so can't really create
more sub-networks from it.

Onto the good news, here are some measurements (ping time / bandwidth from my laptop connected through WiFi to my desktop connected through GbitE):

no fq_codel on laptop, openwrt, wlan0 5Ghz: 0.859/174.859/923.768/198.308 ms; 120 - 140Mbps
w/ fq_codel on laptop, openwrt, wlan0 5Ghz: 1.693/ 26.727/ 54.936/ 11.746 ms; 120 - 140Mbps
no fq_codel on laptop, cerowrt, wlan0 5Ghz: 2.310/ 15.183/140.495/ 30.337 ms; 75 - 85 Mbps
w/ fq_codel on laptop, cerowrt, wlan0 5Ghz: 1.464/  1.981/  2.223/  0.221 ms; 75 - 85 Mbps

The latency improvement is awesome, and I don't really mind the sacrificed bandwidth to accomplish it.
Is the bandwidth drop intended though? When enabling fq_codel just on my laptop I didn't notice any bandwidth drop at all.
AFAICT my router is the only radio on 5Ghz and it is configured the same way as openwrt was (HT40+).

Note: I use WPA2-PSK, and I disabled the other two SSIDs on the 5Ghz.

Best regards,
--Edwin