+1 A blog format where we can also comment and document our experiences/tweaks.
On Saturday, March 5, 2016, David Lang <da...@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.t...@gmail.com> >> To: moeller0 <moell...@gmx.de> >> Cc: "cerowrt-devel@lists.bufferbloat.net" >> <cerowrt-devel@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 >> somewhere? >> >> (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 >> odroid) >> >> 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 >> tests.... >> _______________________________________________ >> Cerowrt-devel mailing list >> Cerowrt-devel@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/cerowrt-devel >> > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel >
_______________________________________________ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel