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