From: Pete Heist <peteheist@gmail.com>
To: make-wifi-fast@lists.bufferbloat.net
Subject: Re: [Make-wifi-fast] Wiring up a wireless testbed
Date: Sat, 4 Nov 2017 15:05:53 +0100 [thread overview]
Message-ID: <B199D107-BD63-4D23-BD36-528B964CA2B7@gmail.com> (raw)
In-Reply-To: <mailman.928.1509802426.3609.make-wifi-fast@lists.bufferbloat.net>
> Date: Fri, 03 Nov 2017 23:51:05 +0100
> From: Toke Høiland-Jørgensen <toke@toke.dk>
> To: make-wifi-fast@lists.bufferbloat.net
> Subject: [Make-wifi-fast] Wiring up a wireless testbed
> Message-ID: <87tvybm0x2.fsf@toke.dk>
> Content-Type: text/plain
>
> Since I had to (physically) move my wireless testbed recently, I had to
> figure out a way to run reliable WiFi experiments in a cramped server
> room. I ended up wiring everything up instead of running over the air,
> and documented the process here, in case anyone wants to replicate it:
>
> https://blog.tohojo.dk/2017/11/building-a-wireless-testbed-with-wires.html
>
> Also, if anyone sees any fatal flaw in that setup, please do let me know :)
That looks really nice, especially for reproducing and fixing software bugs. I’d second Aaron’s comments that what you get here is repeatability at the expense of not seeing things you see in the real world, which you’re probably aware of.
As an example of what I’ve seen, in the 2.4 GHz band with my OM2P-HS routers running LEDE, I sometimes see CTS protection suddenly flipping on or off in the middle of tests, changing throughput and results considerably. It doesn’t help that one distant neighbor seems to be using 40 MHz channels, so I’m sometimes struggling to find clear 2.4 GHz spectrum, but this is what can happen in the real world anyway.
Unfortunately, I don’t think I can replicate this “wired wireless" setup in my test closet at the moment, because none of my six APs (NanoStation M5s or OM2P-HSs) have external antenna connectors. Nor do the older MacBooks I started using for clients in point-to-multipoint testing. I’m not sure I’ll even do much more point-to-multipoint testing because of how disastrously the results vary between runs, or if I do, I sense it’s going to consume a lot of time. :)
next parent reply other threads:[~2017-11-04 14:05 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.928.1509802426.3609.make-wifi-fast@lists.bufferbloat.net>
2017-11-04 14:05 ` Pete Heist [this message]
2017-11-03 22:51 Toke Høiland-Jørgensen
2017-11-03 23:03 ` Aaron Wood
2017-11-03 23:33 ` Bob McMahon
2017-11-04 21:48 ` Toke Høiland-Jørgensen
2017-11-05 1:50 ` Bob McMahon
2017-11-05 1:56 ` Bob McMahon
2017-11-05 2:04 ` Bob McMahon
2017-11-04 21:46 ` Toke Høiland-Jørgensen
2017-11-04 21:56 ` Aaron Wood
2017-11-04 22:08 ` Toke Høiland-Jørgensen
2017-11-04 7:35 ` Dane Medic
2017-11-04 21:51 ` Toke Høiland-Jørgensen
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=B199D107-BD63-4D23-BD36-528B964CA2B7@gmail.com \
--to=peteheist@gmail.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