On Fri, Feb 7, 2014 at 1:37 PM, Sebastian Moeller <[email protected]> wrote: > Hi Dave, > > > On Feb 7, 2014, at 18:57 , Dave Taht <[email protected]> wrote: > >> On Fri, Feb 7, 2014 at 12:01 PM, Stephen Hemminger >> <[email protected]> wrote: >>> Any progress on getting a stable version? Recent versions seem to be >>> targeted >>> at IPv6 and other things which do not impact me for home use. What does >>> matter >>> is fixing the wireless hanging issue on 2.4Ghz. >> >> Do I detect a plainative note? I share it... >> >> I'm not aware of any problems on 2.4ghz in the last specific release I >> did for comcast. It's been in day-to-day use here since I put it out. >> >> http://snapon.lab.bufferbloat.net/~cero2/cerowrt/wndr/comcast/3.10.28-4/ >> >> Feel free to give it a shot. The stuff that made it comcast specific >> (co-existence with HE tunnels) is solved, so the next gen will be >> generic. >> >> I AM painfully aware that ht40+ at 5ghz appears to have broken on >> several channels (Seems to work on 36 and fail on 44) There was a >> fresh merge from wireless-testing recently, that I hope fixes it. > > With ht40+ on 44 I get MCS index 7 with transmigrate 150 reported on > my macbook, that according to the table in > http://en.wikipedia.org/wiki/IEEE_802.11n-2009 means 40MHz channel, with > netperf-wrapper I get an accumulate of ~100Mbits/s (which actually sounds too > good to be true I would have expected 75 tops, but with the macbook hogging > all tops, there seems to be less wasted airtime for direction changes). So at > least with country code GE channel 44 is capable of operating in ht40+ mode.
What release exactly? I confess to have merely seen the bug on a release or two back. You should get MCS15, btw. >> There is still one unaligned_instruction trap left to beat that >> appears to be triggered by odhcpd. >> >> root@comcast-gw:~# cat /sys/kernel/debug/mips/unaligned_instructions >> 18000 > > So with my non-working IP6 on 3.10.28-1, I get: > root@nacktmulle:~# cat /sys/kernel/debug/mips/unaligned_instructions > 0 > root@nacktmulle:~# uptime > 19:35:13 up 11 days, 22:46, load average: 0.09, 0.43, 1.06 No, not fixed, it's triggered by ipv6 traffic. > > so most of the traps seem fixed! > > >> >> One of the things that scares me is that a bunch of openwrt targets >> are migrating to 3.13 and if I miss a window the very stable 3.10.28 >> release is going to get replaced upstream with 3.13 and resultant >> headaches. (and benefits) > > Do yu know what their plan is? Put out a stable version an maintain > that or switch to a rolling release cycle? I have had few detailed conversations with the #openwrt-devel folk of late. I have been ignoring irc in favor of doing work. There is a ton of good stuff landing in openwrt, let me forward something in a second... > > > Best Regards & many Thanks for doing all this > Sebastian > >> >> As my own deadlines slip everywhere, I made a big push earlier this >> week to appeal to many folk to get dnsmasq + dnssec more widely tested >> on other platforms in the hope that whenever I got unburied it would >> be stable enough to toss into cero. (that's going along swimmingly on >> x86 and arm so far) >> >> I hope to replace the failed server this tonight and burn sunday on >> trying to resolve the problems above. The currently borked srcs are on >> github. >> >> >> -- >> Dave Täht >> >> Fixing bufferbloat with cerowrt: >> http://www.teklibre.com/cerowrt/subscribe.html >> _______________________________________________ >> Cerowrt-devel mailing list >> [email protected] >> https://lists.bufferbloat.net/listinfo/cerowrt-devel > -- Dave Täht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html _______________________________________________ Cerowrt-devel mailing list [email protected] https://lists.bufferbloat.net/listinfo/cerowrt-devel
