<p dir="ltr"><br>
On Jun 25, 2015 10:35 AM, "Dave Taht" <<a href="mailto:dave.taht@gmail.com">dave.taht@gmail.com</a>> wrote:<br>
><br>
> I have been abusing it on a picostation and nanostation now for 48<br>
> hours. The archer c7v2 (as a source specific gateway) for a week. A<br>
> couple wndr3800s. No crashes. Can still trigger the dreaded wifi TX<br>
> DMA bug, but it seems harder now. DID regularly crash the iwl in one<br>
> box. [3]</p>
<p dir="ltr">Did you update with the latest Qualcomm v5 ath10k firmware and associated mac80211 patches that were committed into upstream openwrt trunk a couple of days ago?</p>
<p dir="ltr">My last builds from end of May died several days ago after around a month of uptime. Probably due to the power zone bugs in wifi but I can't check until I get back to Vancouver tonight (currently in Mountain View)<br><br></p>
<p dir="ltr">> My mission was to get to something that I could deploy here at a small<br>
> scale and just let run for a month while away in the eu, and that was<br>
> looking dicy there for a while. (I am glad to have basically started<br>
> in april!)<br>
><br>
> So... we do, finally, have an openwrt build that uses cake, has the<br>
> minstrel-blues patches, and andrews minimum variance patches, working<br>
> dnssec (we hope!), and a new version of babel with ecn enabled, has<br>
> snmp, that does dhcp-pd fairly right, and works with comcast. I also<br>
> have things (odhcp6c is way better than isc, dibbler, wide) working<br>
> fairly well with another debian based firewall.<br>
><br>
> If/when new cake or sqm stuff arrives my plan (barring other major<br>
> bugs elsewhere) is to just incrementally build that and tc-adv out of<br>
> the above frozen repo. [1]<br>
><br>
> :whew: Have to go climb a couple trees this week. Have 3 source<br>
> specific gateways up, might get two more. [2]<br>
><br>
> * babel bug - channel diversity routing does not autodetect the actual<br>
> channel you are on. Setting it manually works, but is a pita to<br>
> remember to do... fixing it is a mere matter of grokking the iw<br>
> nl80211 code.<br>
><br>
> * Juliusz does not like having a routing protocol that uses ecn but<br>
> does not respond to it (yet!), (I agree partially) but me, what I see<br>
> is routing suffering from congestive failures periodically, and I am<br>
> most interested in what is going on at precisely the point of<br>
> congestion... particularly the rtt timestamps now in babel... so I<br>
> left it in. DID prove that even a minimalistic routing protocol in a<br>
> fq_codel environment on present day wifi can suffer from significant<br>
> congestive loss. (or in this case, get CE marked). Distinguishing<br>
> between path connectivity loss - and congestion - seems worthwhile in<br>
> a routing protocol.....<br>
><br>
> Pull up wireshark on:<br>
> <a href="http://snapon.lab.bufferbloat.net/~d/newrouters/linuxcap.cap">http://snapon.lab.bufferbloat.net/~d/newrouters/linuxcap.cap</a><br>
> use a ipv6.traffic_class.ce == 1 filter in wireshark.<br>
><br>
> An observation: routing stuff that does not use IP (like arp, and I<br>
> think batman and ISIS) cannot use ecn at all...<br>
><br>
> - I did not bother testing hnetd. Simply not enough time to test it.<br>
> What I plan to do is just backhaul a few fixed ipv6 prefixes to the<br>
> core locations that can use them after finishing up:<br>
> <a href="https://github.com/dtaht/ipv6_selfassign">https://github.com/dtaht/ipv6_selfassign</a> - and try to do more to<br>
> figure out hnetd at ietf, or look over dhcp-pd again for internal use.<br>
><br>
> - did not do package signing<br>
><br>
> [1] If you have any missing packages you need from that repo, tell me<br>
> now. But the goal is to push up tc-adv and cake into the openwrt<br>
> mainline repos next.... running on things like the linksys 1200ac...<br>
> then get minstrel-blues straightened out... and start on per station<br>
> queueing... - and I am still not in a position to do another<br>
> cerowrt-like effort. Where do we go with this? I feel like we are<br>
> limping along....<br>
><br>
> Still, if you want to play along, knowing full well we will be stuck<br>
> here for months or forever:<br>
><br>
>  <a href="http://snapon.lab.bufferbloat.net/~cero3/lupin/ar71xx/">http://snapon.lab.bufferbloat.net/~cero3/lupin/ar71xx/</a><br>
><br>
> [2] a pita in my environment is to get the picos and nanos setup right<br>
> (unbridged, adhoc, snmp, etc) , so I am doing separate builds for<br>
> that.<br>
><br>
> [3] Some flent data here: <a href="http://snapon.lab.bufferbloat.net/~d/newrouters.tgz">snapon.lab.bufferbloat.net/~d/newrouters.tgz</a><br>
><br>
> everything with the word "linux" in the title was a the iwl using<br>
> linux box. the other tests were driven by OSX. It was<br>
> interesting/depressing to see how much more airtime the osx box<br>
> grabbed, while the linux box was quite fair to the AP. Do not have any<br>
> longer range tests... that awaits tree-climbing.<br>
><br>
> --<br>
> Dave Täht<br>
> worldwide bufferbloat report:<br>
> <a href="http://www.dslreports.com/speedtest/results/bufferbloat">http://www.dslreports.com/speedtest/results/bufferbloat</a><br>
> And:<br>
> What will it take to vastly improve wifi for everyone?<br>
> <a href="https://plus.google.com/u/0/explore/makewififast">https://plus.google.com/u/0/explore/makewififast</a><br>
> _______________________________________________<br>
> Cerowrt-devel mailing list<br>
> <a href="mailto:Cerowrt-devel@lists.bufferbloat.net">Cerowrt-devel@lists.bufferbloat.net</a><br>
> <a href="https://lists.bufferbloat.net/listinfo/cerowrt-devel">https://lists.bufferbloat.net/listinfo/cerowrt-devel</a><br>
</p>