[Cerowrt-devel] odroid C1+ status
Luis E. Garcia
luis at bitamins.net
Sat Mar 5 18:34:47 EST 2016
A blog format where we can also comment and document our experiences/tweaks.
On Saturday, March 5, 2016, David Lang <david at lang.hm> wrote:
> A blog format for hardware testing would be a good idea.
> David Lang
> On Sat, 5 Mar 2016, Dave Taht wrote:
> Date: Sat, 5 Mar 2016 12:23:36 -0800
>> From: Dave Taht <dave.taht at gmail.com>
>> To: moeller0 <moeller0 at gmx.de>
>> Cc: "cerowrt-devel at lists.bufferbloat.net"
>> <cerowrt-devel at lists.bufferbloat.net>
>> Subject: [Cerowrt-devel] odroid C1+ status
>> wow, thx for all the suggestions on alternate x86 router hardware... I
>> will read more later.
>> Would using a blog format for things like the following work better
>> for people? I could more easily revise, including graphics, etc,
>> etc... could try to hit on our hot buttons (upgradability, bloat,
>> reliability, kernel versions, manufacturer support) with some sort of
>> grading system...
>> http://the-edge.taht.net/post/odroid_c1_plus/ in this case
>> I got the odroid C1+ to work better. (either a cable or power supply
>> issue, I swapped both). On output it peaks at about 416Mbits with 26%
>> of cpu being spent in a softirq interrupt. On input I can get it to
>> gbit, with 220% of cpu in use.
>> The rrul tests were pretty normal, aside from the apparent 400mbit
>> upload limit causing contention on rx/tx (at the moment I have no good
>> place to put these test results since snapon is now behind a firewall.
>> I'd like to get more organized about how we store and index these
>> results also)
>> There is no BQL support in the odroid driver for it, and it ships with
>> linux 3.10.80. At least its a LTS version.... I am totally unfamiliar
>> with the odroid ecosystem but maybe there is active kernel dev on it
>> (The pi 2, on the other hand, is kernel 4.1.17-v7 AND only has a
>> 100mbit phy, so it is hard to complain about only getting 400mbit from
>> the odroid c1+, but, dang it, a much later kernel would be nice in the
>> My goal in life, generally, is to have a set of boxes with known
>> characteristics to drive tests with, that are reliable enough to setup
>> once and ignore.
>> A) this time around, I definitely wanted variety, particularly in tcp
>> implementations, kernel versions, ethernet and wifi chips - as it
>> seemed like drawing conclusions from "perfect" drivers like the e1000e
>> all the time was a bad idea. We have a very repeatable testbed in
>> karlstad, already - I'm interested in what random sort of traffic can
>> exist on a home network that messes life up.
>> One of the things I noticed while using kodi is that the box announces
>> 2k of multicast ipv4 packets every 30 seconds or so on the upnp
>> port... AND over 4k of multicast ipv6 packets, if ipv6 is enabled.
>> B) Need to be able to drive 802.11ac as hard as possible with as many
>> stations as possible.
>> C) needs to be low power and quiet (cheap is good too!)
>> Has anyone tried the banana pi? That's what comcast is using in their
>> Cerowrt-devel mailing list
>> Cerowrt-devel at lists.bufferbloat.net
> Cerowrt-devel mailing list
> Cerowrt-devel at lists.bufferbloat.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Cerowrt-devel