From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id C291521F783 for ; Fri, 26 Jun 2015 06:53:06 -0700 (PDT) Received: by pabvl15 with SMTP id vl15so69397034pab.1 for ; Fri, 26 Jun 2015 06:53:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aenertia.net; s=dkimaenertianet; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=mwRqBs9CJ1kb5aYOoyRh0y/+bJxWbnAFEHyvIfjsPoU=; b=dM6HHEBDCVFJy/aXRjW6cVoLw31HPeym/Yd3CzEFdrs1ydjcGF6fmxzHxPUAu4yzEZ euuxq2BV+xkz9Q97N1qUQpJPjDq6RehxYfwuuVCk8J823NoYRDKPLz0SgJWVuqRVZ1V3 TTAHg2yEUHMI6dCDlenUP8iFzDLBBoLTfk3tw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=mwRqBs9CJ1kb5aYOoyRh0y/+bJxWbnAFEHyvIfjsPoU=; b=OPQEJTXCcaeo3yMZCYU9xmJ8IuETVtZxyEgIpk5eq8d9HJnz5S2IrIC6J+/aj7oz/O Nvs+MJ4gRMJjIoHjU0e/h0iB+A2/PJJXVzlpa8QccPMatcjXUpadfE5m/De3A7KPdlm9 brlJ/i92o23WaMTfM4eg2tZ0IgWMeeg+vRw3jlDfoXaFAutGIFfvxzw/6d54PX/oVsmF sIo0D2YQeE4W4mgfN0JOvJ1Jg5QaXjzB3uo4U0L5KW79JtLTSroHPoCZBJEix66+2LSV uGgVoGKEENGVWYM16pCxcIu9UAINs5xiYJgu60bMImxf3xph2dWxqW8h1YGr87Q9QXQ1 umNg== X-Gm-Message-State: ALoCoQlnGvkJducRWpwOeJ27taYD9eBPPSqnULmpHhv5bC8J5oK/XWgk00nL0nWk1v0ixW0aH+Y1 MIME-Version: 1.0 X-Received: by 10.66.249.168 with SMTP id yv8mr3650919pac.49.1435326785738; Fri, 26 Jun 2015 06:53:05 -0700 (PDT) Sender: aenertia@aenertia.net Received: by 10.66.10.134 with HTTP; Fri, 26 Jun 2015 06:53:01 -0700 (PDT) Received: by 10.66.10.134 with HTTP; Fri, 26 Jun 2015 06:53:01 -0700 (PDT) In-Reply-To: References: Date: Fri, 26 Jun 2015 06:53:01 -0700 X-Google-Sender-Auth: bfLunyv2B6_J00EfGqX4woA8FVI Message-ID: From: =?UTF-8?Q?Joel_Wir=C4=81mu_Pauling?= To: "Taht, Dave" Content-Type: multipart/alternative; boundary=047d7b111c0f33781405196c0f39 Cc: cerowrt-devel@lists.bufferbloat.net Subject: Re: [Cerowrt-devel] that latest build I did is looking good X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2015 13:53:35 -0000 --047d7b111c0f33781405196c0f39 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 =3D=3D 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=C3=A4ht > 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 --047d7b111c0f33781405196c0f39 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Jun 25, 2015 10:35 AM, "Dave Taht" <dave.taht@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. [3]

Did you update with the latest Qualcomm v5 ath10k firmware a= nd associated mac80211 patches that were committed into upstream openwrt tr= unk a couple of days ago?

My last builds from end of May died several days ago after a= round 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 Mountai= n 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<= br> > 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<= br> > 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<= br> > 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<= br> > 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<= br> > a routing protocol.....
>
> Pull up wireshark on:
> http://snapon.lab.bufferbloat.net/~d/newrouters/linuxcap.cap
> use a ipv6.traffic_class.ce =3D=3D 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.co= m/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<= br> > 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:
>
> =C2=A0http://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=C3=A4ht
> worldwide bufferbloat report:
> ht= tp://www.dslreports.com/speedtest/results/bufferbloat
> And:
> What will it take to vastly improve wifi for everyone?
> https://p= lus.google.com/u/0/explore/makewififast
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@l= ists.bufferbloat.net
> https= ://lists.bufferbloat.net/listinfo/cerowrt-devel

--047d7b111c0f33781405196c0f39--