[Cerowrt-devel] Two d-link products tested for bloat...

[Cerowrt-devel] Two d-link products tested for bloat...

[Dave Taht]

I ordered a d-link DGL-5500 from amazon this week. It arrived today.
This is their almost top of the line 802.11ac router.

Their streamboost QoS feature - the first thing you see on their
configuration page - LOVELY gui, actually! - was entirely broken in
the uplink direction.

Admittedly that was the first generation firmware. I know how hard it
is to get that right. So I tried to update it. My attempt to update
the firmware for it from their website, bricked it. And it appears the
only way to update it, or to update it to openwrt, is via a gui, not
tftp.

ok.... so...

In an orgy of giving companies that don´t deserve my money, money,
I also got the DIR-860L. It was the "A1" model, which of course, has
no support in openwrt, and there is no way to figure out if an online
retailer is selling the entirely different B model or not.

Their version of the QoS system was entirely broken in *both
directions*. While I was mildly happy that it used weighted fair
queuing by default, bandwidth limitation failed to work *at all*,
except, that it did classify CS1 traffic, as *higher* priority than
best effort.

So in both cases, no matter what you did, even if you tried to do the
right thing... you had bufferbloat induced on the next hop (if, I was
trying to actually test this on a cablemodem or dsl link)

I would really to flush this crap from the marketplace, and the only
way left, I think, is to stop being a nice guy.

My problem is, that I really am a nice guy, and the only way I could
possibly do that is put on a persona, do a blog, call it something
like the angry engineer, or something like that.

But I am pretty sure that venom I would have to summon on a daily
basis would be bad for my blood pressure. Maybe we could all get
together on it, and only raise our collective BP by a point or three
each? The Avenging Engineers?

the relevant netperf-wrapper data is in each of these dirs:

http://snapon.lab.bufferbloat.net/~d/DIR-860L/dir-860L-bandwidth-broke-in-both-directions.png

http://snapon.lab.bufferbloat.net/~d/dgl-5500/totalfailure-to-control-the-upload.png

On Wed, Feb 18, 2015 at 1:28 AM, Sebastian Moeller <moeller0@gmx.de> wrote:
> Hi Felix, hi List,
>
>
> On Jan 25, 2015, at 12:09 , Felix Fietkau <nbd@openwrt.org> wrote:
>
>> Here's another candidate:
>> http://us.dlink.com/products/connect/wireless-ac1200-dual-band-gigabit-cloud-router-dir-860l/
>>
>> CPU: MT7621 (dual-core MIPS, 880 MHz, 4 virtual CPUs)
>> The device has preliminary OpenWrt support already. In my tests, handles
>> ~820 Mbit/s NAT without any special acceleration features (with fq_codel,
>> no shaping). Haven't done any tests with shaping yet.
>> Wifi (MT7612E) is still buggy with my mt76 driver, but I'll fix that in
>> March when I get back from vacation.
>>
>> - Felix
>
>         I am currently searching for a replacement for my wndr3700v2 as it is running out of steam on my temporary 100/40 Mbps link. This thing looks quite decent, but I notice between https://wikidevi.com/wiki/D-Link_DIR-860L_rev_A1 and https://wikidevi.com/wiki/D-Link_DIR-860L_rev_B1 that d-link reused the sam name for quite different hardware implementations, and only the more recent B1 revision will work for us. (Is it just me or do you also find this tendency to not even add the revision to the official name a bit annoying?)
>         So, does anybody here now how to order a specific revision in Germany? Or is the only way to wait a bit and hope the A1 revision clears the retail channel so only B1’s are left? I notice that from looking at the internal photos for both devices posted on the FCC site that the old A1 Broadcom revision has its USB port "above" the ethernet ports while the B1 Mediatek revision has the USB port between DC in and below the ethernet ports. Am I correct in assuming that deployed hardware needs to match the FCC design exactly (that is, in case of revision a new FCC submission with new photos is required)?
>
> Best Regards
>         Sebastian



-- 
Dave Täht

thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks

Re: [Cerowrt-devel] [Bloat] Two d-link products tested for bloat...

[Aaron Wood]

[-- Attachment #1: Type: text/plain, Size: 5484 bytes --]

Perhaps just a wall of shame?  No venom, just point out the failings, and
call people out.

But, frankly, I don't think any of the router mfr's actually care (I've
seen no evidence of it), and since they're not in the business of actually
making these things (just putting their labels on them), I don't see them
being able to drive it in a coherent manner.  I'm appalled that the silicon
vendors aren't in on this.  Because frankly _this_ is the sort of thing
that they can use to distinguish themselves.  But as usual, they seem more
interested in butchering the open source software to make something
"proprietary", which is full of bugs and poor performance except in a
narrow lab setup.

The people that I expect to do better at this are the Ubiquiti and others,
which _are_ doing hardware design (to some degree), and building the
software that goes on top of it as well.

-Aaron

On Thu, Feb 19, 2015 at 6:04 PM, Dave Taht <dave.taht@gmail.com> wrote:

> I ordered a d-link DGL-5500 from amazon this week. It arrived today.
> This is their almost top of the line 802.11ac router.
>
> Their streamboost QoS feature - the first thing you see on their
> configuration page - LOVELY gui, actually! - was entirely broken in
> the uplink direction.
>
> Admittedly that was the first generation firmware. I know how hard it
> is to get that right. So I tried to update it. My attempt to update
> the firmware for it from their website, bricked it. And it appears the
> only way to update it, or to update it to openwrt, is via a gui, not
> tftp.
>
> ok.... so...
>
> In an orgy of giving companies that don´t deserve my money, money,
> I also got the DIR-860L. It was the "A1" model, which of course, has
> no support in openwrt, and there is no way to figure out if an online
> retailer is selling the entirely different B model or not.
>
> Their version of the QoS system was entirely broken in *both
> directions*. While I was mildly happy that it used weighted fair
> queuing by default, bandwidth limitation failed to work *at all*,
> except, that it did classify CS1 traffic, as *higher* priority than
> best effort.
>
> So in both cases, no matter what you did, even if you tried to do the
> right thing... you had bufferbloat induced on the next hop (if, I was
> trying to actually test this on a cablemodem or dsl link)
>
> I would really to flush this crap from the marketplace, and the only
> way left, I think, is to stop being a nice guy.
>
> My problem is, that I really am a nice guy, and the only way I could
> possibly do that is put on a persona, do a blog, call it something
> like the angry engineer, or something like that.
>
> But I am pretty sure that venom I would have to summon on a daily
> basis would be bad for my blood pressure. Maybe we could all get
> together on it, and only raise our collective BP by a point or three
> each? The Avenging Engineers?
>
> the relevant netperf-wrapper data is in each of these dirs:
>
>
> http://snapon.lab.bufferbloat.net/~d/DIR-860L/dir-860L-bandwidth-broke-in-both-directions.png
>
>
> http://snapon.lab.bufferbloat.net/~d/dgl-5500/totalfailure-to-control-the-upload.png
>
> On Wed, Feb 18, 2015 at 1:28 AM, Sebastian Moeller <moeller0@gmx.de>
> wrote:
> > Hi Felix, hi List,
> >
> >
> > On Jan 25, 2015, at 12:09 , Felix Fietkau <nbd@openwrt.org> wrote:
> >
> >> Here's another candidate:
> >>
> http://us.dlink.com/products/connect/wireless-ac1200-dual-band-gigabit-cloud-router-dir-860l/
> >>
> >> CPU: MT7621 (dual-core MIPS, 880 MHz, 4 virtual CPUs)
> >> The device has preliminary OpenWrt support already. In my tests, handles
> >> ~820 Mbit/s NAT without any special acceleration features (with
> fq_codel,
> >> no shaping). Haven't done any tests with shaping yet.
> >> Wifi (MT7612E) is still buggy with my mt76 driver, but I'll fix that in
> >> March when I get back from vacation.
> >>
> >> - Felix
> >
> >         I am currently searching for a replacement for my wndr3700v2 as
> it is running out of steam on my temporary 100/40 Mbps link. This thing
> looks quite decent, but I notice between
> https://wikidevi.com/wiki/D-Link_DIR-860L_rev_A1 and
> https://wikidevi.com/wiki/D-Link_DIR-860L_rev_B1 that d-link reused the
> sam name for quite different hardware implementations, and only the more
> recent B1 revision will work for us. (Is it just me or do you also find
> this tendency to not even add the revision to the official name a bit
> annoying?)
> >         So, does anybody here now how to order a specific revision in
> Germany? Or is the only way to wait a bit and hope the A1 revision clears
> the retail channel so only B1’s are left? I notice that from looking at the
> internal photos for both devices posted on the FCC site that the old A1
> Broadcom revision has its USB port "above" the ethernet ports while the B1
> Mediatek revision has the USB port between DC in and below the ethernet
> ports. Am I correct in assuming that deployed hardware needs to match the
> FCC design exactly (that is, in case of revision a new FCC submission with
> new photos is required)?
> >
> > Best Regards
> >         Sebastian
>
>
>
> --
> Dave Täht
>
> thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>

[-- Attachment #2: Type: text/html, Size: 7012 bytes --]

Re: [Cerowrt-devel] [Bloat] Two d-link products tested for bloat...

[Jonathan Morton]

[-- Attachment #1: Type: text/plain, Size: 2729 bytes --]

Out of curiosity, perhaps you could talk to A&A about their FireBrick
router. They make a big point of having written the firmware for it
themselves, and they might be more interested in having researchers poke at
it in interesting ways than the average big name.  A&A are an ISP, not a
hardware manufacturer by trade.

Meanwhile, I suspect the ultimate hardware vendors don't care because their
customers, the big brands, don't care. They in turn don't care because
neither ISPs nor consumers care (on average). A coherent, magazine style
review system with specific areas given star ratings might have a chance of
fixing that, if it becomes visible enough. I'm not sure that a rant blog
would gain the same sort of traction.

Some guidance can be gained from the business of reviewing other computer
hardware. Power supplies are generally, at their core, one of a few
standard designs made by one of a couple of big subcontractors. The quality
of the components used to implement that design, and ancillary hardware
such as heatsinks and cabling, are what distinguish them in the
marketplace. Likewise motherboards are all built around a standard CPU
socket, chipset and form factor, but the manufacturers find lots of little
ways to distinguish themselves on razor thin margins; likewise graphics
cards. Laptops are usually badly designed in at least one stupid way
despite the best efforts of reviewers, but thanks to them it is now
possible to sort through the general mess and find one that doesn't
completely suck at a reasonable price.

As for the rating system itself:

- the Communications Black Hole, for when we can't get it to work at all.
Maybe we can shrink a screen grab from Interstellar for the job.

- the Tin Cans & String, for when it passes packets okay (out of the box)
but is horrible in every other important respect.

- the Carrier Pigeon. Bonus points if we can show it defecating on the
message (or the handler's wrist).

- the Telegraph Pole (or Morse Code Key). Maybe put the Titanic in the
background just to remind people how hard they are failing.

- the Dial-Up Modem. Perhaps products which become reliable and useful if
the user installs OpenWRT should get at least this rating.

- the Silver RJ45, for products which contrive to be overall competent in
all important respects.

- the Golden Fibre, for the very best, most outstanding examples of best
practice, without any significant faults at all. Bonus Pink Floyd reference.

I've been toying with the idea of putting up a website on a completely
different subject, but which might have similar structure. Being able to
use the same infrastructure for two different sites might spread the costs
in an interesting way...

- Jonathan Morton

[-- Attachment #2: Type: text/html, Size: 3003 bytes --]

Re: [Cerowrt-devel] [Bloat] Two d-link products tested for bloat...

[Dave Taht]

I spent a bit of my vacation porting my old blog over from blogger,
and the ikiwiki "successor" to that blog also. It took quite a few sed
scripts, but it is mostly done...

I switched to using hugo ( https://github.com/spf13/hugo ). Hugo is a
surprisingly useful language, and *fast*.

the 940+ postings render to a static fairly nicely formatted website
in under a second. (took minutes, with ikiwiki) It was really nice to
have regained control of my canon, and to be able to grep through
things, and use tools like sed on it, and coming up with some way of
copying with the chaos of the bufferbloat site was kind of my
subconcious goal... but

and in reading all that old blog material, I remembered I had a life
before bufferbloat... and still, as things started re-taking shape, I
started scribbling down a whole bunch of new things in the easy to
write in markdown format, ranting, getting things out of my system,
and it was starting to feel productive to be able to edit in a real
editor again and not have to use the web for *anything*...

but, boy, I am not sure if the web is ready to see a side of me that
frustrated and angry and fed up, and dripping sarcasm and scorn at
every turn, again.

http://the-edge.blogspot.com/2003/06/when-youre-staring-at-brick-walls.html

I really, really, really hated ham the marketing monkey way back when.


On Fri, Feb 20, 2015 at 12:47 AM, Jonathan Morton <chromatix99@gmail.com> wrote:
> Out of curiosity, perhaps you could talk to A&A about their FireBrick
> router. They make a big point of having written the firmware for it
> themselves, and they might be more interested in having researchers poke at
> it in interesting ways than the average big name.  A&A are an ISP, not a
> hardware manufacturer by trade.
>
> Meanwhile, I suspect the ultimate hardware vendors don't care because their
> customers, the big brands, don't care. They in turn don't care because
> neither ISPs nor consumers care (on average). A coherent, magazine style
> review system with specific areas given star ratings might have a chance of
> fixing that, if it becomes visible enough. I'm not sure that a rant blog
> would gain the same sort of traction.
>
> Some guidance can be gained from the business of reviewing other computer
> hardware. Power supplies are generally, at their core, one of a few standard
> designs made by one of a couple of big subcontractors. The quality of the
> components used to implement that design, and ancillary hardware such as
> heatsinks and cabling, are what distinguish them in the marketplace.
> Likewise motherboards are all built around a standard CPU socket, chipset
> and form factor, but the manufacturers find lots of little ways to
> distinguish themselves on razor thin margins; likewise graphics cards.
> Laptops are usually badly designed in at least one stupid way despite the
> best efforts of reviewers, but thanks to them it is now possible to sort
> through the general mess and find one that doesn't completely suck at a
> reasonable price.
>
> As for the rating system itself:
>
> - the Communications Black Hole, for when we can't get it to work at all.
> Maybe we can shrink a screen grab from Interstellar for the job.
>
> - the Tin Cans & String, for when it passes packets okay (out of the box)
> but is horrible in every other important respect.
>
> - the Carrier Pigeon. Bonus points if we can show it defecating on the
> message (or the handler's wrist).
>
> - the Telegraph Pole (or Morse Code Key). Maybe put the Titanic in the
> background just to remind people how hard they are failing.
>
> - the Dial-Up Modem. Perhaps products which become reliable and useful if
> the user installs OpenWRT should get at least this rating.
>
> - the Silver RJ45, for products which contrive to be overall competent in
> all important respects.
>
> - the Golden Fibre, for the very best, most outstanding examples of best
> practice, without any significant faults at all. Bonus Pink Floyd reference.
>
> I've been toying with the idea of putting up a website on a completely
> different subject, but which might have similar structure. Being able to use
> the same infrastructure for two different sites might spread the costs in an
> interesting way...
>
> - Jonathan Morton



-- 
Dave Täht

thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks

Re: [Cerowrt-devel] [Bloat] Two d-link products tested for bloat...

[dpreed]

[-- Attachment #1: Type: text/plain, Size: 4255 bytes --]


+1 for this idea.  It really worked for Anand's and Tom's - their reviews caught fire and got followed so much that they could become profitable businesses from the ads.
 
Craigslist style business model, funding both reviewing and CeroWRT promotion activities would be the logical thing.  And I love the names! (free + some premium service that doesn't compromise the purity and freeness of the reviews)...
 
Thoughts on the premium service that might go with this:
 
1) some kind of "support service" that links people with skilled support for WiFi in their area (for a percentage on each referral)
 
2) Premium insider news  content (like LWN.net, which I subscribe to at the professional level, because it is so great).
 
The point of this is not to maximize the likelihood of buyout for billions of dollars.  I don't oppose that outcome, but it is tricky to aim for that goal without compromising the review (and news if there) quality.  You don't want "vendor sponsorship".  You might want early access to upcoming products, as long as it is on your own terms and not a way of letting vendors buy your integrity, which they would certainly attempt.
 
I don't normally do this, but I would contribute content at a modest level - and I'm sure others would.  The key missing feature is an editor (e.g. Jonathan Corbet, Michael Swaine, Doc Searls, .. - that type of editor, not necessarily those people).
 
 
 


On Friday, February 20, 2015 3:47am, "Jonathan Morton" <chromatix99@gmail.com> said:



Out of curiosity, perhaps you could talk to A&A about their FireBrick router. They make a big point of having written the firmware for it themselves, and they might be more interested in having researchers poke at it in interesting ways than the average big name.  A&A are an ISP, not a hardware manufacturer by trade.
Meanwhile, I suspect the ultimate hardware vendors don't care because their customers, the big brands, don't care. They in turn don't care because neither ISPs nor consumers care (on average). A coherent, magazine style review system with specific areas given star ratings might have a chance of fixing that, if it becomes visible enough. I'm not sure that a rant blog would gain the same sort of traction.
Some guidance can be gained from the business of reviewing other computer hardware. Power supplies are generally, at their core, one of a few standard designs made by one of a couple of big subcontractors. The quality of the components used to implement that design, and ancillary hardware such as heatsinks and cabling, are what distinguish them in the marketplace. Likewise motherboards are all built around a standard CPU socket, chipset and form factor, but the manufacturers find lots of little ways to distinguish themselves on razor thin margins; likewise graphics cards. Laptops are usually badly designed in at least one stupid way despite the best efforts of reviewers, but thanks to them it is now possible to sort through the general mess and find one that doesn't completely suck at a reasonable price.
As for the rating system itself:
- the Communications Black Hole, for when we can't get it to work at all. Maybe we can shrink a screen grab from Interstellar for the job.
- the Tin Cans & String, for when it passes packets okay (out of the box) but is horrible in every other important respect.
- the Carrier Pigeon. Bonus points if we can show it defecating on the message (or the handler's wrist).
- the Telegraph Pole (or Morse Code Key). Maybe put the Titanic in the background just to remind people how hard they are failing.
- the Dial-Up Modem. Perhaps products which become reliable and useful if the user installs OpenWRT should get at least this rating.
- the Silver RJ45, for products which contrive to be overall competent in all important respects.
- the Golden Fibre, for the very best, most outstanding examples of best practice, without any significant faults at all. Bonus Pink Floyd reference.
I've been toying with the idea of putting up a website on a completely different subject, but which might have similar structure. Being able to use the same infrastructure for two different sites might spread the costs in an interesting way...
- Jonathan Morton

[-- Attachment #2: Type: text/html, Size: 7493 bytes --]

Re: [Cerowrt-devel] [Bloat] Two d-link products tested for bloat...

[Isaac Konikoff]

I did some rtt_fair4be tests on different APs per Dave's request. The 
test setup was a LANforge 802.11ac box with a wired port connected to 
the AP LAN port and with 4 emulated wireless stations that were 
connected to the AP wireless over the air. I ran the test on each of the 
following APs with firmware versions:

netgear3700v2 - 1.0.0.12
netgear6300 - v1.0.2.70_1.0.50
netgear7000 - dd-wrt-23884M
dlink-dgl5500 - 1.11b03
linksys1900ac - 1.1.7.160582
asus-rt-ac66r - 3.0.0.4.374_5517

Here's a comparison plot of box totals:
http://www.candelatech.com/downloads/rtt_fair4be-comparison-box-plot.png

Here's a tarball of all the test results:
http://candelatech.com/downloads/rtt_fair4be-ap-tests.tgz

I'm still refining the test setup, so I'll be re-running these as well 
as trying out other APs.

Isaac


On 02/19/2015 06:04 PM, Dave Taht wrote:
> I ordered a d-link DGL-5500 from amazon this week. It arrived today.
> This is their almost top of the line 802.11ac router.
>
> Their streamboost QoS feature - the first thing you see on their
> configuration page - LOVELY gui, actually! - was entirely broken in
> the uplink direction.
>
> Admittedly that was the first generation firmware. I know how hard it
> is to get that right. So I tried to update it. My attempt to update
> the firmware for it from their website, bricked it. And it appears the
> only way to update it, or to update it to openwrt, is via a gui, not
> tftp.
>
> ok.... so...
>
> In an orgy of giving companies that don´t deserve my money, money,
> I also got the DIR-860L. It was the "A1" model, which of course, has
> no support in openwrt, and there is no way to figure out if an online
> retailer is selling the entirely different B model or not.
>
> Their version of the QoS system was entirely broken in *both
> directions*. While I was mildly happy that it used weighted fair
> queuing by default, bandwidth limitation failed to work *at all*,
> except, that it did classify CS1 traffic, as *higher* priority than
> best effort.
>
> So in both cases, no matter what you did, even if you tried to do the
> right thing... you had bufferbloat induced on the next hop (if, I was
> trying to actually test this on a cablemodem or dsl link)
>
> I would really to flush this crap from the marketplace, and the only
> way left, I think, is to stop being a nice guy.
>
> My problem is, that I really am a nice guy, and the only way I could
> possibly do that is put on a persona, do a blog, call it something
> like the angry engineer, or something like that.
>
> But I am pretty sure that venom I would have to summon on a daily
> basis would be bad for my blood pressure. Maybe we could all get
> together on it, and only raise our collective BP by a point or three
> each? The Avenging Engineers?
>
> the relevant netperf-wrapper data is in each of these dirs:
>
> http://snapon.lab.bufferbloat.net/~d/DIR-860L/dir-860L-bandwidth-broke-in-both-directions.png
>
> http://snapon.lab.bufferbloat.net/~d/dgl-5500/totalfailure-to-control-the-upload.png
>
> On Wed, Feb 18, 2015 at 1:28 AM, Sebastian Moeller <moeller0@gmx.de> wrote:
>> Hi Felix, hi List,
>>
>>
>> On Jan 25, 2015, at 12:09 , Felix Fietkau <nbd@openwrt.org> wrote:
>>
>>> Here's another candidate:
>>> http://us.dlink.com/products/connect/wireless-ac1200-dual-band-gigabit-cloud-router-dir-860l/
>>>
>>> CPU: MT7621 (dual-core MIPS, 880 MHz, 4 virtual CPUs)
>>> The device has preliminary OpenWrt support already. In my tests, handles
>>> ~820 Mbit/s NAT without any special acceleration features (with fq_codel,
>>> no shaping). Haven't done any tests with shaping yet.
>>> Wifi (MT7612E) is still buggy with my mt76 driver, but I'll fix that in
>>> March when I get back from vacation.
>>>
>>> - Felix
>>
>>          I am currently searching for a replacement for my wndr3700v2 as it is running out of steam on my temporary 100/40 Mbps link. This thing looks quite decent, but I notice between https://wikidevi.com/wiki/D-Link_DIR-860L_rev_A1 and https://wikidevi.com/wiki/D-Link_DIR-860L_rev_B1 that d-link reused the sam name for quite different hardware implementations, and only the more recent B1 revision will work for us. (Is it just me or do you also find this tendency to not even add the revision to the official name a bit annoying?)
>>          So, does anybody here now how to order a specific revision in Germany? Or is the only way to wait a bit and hope the A1 revision clears the retail channel so only B1’s are left? I notice that from looking at the internal photos for both devices posted on the FCC site that the old A1 Broadcom revision has its USB port "above" the ethernet ports while the B1 Mediatek revision has the USB port between DC in and below the ethernet ports. Am I correct in assuming that deployed hardware needs to match the FCC design exactly (that is, in case of revision a new FCC submission with new photos is required)?
>>
>> Best Regards
>>          Sebastian
>
>
>

-- 
Isaac Konikoff
Candela Technologies
konikofi@candelatech.com
Office: 360-380-1618
Mobile: 360-389-2453

Re: [Cerowrt-devel] [Bloat] Two d-link products tested for bloat...

[Jonathan Morton]

[-- Attachment #1: Type: text/plain, Size: 402 bytes --]

> Here's a comparison plot of box totals:
http://www.candelatech.com/downloads/rtt_fair4be-comparison-box-plot.png

That's a real mess. All of them utterly fail to get download bandwidth
anywhere near the upload (am I right in assuming it should ideally be about
equal?), and the only ones with even halfway acceptable latency are the
ones with least throughput in either direction.

- Jonathan Morton

[-- Attachment #2: Type: text/html, Size: 564 bytes --]

Re: [Cerowrt-devel] [Bloat] Two d-link products tested for bloat...

[Dave Taht]

On Wed, Feb 25, 2015 at 4:18 PM, Jonathan Morton <chromatix99@gmail.com> wrote:
>> Here's a comparison plot of box totals:
> http://www.candelatech.com/downloads/rtt_fair4be-comparison-box-plot.png
>
> That's a real mess. All of them utterly fail to get download bandwidth
> anywhere near the upload (am I right in assuming it should ideally be about
> equal?), and the only ones with even halfway acceptable latency are the ones
> with least throughput in either direction.

And I suspect that this was a test at the highest possible MCS rates
and txpower. Isaac?

>
> - Jonathan Morton



-- 
Dave Täht
Let's make wifi fast, less jittery and reliable again!

https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb

Re: [Cerowrt-devel] [Bloat] Two d-link products tested for bloat...

[Isaac Konikoff]

On 02/25/2015 04:23 PM, Dave Taht wrote:
> On Wed, Feb 25, 2015 at 4:18 PM, Jonathan Morton <chromatix99@gmail.com> wrote:
>>> Here's a comparison plot of box totals:
>> http://www.candelatech.com/downloads/rtt_fair4be-comparison-box-plot.png
>>
>> That's a real mess. All of them utterly fail to get download bandwidth
>> anywhere near the upload (am I right in assuming it should ideally be about
>> equal?), and the only ones with even halfway acceptable latency are the ones
>> with least throughput in either direction.
>
> And I suspect that this was a test at the highest possible MCS rates
> and txpower. Isaac?

Yes, highest MCS for each AP and fw defaulted tx power. I can experiment 
with attenuation and lower MCS rates as well.

>
>>
>> - Jonathan Morton
>
>
>

Re: [Cerowrt-devel] [Bloat] Two d-link products tested for bloat...

[Dave Taht]

On Wed, Feb 25, 2015 at 8:22 PM, Isaac Konikoff
<konikofi@candelatech.com> wrote:
>
>
> On 02/25/2015 04:23 PM, Dave Taht wrote:
>>
>> On Wed, Feb 25, 2015 at 4:18 PM, Jonathan Morton <chromatix99@gmail.com>
>> wrote:
>>>>
>>>> Here's a comparison plot of box totals:
>>>
>>> http://www.candelatech.com/downloads/rtt_fair4be-comparison-box-plot.png
>>>
>>> That's a real mess. All of them utterly fail to get download bandwidth
>>> anywhere near the upload (am I right in assuming it should ideally be
>>> about
>>> equal?), and the only ones with even halfway acceptable latency are the
>>> ones
>>> with least throughput in either direction.
>>
>>
>> And I suspect that this was a test at the highest possible MCS rates
>> and txpower. Isaac?
>
>
> Yes, highest MCS for each AP and fw defaulted tx power. I can experiment
> with attenuation and lower MCS rates as well.

Be prepared to be horrified in disbelief at your results at the lower
rates... and post them anyway.

I note that rtt_fair4be is a pretty stressful, artificial benchmark,
and to truly stress things out requires more
than one tcp flow per station in each direction, or attempting to also
exercise the 802.11e queues. Or interference. Or multicast.

I do believe, that once these enormous latencies are clobbered via
various techniques in make-wifi-fast that it is possible to get
bandwidth per station over tcp to degrade nearly linearly, and achieve
close to the theoretical rate of the air, and for latencies to remain
(on this 4 station test) typically in the 4-14ms range at all but the
lowest MCS rates.

IMHO an AP that one day does well on these tests will also do much
better on a variety of others. :)

btw, I show a detailed graph of TCP's actual behavior under
circumstances like these
at nearly every talk, with data taken on the actual conference wifi.
It never occurred to me once, to show the bar chart! (out of the 14+
plots available).

It might be helpful on your next test run to also do the simplest
tests to a single station over each AP
for a reference (tcp_upload, tcp_download, and tcp_bidirectional).

>>
>>>
>>> - Jonathan Morton
>>
>>
>>
>>
>



-- 
Dave Täht
Let's make wifi fast, less jittery and reliable again!

https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb

Re: [Cerowrt-devel] [Bloat] Two d-link products tested for bloat...

[Isaac Konikoff]

Something I'm not quite getting on the rtt_fair tests is that the upload 
and download labels do not look right for my test setup...how can I use 
netperf-wrapper better?

The lanforge box is sending and receiving all traffic with the AP under 
test in the middle, where eth1 to staX is download and staX to eth1 is 
upload.

So I setup the virtual sta's to associate with the AP, then run the 
following commands for the rtt_fair4be test:
netserver
netperf-wrapper -H sta1 -H sta2 -H sta3 -H sta4 --local-bind eth1 -x -t 
netgear6300 rtt_fair4be -f plot

However if I run a tcp_upload, tcp_download or tcp_bidirectional I can 
change the order of the arguments so that the upload/download labels 
match what each interface is reporting:

netperf-wrapper -H eth1 --local-bind sta1 -x -t netgear6300 tcp_download 
-f plot

Thanks for any help...

Isaac

On 02/25/2015 08:37 PM, Dave Taht wrote:
> On Wed, Feb 25, 2015 at 8:22 PM, Isaac Konikoff
> <konikofi@candelatech.com> wrote:
>>
>>
>> On 02/25/2015 04:23 PM, Dave Taht wrote:
>>>
>>> On Wed, Feb 25, 2015 at 4:18 PM, Jonathan Morton <chromatix99@gmail.com>
>>> wrote:
>>>>>
>>>>> Here's a comparison plot of box totals:
>>>>
>>>> http://www.candelatech.com/downloads/rtt_fair4be-comparison-box-plot.png
>>>>
>>>> That's a real mess. All of them utterly fail to get download bandwidth
>>>> anywhere near the upload (am I right in assuming it should ideally be
>>>> about
>>>> equal?), and the only ones with even halfway acceptable latency are the
>>>> ones
>>>> with least throughput in either direction.
>>>
>>>
>>> And I suspect that this was a test at the highest possible MCS rates
>>> and txpower. Isaac?
>>
>>
>> Yes, highest MCS for each AP and fw defaulted tx power. I can experiment
>> with attenuation and lower MCS rates as well.
>
> Be prepared to be horrified in disbelief at your results at the lower
> rates... and post them anyway.
>
> I note that rtt_fair4be is a pretty stressful, artificial benchmark,
> and to truly stress things out requires more
> than one tcp flow per station in each direction, or attempting to also
> exercise the 802.11e queues. Or interference. Or multicast.
>
> I do believe, that once these enormous latencies are clobbered via
> various techniques in make-wifi-fast that it is possible to get
> bandwidth per station over tcp to degrade nearly linearly, and achieve
> close to the theoretical rate of the air, and for latencies to remain
> (on this 4 station test) typically in the 4-14ms range at all but the
> lowest MCS rates.
>
> IMHO an AP that one day does well on these tests will also do much
> better on a variety of others. :)
>
> btw, I show a detailed graph of TCP's actual behavior under
> circumstances like these
> at nearly every talk, with data taken on the actual conference wifi.
> It never occurred to me once, to show the bar chart! (out of the 14+
> plots available).
>
> It might be helpful on your next test run to also do the simplest
> tests to a single station over each AP
> for a reference (tcp_upload, tcp_download, and tcp_bidirectional).
>
>>>
>>>>
>>>> - Jonathan Morton
>>>
>>>
>>>
>>>
>>
>
>
>

Re: [Cerowrt-devel] [Bloat] Two d-link products tested for bloat...

[Dave Taht]

I don't quite get what you mean. Can you mark what you want in gimp or
inkscape, and put it up somewhere?

(you can post edit the .pdf or .svg versions in inkscape)

On Thu, Feb 26, 2015 at 9:00 PM, Isaac Konikoff
<konikofi@candelatech.com> wrote:
> Something I'm not quite getting on the rtt_fair tests is that the upload and
> download labels do not look right for my test setup...how can I use
> netperf-wrapper better?
>
> The lanforge box is sending and receiving all traffic with the AP under test
> in the middle, where eth1 to staX is download and staX to eth1 is upload.
>
> So I setup the virtual sta's to associate with the AP, then run the
> following commands for the rtt_fair4be test:
> netserver
> netperf-wrapper -H sta1 -H sta2 -H sta3 -H sta4 --local-bind eth1 -x -t
> netgear6300 rtt_fair4be -f plot
>
> However if I run a tcp_upload, tcp_download or tcp_bidirectional I can
> change the order of the arguments so that the upload/download labels match
> what each interface is reporting:
>
> netperf-wrapper -H eth1 --local-bind sta1 -x -t netgear6300 tcp_download -f
> plot
>
> Thanks for any help...
>
> Isaac
>
>
> On 02/25/2015 08:37 PM, Dave Taht wrote:
>>
>> On Wed, Feb 25, 2015 at 8:22 PM, Isaac Konikoff
>> <konikofi@candelatech.com> wrote:
>>>
>>>
>>>
>>> On 02/25/2015 04:23 PM, Dave Taht wrote:
>>>>
>>>>
>>>> On Wed, Feb 25, 2015 at 4:18 PM, Jonathan Morton <chromatix99@gmail.com>
>>>> wrote:
>>>>>>
>>>>>>
>>>>>> Here's a comparison plot of box totals:
>>>>>
>>>>>
>>>>>
>>>>> http://www.candelatech.com/downloads/rtt_fair4be-comparison-box-plot.png
>>>>>
>>>>> That's a real mess. All of them utterly fail to get download bandwidth
>>>>> anywhere near the upload (am I right in assuming it should ideally be
>>>>> about
>>>>> equal?), and the only ones with even halfway acceptable latency are the
>>>>> ones
>>>>> with least throughput in either direction.
>>>>
>>>>
>>>>
>>>> And I suspect that this was a test at the highest possible MCS rates
>>>> and txpower. Isaac?
>>>
>>>
>>>
>>> Yes, highest MCS for each AP and fw defaulted tx power. I can experiment
>>> with attenuation and lower MCS rates as well.
>>
>>
>> Be prepared to be horrified in disbelief at your results at the lower
>> rates... and post them anyway.
>>
>> I note that rtt_fair4be is a pretty stressful, artificial benchmark,
>> and to truly stress things out requires more
>> than one tcp flow per station in each direction, or attempting to also
>> exercise the 802.11e queues. Or interference. Or multicast.
>>
>> I do believe, that once these enormous latencies are clobbered via
>> various techniques in make-wifi-fast that it is possible to get
>> bandwidth per station over tcp to degrade nearly linearly, and achieve
>> close to the theoretical rate of the air, and for latencies to remain
>> (on this 4 station test) typically in the 4-14ms range at all but the
>> lowest MCS rates.
>>
>> IMHO an AP that one day does well on these tests will also do much
>> better on a variety of others. :)
>>
>> btw, I show a detailed graph of TCP's actual behavior under
>> circumstances like these
>> at nearly every talk, with data taken on the actual conference wifi.
>> It never occurred to me once, to show the bar chart! (out of the 14+
>> plots available).
>>
>> It might be helpful on your next test run to also do the simplest
>> tests to a single station over each AP
>> for a reference (tcp_upload, tcp_download, and tcp_bidirectional).
>>
>>>>
>>>>>
>>>>> - Jonathan Morton
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>



-- 
Dave Täht
Let's make wifi fast, less jittery and reliable again!

https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb

Re: [Cerowrt-devel] [Bloat] Two d-link products tested for bloat...

[Isaac Konikoff]

It looks like the rtt-fair tests are designed to be run from a single 
sta to several host servers such as snapon.lab.bufferbloat.net which 
would make the local-bind be the sta. In this case, the upload is up and 
the download is down wrt to the sta.

In my case, I'm not using those host servers, I'm using eth1 and 
multiple sta's on the same box. So the -H option has the multiple sta's 
and eth1 is local-bind. In this case the upload direction is local-bind 
to -H or eth1 to sta which is really download.

So, it looks like I need to edit the wrapper conf to get the direction 
labels right for essentially a send-to-self test, or just ignore the 
labels for now.

Here are some example plots:
http://candelatech.com/downloads/rtt-fair-box.png
http://candelatech.com/downloads/tcp-down.png
http://candelatech.com/downloads/tcp-up.png



On 02/26/2015 09:12 PM, Dave Taht wrote:
> I don't quite get what you mean. Can you mark what you want in gimp or
> inkscape, and put it up somewhere?
>
> (you can post edit the .pdf or .svg versions in inkscape)
>
> On Thu, Feb 26, 2015 at 9:00 PM, Isaac Konikoff
> <konikofi@candelatech.com> wrote:
>> Something I'm not quite getting on the rtt_fair tests is that the upload and
>> download labels do not look right for my test setup...how can I use
>> netperf-wrapper better?
>>
>> The lanforge box is sending and receiving all traffic with the AP under test
>> in the middle, where eth1 to staX is download and staX to eth1 is upload.
>>
>> So I setup the virtual sta's to associate with the AP, then run the
>> following commands for the rtt_fair4be test:
>> netserver
>> netperf-wrapper -H sta1 -H sta2 -H sta3 -H sta4 --local-bind eth1 -x -t
>> netgear6300 rtt_fair4be -f plot
>>
>> However if I run a tcp_upload, tcp_download or tcp_bidirectional I can
>> change the order of the arguments so that the upload/download labels match
>> what each interface is reporting:
>>
>> netperf-wrapper -H eth1 --local-bind sta1 -x -t netgear6300 tcp_download -f
>> plot
>>
>> Thanks for any help...
>>
>> Isaac
>>
>>
>> On 02/25/2015 08:37 PM, Dave Taht wrote:
>>>
>>> On Wed, Feb 25, 2015 at 8:22 PM, Isaac Konikoff
>>> <konikofi@candelatech.com> wrote:
>>>>
>>>>
>>>>
>>>> On 02/25/2015 04:23 PM, Dave Taht wrote:
>>>>>
>>>>>
>>>>> On Wed, Feb 25, 2015 at 4:18 PM, Jonathan Morton <chromatix99@gmail.com>
>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>> Here's a comparison plot of box totals:
>>>>>>
>>>>>>
>>>>>>
>>>>>> http://www.candelatech.com/downloads/rtt_fair4be-comparison-box-plot.png
>>>>>>
>>>>>> That's a real mess. All of them utterly fail to get download bandwidth
>>>>>> anywhere near the upload (am I right in assuming it should ideally be
>>>>>> about
>>>>>> equal?), and the only ones with even halfway acceptable latency are the
>>>>>> ones
>>>>>> with least throughput in either direction.
>>>>>
>>>>>
>>>>>
>>>>> And I suspect that this was a test at the highest possible MCS rates
>>>>> and txpower. Isaac?
>>>>
>>>>
>>>>
>>>> Yes, highest MCS for each AP and fw defaulted tx power. I can experiment
>>>> with attenuation and lower MCS rates as well.
>>>
>>>
>>> Be prepared to be horrified in disbelief at your results at the lower
>>> rates... and post them anyway.
>>>
>>> I note that rtt_fair4be is a pretty stressful, artificial benchmark,
>>> and to truly stress things out requires more
>>> than one tcp flow per station in each direction, or attempting to also
>>> exercise the 802.11e queues. Or interference. Or multicast.
>>>
>>> I do believe, that once these enormous latencies are clobbered via
>>> various techniques in make-wifi-fast that it is possible to get
>>> bandwidth per station over tcp to degrade nearly linearly, and achieve
>>> close to the theoretical rate of the air, and for latencies to remain
>>> (on this 4 station test) typically in the 4-14ms range at all but the
>>> lowest MCS rates.
>>>
>>> IMHO an AP that one day does well on these tests will also do much
>>> better on a variety of others. :)
>>>
>>> btw, I show a detailed graph of TCP's actual behavior under
>>> circumstances like these
>>> at nearly every talk, with data taken on the actual conference wifi.
>>> It never occurred to me once, to show the bar chart! (out of the 14+
>>> plots available).
>>>
>>> It might be helpful on your next test run to also do the simplest
>>> tests to a single station over each AP
>>> for a reference (tcp_upload, tcp_download, and tcp_bidirectional).
>>>
>>>>>
>>>>>>
>>>>>> - Jonathan Morton
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
>
>
>

-- 
Isaac Konikoff
Candela Technologies
konikofi@candelatech.com
Office: 360-380-1618
Mobile: 360-389-2453