On Mon, 18 Apr 2016, Dave Taht wrote:
On Mon, Apr 18, 2016 at 5:01 PM, David Lang <[email protected]> wrote:
On Mon, 18 Apr 2016, Dave Taht wrote:
(and there will be a large chunk
of airtime unused for various reasons, much of which you will not be able
to
attribute to any one station, and if you do get full transmit data from
each
station, you can end up with >100% airtime use attempted)
The "black" lines on the pie chart would represent the interframe gap,
you could use a color for "other things" like mgmt frames or
interference (if you have the data), go "grey" or transparent for
unused txops.
I really wanted to be able to show the "pulse" that multicast
powersave induces every ~250ms (could also use that to change the
chart to show what stations are active), and pulses like upnp and
other big pieces of multicast traffic can induce, also, by making the
whole pie chart flash for the actual duration it took, while the sweep
hand went 'round.
well, in the 'river' chart, such pulses are going to stand out as well
(assuming you are displaying things to a suitable resolution.
Trying to have them show up in a pie chart seems hard. Are you really going
to update the entire pie chart 4 times/sec? how is anyone going to see
what's what when things are changing that fast?
8 times/sec, and a human can deal with that.
not if they need to see any detail. let alone the 'max rate from their protocol
version vs rate actually used' and things like that.
However, slowing the
playback down by some factor like 10x would be useful. We had ways of
doing that in early versions of the web implementation of the flent
interpreter...
That work died a few years ago, but had some nice features on scaling
in and out on detail. Old repo here.
https://github.com/bipulkkuri/netperf-wrapper
Similarly, mu-mimo "soundings" - although they are very short, could
be shown, and I dunno how to show multiple stations going at once in
that mode.
(the spec suggests soundings be taken every 10ms (and take up to
500usec!!!), which is nuts. First you need per-station airtime
scheduling and queuing, then, IF you have MU-mimo capable stations
with data waiting for them, sound... and even then the only major
cases where I think this feature is going to help all that much is in
very, very dense environments, which have other problems)
I would be looking at a stacked area graph to show changes over time (a
particular source will come and go over time)
I would either do two graphs, one showing data successfully transmitted,
the
other showing airtime used (keeping colors/order matching between the two
graphs), or if you have few enough stations, one graph with good lines
between the stations and have the color represent the % of theoretical
peak
data transmission to show the relative efficiency of the different
stations.
Noted.
While the radar sweep updating of a pie graph is a neat graphic, it
doesn't
really let you see what's happening over time.
Disagree. At least on a testbench I'm pretty sure a "good" pattern
could be recognisable against other traffic.
what information do we need to test this?
AirCaps, mostly. You could try to get there from timestamps alone but
I doubt it would be all that useful.
if we are trying to get this from aircaps then we have multiple categories of
things.
1. time when nothing was sent, but it looks to us like the airtime could have
been used.
2. time when nothing was sent that we can understand, but we see enough signal
strength that we would not transmit
3. data we see sent, and can identify the sender, but it gets mangled
4. Data we see sent that we can understand, but that gets re-transmitted
5. Data we see sent and can understand, and is acked or at least not re-sent
note that with #2 and #3 other things (including the system being transmitted
to) may be able to understand the signal.
What we really need is hooks into the wifi stack to spit out what it sees
(transmitting and receiving) and then gather this info (via a different network
or after the fact) and correlate things together.
That's really the only way we are going to be able to tell the difference
between
microwave/cordless phone/other stations just barely too far away to unserstand
noise
something transmitted by station A to station B that B can't understand because
something tromped on it
something transmitted by station A to station B successfully
especially in high density environments.
David Lang
_______________________________________________
Bloat mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/bloat
