On 3/30/17 1:11 AM, Toke Høiland-Jørgensen wrote:
> leetminiwheat writes:
>
>> Apologies I haven't had time to follow recent developments but are there
>> any recent bufferbloat/CAKE related news/recommendations for the APU2
>> platform? Specifically the APU2C (previous was marvell I believe)
On 12/13/16 4:58 PM, Matt Taggart wrote:
> Hi,
>
> I love the WNDR3800 platform, it's been great over the years first with
> cerowrt and then openwrt. Of the many I've deployed I have only had
> hardware problems with 2 of them, and usually uptimes go over 100 days. You
> can also still buy t
On 11/7/16 6:30 AM, James Cloos wrote:
> but with wshaper there were 8 rather than 4 lines matching parent for
> each interface. There still are 8 for the 3 ethernet devices, but that
> doesn't seem to be a problem
The armada chipset in the omnia has 8 hardware queues on the ethernet
devic
On 8/13/16 12:26 AM, dpr...@reed.com wrote:
> Maybe we all need to buy some Sandvine devices for our homes that detect IW10
> and forge TCP RSTs? Or maybe Ellacoya will develop one for consumers?
>
> That's what Comcast did when bufferbloat was killing their gear on upload, as
> I'm sure we a
I am hoping they got their wifi driver out there, but am afraid to look
at the code drop to find out. At least, it appears to be kernel 3.10.65
based.
https://www.xda-developers.com/team-m-a-d-brings-android-6-0-1-marshmallow-and-full-gpl-kernel-for-jiayu-mediatek-devices/
It is generally my hope that ipv6 nat will not be widely deployed.
Firewalls will be stateful instead, and thus there would be no need to
access the conntrack information for ipv6 in cake.
I'm not sure, however, to
what extent ipv6 conntrack is in openwrt today, certainly udp and tcp,
"in" is ess
I am A) still fiddling with alternate web site generators and B) just
finished writing up (grousing) about all the hardware I just tried to
make work.
http://the-edge.taht.net/post/hardware_from_hell/
I am about to tear apart the dual ethernet nuc we discussed here, again,
swapping out everything
Sometimes markets *can* work. I do hope that viasat's new service is
bufferbloat-free. Some folk over there at least paid some attention to
the technology.
http://finance.yahoo.com/news/investors-react-gogo-gogo-stock-182606506.html;_ylt=AwrC3Sza7cRW7mUA51AnnIlQ;_ylu=X3oDMTByMDgyYjJiBGNvbG8DYmYxBH
I have been considering exiting the cloud as much as possible for my
personal email in particular, and since storage tends to be expensive in
the cloud, to keep that also locally for at least some stuff.
Barrier #1 to doing that is that comcast blocks port 25 on residential
links (I want to upgrad
On 2/15/16 8:11 AM, dpr...@reed.com wrote:
> BTW, I went shopping for a pure home "gateway" box. What pleased me was this
> board, because I am sure it has the "oomph" to deal with up to Gigabit packet
> processing (which is where all the current residential ISPs will shortly be).
> It has
A pithy note on
https://wiki.openwrt.org/toh/tp-link/archer-c5-c7-wdr7500 - it contains
a bitter "thank you" to the FCC - you can't upgrade the firmware to a
third party anymore.
I can confirm this - the archer c7v2 I got off of amazon last week has
firmware 3.14.3, and will not take a web upload
https://forum.openwrt.org/viewtopic.php?id=50914 as of feb 13th has many
features (like having the luci-ssl gui native, sqm-scripts, and support
for nearly all the platforms I have handy (c7v2, linksys 1200ac, wndr
4800 and 4300))... so I replaced a c7v2 router as my default home
gateway to see how
I had a browse at linuxgizmos last weekend. Wow. The cornucopia machine
is open and it is almost impossible to imagine what will happen next! 64
bit arms, 40 bucks. Jeebus.
http://linuxgizmos.com/ringing-in-2016-with-64-open-spec-hacker-friendly-sbcs/
2 years back, 64 bit arms cost 1500 bucks.
fo
Much more readable than the spec!
http://chimera.labs.oreilly.com/books/123401739/ch03.html
I still keep hoping for a comprehensive list (or a tool) for timings for
every possible operation across all the 802.11 standards. Trying to
figure out how long things take "on the wire" makes my brain
Felix's current focus per-sta queuing is on boards with this chipset.
I am going to order a couple, but they may take a month to arrive.
Anyone else want one?
http://www.aliexpress.com/item/Wireless-Router-1200Mbps-dual-band-AC-Router-Support-a-SIM-card-for-3-g-4-g/32382460744.html?ws_ab_test=sea
The simplest thing you can do today to improve latency on your ath9k
devices is to disable wmm (802.11e), and to reduce the ath9k driver
queues to smaller sizes. I typically run the yurtlab network with a
qlen_be of 12 (slow links) to 24 rather than the default.
On links with significant speed iss
peeds have cracked 20Mbit generally, however, the bloat and
bad behavior is shifting to wifi, generally. So please try fiddling with
your internet uplink(s) first.
I look forward to hearing about your gaming results. ;)
>> On Feb 2, 2016, at 5:59 PM, Dave Täht wrote:
>>
>> https
I wish more reporters would realize that this is as good as it gets, and
as users go more online, life will get worse rapidly.
I dream of someone doing a meetup inside that starbucks in NYC, and 5-10
people testing that wifi simultaneously with flent.
http://www.pcmag.com/article2/0,2817,2498177,
While at last week's scale conference I ran across a guy doing
interesting things in tinc. One of the things he'd pointed out was the
general availability of service discovery options using a very flexible
many master/client protocol called "raft" - including using it as a dns
substitute in his env
It would be so nice, of course, if this was open source from the getgo.
http://arstechnica.com/gadgets/2016/01/tp-link-unveils-worlds-first-802-11ad-wigig-router/
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloa
One of my issues with blindly applying techniques to block certain IPs
is trusting the sources of the data - many people have ended up on a
blocklist that shouldn't have.
That said, ipset is so effective and so scalable, that perhaps deploying
this by default
http://www.linuxjournal.com/content/s
The existing dissector handled gre and ipip encapsulated packets.
This adds support for ipv6 (proto 41) encapsulated packets to the
dissector, making possible a better fq_codel hash on 6in4, 6to4 tunnels.
---
net/core/flow_dissector.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/net/
From: Dave Taht
On embedded devices in particular, large queues of small packets from the rx
path with a large truesize can exist. Reducing their size can reduce
memory pressure. skb_reduce_truesize is a helper function for doing this,
when needed.
---
include/linux/skbuff.h | 18 +
From: Dave Taht
At a knife's edge, where we are rapidly entering and existing
a dropping state, seek lower to find the optimimum.
---
include/net/codel.h |3 +++
1 file changed, 3 insertions(+)
diff --git a/include/net/codel.h b/include/net/codel.h
index dbfccb7..5e85632 100644
--- a/includ
From: Dave Taht
This patch attempts to smooth out codel behavior in several ways.
These first two are arguably bugs.
1) Newton's method doesn't run well in reverse, run it twice on a decline
2) Account for the idea of dropping out of drop state after a drop
upon entering drop state.
3) the old
So I was mostly fiddling with codel itself, trying to make it work
better on long RTTs, when the memory and oom issues came up.
The two patches following for codel are experimental.
It will take me multiple days to prove out/dismiss as junk and/or further
improve these...
During that test cy
26 matches
Mail list logo
