On Tue, Jan 27, 2015 at 6:08 PM, Ewen McNeill
Hi Dave,
On 27/01/15 16:45, Dave Taht wrote:
Well, I would love it if I could get more data from folk willing to install netperf-wrapper and run a 5 minute test that would be good. [...]
on debian derived linux those are:
In case it helps someone else trying to test this week...
Given the high level of enthusiasm displayed I wish I'd made this request last week....
For "Debian derived Linux" read "Ubuntu" AFAICT (netperf is not packaged in Debian, up through Debian Experimental, so "apt-get build-dep netperf" won't work there; I can send a packages-my-Ubuntu-system-wanted-to-install list in case someone wants to try on Debian).
It's also apparently _not_ Ubuntu 14.04 LTS, because that appears to install netperf-wrapper as a Python Egg with the given install instructions, and netperf-wrapper appears to be completely unable to find its tests within the Python Egg, resulting in it complaining:
There is also a bug with that version's matplotlib - not a problem for the test itself, but for generating the charts.
-=- cut here -=- Fatal error: Hostname lookup failed for host rrul: [Errno -2] Name or service not known -=- cut here -=-
You can tell you have this problem if "netperf-wrapper --list-tests" fails with a Python stack trace, rather than returning a list of tests.
My kludgy workaround (which seems to have worked) was:
-=- cut here -=- cd /usr/local/share && sudo ln -s ~/src/netperf-wrapper . -=- cut here -=-
which then lets "nztest.sh" (http://snapon.lab.bufferbloat.net/~d/nz/nztest.sh) run after some editing to point it at something other than the non-existent NZ server (I chose the US west coast).
I imagine the python libs are stored in /usr/local/share....
Serious suggestion: perhaps it would help to bundle this with Docker or similar? It'd then be easier for people to install a known-to-work version with just a "needs modern Linux kernel" dependency.
When we started this project, we couldn't trust the devices, the device drivers, the qdiscs, the tcps, or the oses, and adding a vm on top of that tended to compound things. It took a really long time to get to the roots of the problems and while all that is mostly fixed on modern linuxes.... To this day, many co-location facilities are still running ancient linuxes on their bare hardware, or hypervisors with behavior that is not well understood, with invisible workloads elsewhere in the system. It's really hard to trust those results, except when the devices you are testing are running at very low rates relative to the host you are testing from. Docker hadn't appeared as a force, when we started, either. Certainly containerization is saner than vms, but when you are testing for a problem that goes all the way down to the raw hardware, having less abstractions is of a help. :/ That said, a docker version of the tool would be fabulous to have around and we'd welcome to contribution of an image easier for more people to install! Before it is asked, we didn't do a web bandwidth measurement tool (like speedof.me or speedtest) because we found universally that they were inaccurate above about 20Mbits, as were java based things like netalyzer. Instead, we did netperf-wrapper, which has been now proven to scale to 40GigE, and scales to a gbit even on fairly low end hardware. Netperf results are trusted by the kernel developers also, unlike iperf. That said, one day, we'll try to do up a tool that works on every platform, runs fast, and can do the kind of analytics you can do that the netperf-wrapper --gui can do - the analytical and graphical portions of the engine can deal with any form of periodic sampling of a flow, from any tool, and there are wrappers now for things like d-itg, and iperf in it, so it's increasingly misnamed as a tool. I agree strongly that we need to make the core tests easier to install! But it was more important to get back accurate data at least, at first. In the interim, the pain of installing it is incurred once, and the benefits last. One of my favorite things to do is compare a speedtest result to a netperf-wrapper one, in front of someone dubious about bufferbloat....
In my present location, however, I am seeing a *450ms* RTT to the eu, which I sure hope isn't normal for NZ, just this hotel. ( ping netperf-eu.bufferbloat.net ).
It seems about 75-100ms too high. From Vodafone cable in Wellington:
-=- cut here -=- ewen(a)ashram:~$ ping netperf-eu.bufferbloat.net PING kau.toke.dk (130.243.26.64): 56 data bytes 64 bytes from 130.243.26.64: icmp_seq=0 ttl=39 time=341.222 ms 64 bytes from 130.243.26.64: icmp_seq=1 ttl=39 time=342.191 ms [...] -=- cut here -=-
and it's about 15ms lower (ie, around 325ms) from my colo box in central Wellington (which is roughly the cable Internet overhead, so an expected difference).
320-350ms is roughly the RTT I'd expect to see to Europe out of New Zealand, mostly due to speed-of-light not being infinite. (I do work on a few systems based in Europe so have fairly consistently seen this for years.)
If anyone has a power supply suitable for a wndr3800 and NZ power standards, I brought one, might be able to fix matters here.....
A quick online search suggests this is a 12V DC, 2.5A power supply (eg, http://www.myaccount.charter.com/customers/support.aspx?supportarticleid=329...). If so, they seem likely to be fairly common.
common as in a radio shack or equivalent in roturua?
Sort of why I just asked if openwrt derived gear was a problem here. That stuff is the farthest along by far, for home cpe.
The main issue here for DSL is that there is an approval process ("Telepermit") for legally connecting equipment to NZ copper lines, so only models that someone has put through the approval process can be legally used (and IIRC each importer has to have their own import approved).
The only fully BQL'd and fq_codeled DSL device I have used at is the transcend ( can't quite remember the name?) dsl box made in australia. It was built around a geode, and dave woodhouse fixed their driver, but good. There are undoubtably others at this point. Free.fr uses their own custom DSL firmware for their revolution V6 boxes.
For Vodafone Cable the CPE device is usually supplied by Vodafone (and acts as a bridge), and it's standard-Ethernet from there in, so there may be more choice.
What are the typical rates sold? This is the typical result of (comcast) cable in the USA - see image 2 for the "normal" state of cable there: http://snapon.lab.bufferbloat.net/~cero2/jimreisert/results.html and this is a more extensive set of tests and tunings showing how to address up and down bandwidth issues, using the rrul test as a guide. http://burntchrome.blogspot.co.nz/2014_05_01_archive.html
I've not gone looking for specific models that CoroWRT has focused on in NZ (except for looking for WNDR3800 just now, and not immediately finding any obviously for sale -- but IIRC the model is getting harder to find everywhere now).
Well, I had planned to donate mine to someone here that needs it... except that I didn't bring a power supply suitable.... And everything important that was in cerowrt is in openwrt chaos calmer, and any of the thousands of platforms openwrt supports could be used here. Also, the latest edgerouter software has fq_codel, as do several high end home routers like the netgear X4 and everything with streamboost. We have been trying to coax mikrotik to pay attention... Now, having given all this info out, can I just skip the talk and drink beer? :)
Ewen
-- Dave Täht thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks