From: Dave Taht <dave.taht@gmail.com>
To: "David P. Reed" <dpreed@deepplum.com>
Cc: Make-Wifi-fast <make-wifi-fast@lists.bufferbloat.net>
Subject: Re: [Make-wifi-fast] Anyone got a view on this?
Date: Sat, 11 Apr 2020 19:05:07 -0700 [thread overview]
Message-ID: <CAA93jw66a+g7jc_Xpk+iQvM30o4nkdbEYxOZzfgDnJE+q+BJ8w@mail.gmail.com> (raw)
In-Reply-To: <1586653525.57076088@apps.rackspace.com>
On Sat, Apr 11, 2020 at 6:05 PM David P. Reed <dpreed@deepplum.com> wrote:
>
> https://techxplore.com/news/2020-04-wireless-networks.html
MIT still is good at PR, unlike us.
Yer the one that handed them their ass on your prior paper review.
(and me, privately, I handed 'em their ass on the quality of their
result vs a vs modern fq_codel on wifi (post "ending the anomaly"),
since they didn't compare against the real deal, seemingly
specifically picking a kernel that pre-dated our work - and I view the
trace results they use as entirely useless). the actual paper
presented is probably this one:
https://www.usenix.org/system/files/nsdi20-paper-goyal.pdf
I only skimmed it briefly. no running code, non-reproduceable results, traces...
Rather than compare against fq_codel, they ripped out a real wifi
emulation entirely, and did codel with cubic rather than fq_codel.
They got a glow on from getting published after multiple tries. And
then there's the totally artificial test setup...
"Our emulated cellular network experiments used a mini-mum RTT of 100
ms and a buffer size of 250 MTU-sized pack-ets. Additionally, ABC’s
target rate calculation (Equation(1))usedη=0.98andδ=133ms. Our Wi-Fi
implementationuses the link rate estimator from §5, while our emulated
cel-lular network setup assumes the realistic scenario that
ABC’srouter has knowledge of the underlying link capacity [1"
Uh, huh.
PLEASE NOTE: That said, I like the simplifying conceptualization of
ECT(1) equals accellerate in abc, *with* a transport that thinks that
way. it's sort of inbetween the SCE concept and the L4S DCTCP concept
and may well have a bit of promise. But lacking code...
One of these days having the war with real results with real tech vs
academia might seem worthwhile, but, me, I'm still got a glow on from
actually seeing the ath10k finally behave.
https://forum.openwrt.org/t/aql-and-the-ath10k-is-lovely/59002
only cost us 4 years of life, that.... so many other chips to fix...
I really, really, really used to have way more respect for MIT and
academia than I do today. I really wish they'd produced results
against our more modern openwrt implementation and published source
code. As it is it feels like they are not advancing or being true to
the goals of real science. For all I know, by us knocking it so far
out of the park with "ending the anomaly", no academic will cite it or
compare against it because they can't do better. Just ignore it. Am I
grumpy about this? you betcha... do I feel like writing a paper or
letter to the editor? I don't really know the right way to fight an
academic battle. Never learned. What's the right response? "Dear
USENIX, you do your readers a disservice by allowing a paper that made
claims about wifi to not do any coherent comparison with "ending the
anomaly", published a few years prior, containing code that seems to
outperform it by a large margin, and the current default in the linux
kernel"?
Prefer just to ship code....
I kind of feel that way also when stanford keeps insisting on still
teaching CS244 with a ludicrously small buffersize relative to what's
being observed in the field, also. And then people clone that course
thinking it represents some reality. And the recent buffersizing
workshop... oh, don't get me started. It's makework. Keeping a problem
alive to keep the grant money coming.
>
> _______________________________________________
> Make-wifi-fast mailing list
> Make-wifi-fast@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/make-wifi-fast
--
Make Music, Not War
Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-435-0729
next prev parent reply other threads:[~2020-04-12 2:05 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-12 1:05 David P. Reed
2020-04-12 2:05 ` Dave Taht [this message]
2020-04-12 16:31 ` David P. Reed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/make-wifi-fast.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAA93jw66a+g7jc_Xpk+iQvM30o4nkdbEYxOZzfgDnJE+q+BJ8w@mail.gmail.com \
--to=dave.taht@gmail.com \
--cc=dpreed@deepplum.com \
--cc=make-wifi-fast@lists.bufferbloat.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox