[Cerowrt-devel] that latest build I did is looking good
Joel Wirāmu Pauling
joel at aenertia.net
Fri Jun 26 09:53:01 EDT 2015
On Jun 25, 2015 10:35 AM, "Dave Taht" <dave.taht at gmail.com> 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. 
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. 
> :whew: Have to go climb a couple trees this week. Have 3 source
> specific gateways up, might get two more. 
> * 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:
> 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
>  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:
>  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
>  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:
> What will it take to vastly improve wifi for everyone?
> Cerowrt-devel mailing list
> Cerowrt-devel at lists.bufferbloat.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Cerowrt-devel