<div dir="ltr">On a statistician - I've been learning from Shashi <font color="#000000" face="Arial, Helvetica, FreeSans, sans-serif">Sathyanarayana of <a href="http://www.numericinsight.com/Home.html">Numeric Insight</a> with an intention of using machine learning techniques (<a href="https://en.wikipedia.org/wiki/Principal_component_analysis">PCA,</a> etc.) applied to both network traffic and wi-fi traffic.   </font><div><font color="#000000" face="Arial, Helvetica, FreeSans, sans-serif"><br></font></div><div><span style="color:rgb(0,0,0);font-family:Arial,Helvetica,FreeSans,sans-serif;font-size:13px"><i>Shashi Sathyanarayana Ph.D, the founder of Numeric Insight, Inc has spent more than a decade accumulating expertise in scientific programming, algorithm development and teaching.</i></span></div><div><span style="color:rgb(0,0,0);font-family:Arial,Helvetica,FreeSans,sans-serif"><br></span></div><div><span style="color:rgb(0,0,0);font-family:Arial,Helvetica,FreeSans,sans-serif">Things are still in the early stages of prototyping so if there are specific needs not mentioned in the current threads it would be interesting to know them.  </span></div><div><span style="color:rgb(0,0,0);font-family:Arial,Helvetica,FreeSans,sans-serif"><br></span></div><div><span style="color:rgb(0,0,0);font-family:Arial,Helvetica,FreeSans,sans-serif">(A current project is clustering rig results per the frequency responses and spatial streams eigemnmodes, i.e. learn per multiple test rigs phy characteristics which should allow for scaling</span><span style="color:rgb(0,0,0);font-family:Arial,Helvetica,FreeSans,sans-serif">.  Thought this has to be done per controlled PHY environments.)</span><br></div><div><div><font color="#000000" face="Arial, Helvetica, FreeSans, sans-serif"><br></font></div><div><font color="#000000" face="Arial, Helvetica, FreeSans, sans-serif">With respect to per UDP packet latency, the end/end is already in 2.0.8.  Realtime scheduling and kernel RX timestamping is used if the host supports them (well, except for Mac OS X where that part of the code is still not complete.)   </font></div><div><font color="#000000" face="Arial, Helvetica, FreeSans, sans-serif"><br></font></div><div><font color="#000000" face="Arial, Helvetica, FreeSans, sans-serif">Something others might find helpful is the ability to insert microsecond timestamps inside a UDP payload as packets move through a subsystem.  It might be a good idea to standardize this if its of interest to the larger group.   Here's an example where there is the end/end timestamp and five contributing timestamps.  The client inserts a tag on write to trigger timestamp insertion and the server will produce the subgrouped mean/min/max/stdev and a PDFs per each report.  A higher level tool then can plot them for either human visualizations or machine analysis.</font></div><div><font color="#000000" face="Arial, Helvetica, FreeSans, sans-serif"><br></font></div><div><pre style="color:rgb(0,0,0);word-wrap:break-word;white-space:pre-wrap">11:12:35.158  HNDLR UDP-rx     [  3] 0.10-0.15 sec  1467060 Bytes  234729600 bits/sec   1.972 ms   45/ 1043 (4.3%)  2.322/ 1.224/ 3.664/ 0.534 DHD: 2.317/ 1.219/ 3.656/ 0.534 FW1: 1.900/ 1.209/ 2.994/ 0.310 FW2: 4.772/ 4.109/ 8.120/ 0.304 FW3:32.626/ 0.169/64.681/18.486 FW4: 1.389/ 0.946/ 2.075/ 0.215 ms 19787 pps (4357Bif,file8)
<br></pre><pre style="color:rgb(0,0,0);word-wrap:break-word;white-space:pre-wrap">11:12:35.161  HNDLR UDP-rx     [  3] 0.10-0.15 sec  PDF:ToT(bins/size=10k/10us,10/90=170/308)=123:1 124:1 127:2 128:1 129:1 130:1 132:6 133:2 134:2 135:2 136:2 137:6 138:3 139:2 140:1 141:3 142:6 143:3 144:4 146:6 147:5 148:4 149:3 150:2 151:6 152:5 153:5 154:2 155:9 156:5 157:8 158:5 160:4 161:6 162:4 163:3 164:2 165:4 166:6 167:4 168:1 169:4 170:5 171:4 172:4 173:4 174:3 175:4 176:5 177:3 178:5 179:2 180:6 181:6 182:3 183:5 184:5 185:6 186:4 187:1 188:5 189:4 190:5 191:6 192:2 193:6 194:6 195:7 196:5 197:4 198:5 199:5 200:9 201:2 202:6 203:4 204:5 205:9 206:4 207:8 208:5 209:5 210:6 211:5 212:7 213:6 214:8 215:4 216:8 217:5 218:8 219:6 220:4 221:8 222:4 223:6 224:8 225:6 226:7 227:3 228:10 229:3 230:7 231:6 232:7 233:7 234:3 235:12 236:5 237:6 238:7 239:6 240:9 241:4 242:12 243:3 244:12 245:4 246:4 247:7 248:4 249:6 250:6 251:10 252:6 253:4 254:6 255:6 256:7 257:7 258:7 259:8 260:3 261:6 262:3 263:8 264:3 265:10 266:6 267:4 268:9 269:3 270:8 271:6 272:10 273:4 274:3 275:10 276:3 277:7 278:4 279:6 280:9 281:4 282:6 283:3 284:7 285:5 286:5 287:7 288:4 289:7 290:2 291:6 292:5 293:4 294:7 295:5 296:6 297:4 298:4 299:4 300:4 301:4 302:2 303:5 304:4 305:5 306:3 307:5 308:9 309:3 310:5 311:2 312:2 313:3 314:3 315:3 316:1 317:3 318:3 319:1 320:5 321:2 322:5 324:1 325:1 326:3 327:2 329:2 331:1 332:2 333:1 334:1 336:2 338:1 341:2 343:2 345:1 347:1 348:1 350:1 353:1 355:1 357:1 359:1 362:1 364:1 367:1  (4357Bif,file8)
<br></pre><pre style="color:rgb(0,0,0);word-wrap:break-word;white-space:pre-wrap">...</pre><pre style="color:rgb(0,0,0);word-wrap:break-word;white-space:pre-wrap">[snipped secondary histograms]</pre><pre style="color:rgb(0,0,0);word-wrap:break-word;white-space:pre-wrap">Bob</pre></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, May 7, 2016 at 2:49 PM, Dave Taht <span dir="ltr"><<a href="mailto:dave.taht@gmail.com" target="_blank">dave.taht@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Sat, May 7, 2016 at 9:50 AM, Dave Taht <<a href="mailto:dave.taht@gmail.com">dave.taht@gmail.com</a>> wrote:<br>
> On Thu, May 5, 2016 at 7:08 PM, Aaron Wood <<a href="mailto:woody77@gmail.com">woody77@gmail.com</a>> wrote:<br>
>> I saw Dave's tests on WMM vs. without, and started thinking about test<br>
>> setups for systems when QoS is in use (using classification, not just<br>
>> SQM/AQM).<br>
>><br>
>> There are a LOT of assumptions made when QoS systems based on marked packets<br>
>> is used:<br>
>><br>
>> - That traffic X can starve others<br>
>> - That traffic X is more/most important<br>
>><br>
>> Our test tools are not particularly good at anything other than hammering<br>
>> the network (UDP or TCP).  At least TCP has a built-in congestion control.<br>
>> I've seen many UDP (or even raw IP) test setups that didn't look anything<br>
>> like "real" traffic.<br>
><br>
> I sat back on this in the hope that someone else would jump forward...<br>
> but you asked...<br>
><br>
> I ran across this distribution today:<br>
> <a href="https://en.wikipedia.org/wiki/Rayleigh_distribution" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Rayleigh_distribution</a> which looks closer<br>
> to reflecting the latency/bandwidth problem we're always looking at.<br>
><br>
> I found this via this thread:<br>
> <a href="https://news.ycombinator.com/item?id=11644845" rel="noreferrer" target="_blank">https://news.ycombinator.com/item?id=11644845</a> which was fascinating.<br>
><br>
> I have to admit I have learnt most of my knowledge of statistics<br>
> through osmosis and by looking at (largely realtime) data that does<br>
> not yield to "normal" distributions like gaussian. So, rather than<br>
> coming up with useful methods to reduce stuff to single numbers, I<br>
> rely on curves and graphs and being always painfully aware of how<br>
> sampling intervals can smooth out real spikes and problems, and try to<br>
> convey intuition... and the wifi industry is wedded to charts of "rate<br>
> over range for tcp and udp". Getting to rate+latency over range for<br>
> those variables would be nice to see happen in their test tools....<br>
><br>
> There is another distribution that andrew was very hot on a few years<br>
> ago: <a href="https://en.wikipedia.org/wiki/Tracy%E2%80%93Widom_distribution" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Tracy%E2%80%93Widom_distribution</a><br>
><br>
> I thought something like it could be used to look at basic problems in<br>
> factoring in (or factoring out) header overheads, for example.<br>
><br>
> It would be good if we had a good statistician(s) "on staff"... or<br>
> there must be a whole set of mathematician's mailing lists somewhere,<br>
> all aching to dive into a more real-world problem?<br>
><br>
>> I know Dave has wanted an isochronous traffic tool that could simulate voip<br>
>> traffic (with in-band one-way latency/jitter/loss measurement capabilities).<br>
><br>
> d-itg, for which flent has some support for, "does that" but it's a<br>
> pita to setup and not exactly safe to use over the open internet.<br>
><br>
> *Yes*, the fact that the current rrul test suite and most others in<br>
> flent do not have an isochronous baseline measurement  - and uses a<br>
> rtt-bound measurement instead - leads to very misleading comparison<br>
> results when the measurement traffic gets a huge latency reduction.<br>
> Measurement traffic thus becomes larger - and the corresponding<br>
> observed Bandwidth in most flent tests drops, as we are only measuring<br>
> the bulk flows, not the measurement, nor the acks.<br>
><br>
> using ping-like traffic was "good enough", when we started, and were<br>
> cutting latencies by orders of magnitude on a regular basis, but, for<br>
> example, I just showed a long term 5x latency reduction for stock wifi<br>
> vs michal's patches at 100mbit - from 100ms to 20ms or so, and I have<br>
> no idea how the corresponding bandwidth loss is correlated. In a<br>
> couple tests the measurement flows also drop into another wifi hw<br>
> queue entirely (and I'm pretty convinced that we should always fold<br>
> stuff into the nearest queue when we're busy, no matter the marking)<br>
><br>
> Anyway, I'm digesting a ton of the short term results we got from the<br>
> last week of testing michal's patches...<br>
><br>
> (see the cerowrt blog github repo and compare the stock vs fqmac35<br>
> results on the short tests). I *think* that most of the difference in<br>
> performance is due to noise on the test (the 120ms burps downward in<br>
> bandwidth caused by something else) , and some of the rest can be<br>
> accounted for by more measurement traffic, and probably all the rest<br>
> due to dql taking too long to ramp up.<br>
><br>
> The long term result of the fq_codel wifi patch at the mac80211 layer<br>
> was *better* all round, bandwidth stayed the same, latency and jitter<br>
> got tons better. (if I figure out what was causing the burps - they<br>
> don't happen on OSX, just linux) - anyway comparing the baseline<br>
> patches to the patch here on the second plot...<br>
><br>
> <a href="http://blog.cerowrt.org/post/predictive_codeling/" rel="noreferrer" target="_blank">http://blog.cerowrt.org/post/predictive_codeling/</a><br>
><br>
> Lovely stuff.<br>
><br>
> But the short term results were noisy and the 10s of seconds long dql<br>
> ramp was visible on some of those tests (sorry, no link for those yet,<br>
> it was in one of michal's mails)<br>
><br>
> Also (in flent) I increasingly dislike sampling at 200ms intervals,<br>
> and would prefer to be getting insights at 10-20ms intervals. Or<br>
> lower! 1ms would be *perfect*. :) I can get --step-size in flent down<br>
> to about 40ms before starting to see things like fping "get behind" -<br>
> fixing that would require changing fping to use fdtimers to fire stuff<br>
> off more precisely than it does, or finding/writing another ping tool.<br>
><br>
> Linux fdtimers are *amazing*; we use those in tc_iterate.c.<br>
><br>
> Only way I can think about getting down below 5ms would be to have<br>
> better tools for looking at packet captures. I have not had much<br>
> chance to look at "teacup" as yet. tcptrace -G + <a href="http://xplot.org" rel="noreferrer" target="_blank">xplot.org</a> and<br>
> wireshark's tools are as far as I go. Any other tools for taking apart<br>
> captures out there? In particulary, aircaps of wifi traffic,<br>
> retransmits, rate changes have been giving me enough of a headache to<br>
> want to sit down and tear apart them with wireshark's lua stuff... or<br>
> something.<br>
><br>
> It would be nice to measure latencies in bulk flows, directly.<br>
><br>
> ...<br>
><br>
> I've long figured if we ever got to the basic isochronous test on the<br>
> 10ms interval I originally specified, that we'd either revise the rrul<br>
> related tests to suit (the rrul2016 "standard"),  or create a new set<br>
> called "crrul" - "correct rrul".<br>
><br>
> We have a few isochronous tests to choose from. there are d-itg tests<br>
> in the suite that emulate voip fairly well. The show-stopper thus far<br>
> has been that doing things like that (or iperf/netperfs udp flooding<br>
> tests) are unsafe to use on the general internet, and I wanted some<br>
> form of test that negotiated a 3 way handshake, at least, and also<br>
> enforced a time limit on how long it sent traffic.<br>
><br>
> That said, to heck with it for internal tests as we are doing now.<br>
><br>
> We have a few simpler tools than d-itg that could be built upon. Avery<br>
> has the isoping tests which I'd forked mildly at one point, but never<br>
> got around to doing much with. There's also things like what I was<br>
> calling "twd" that I gave up on, and there's a very prisice<br>
<br>
</div></div>precise "owamp" thing, part of the internet2 project. I had used it<br>
for a while (had a parser for it, even, because I preferred the raw<br>
data). I had basically forgotten about it because it is not packaged<br>
up for debian, and<br>
has a few issues with 64 bit platforms that I meant to poke into.<br>
<br>
I did enjoy trying to get it running a few minutes ago.<br>
<br>
root@dancer:/usr/local/etc# owampd<br>
owampd[19846]: WARNING: No limits specified.<br>
owampd[19846]: Running owampd as root is folly!<br>
owampd[19846]: Use the -U option! (or allow root with the -f option)<br>
<br>
<a href="http://software.internet2.edu/owamp/details.html" rel="noreferrer" target="_blank">http://software.internet2.edu/owamp/details.html</a><br>
<br>
I think I'd (or stephen walker) had packaged it up for cerowrt, but as<br>
we never got gps's into the hands of enough users (and my testbeds<br>
were largely divorced from the internet) I let the idea slide. Toke's<br>
testbed has fully synced time.<br>
<br>
now that gpses are even more cheap (like a raspi pi hat), hmm....<br>
<br>
Grump, it doesn't compile on aarch64....<br>
<br>
...<br>
<br>
There is something of a great divide between us and the perfsonar project.<br>
<br>
They use iperf, not netperf, they work on fedora, not ubuntu...<br>
<br>
and last I recall they were still stuck at linux 2.6.32 or somesuch.<br>
<br>
anyone booted that up lately?<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
>><br>
>> What other tools do we need, for replicating traffic types that match how<br>
>> these QoS types in wifi are meant to be used?  I think we're doing an<br>
>> excellent job of showing how they can be abused.  Abusing is pretty easy, at<br>
>> this point (rrul, iPerf, etc).<br>
><br>
> :) Solving for abuse is useful, I think, also.<br>
><br>
> Solving for real traffic types like HAS and videoconferencing would be better.<br>
><br>
> Having a steady, non-greedy flow (like a basic music or video stream)<br>
> test would be good.<br>
><br>
> I'd love to have a 3-5 flow HAS-like test to fold into the others.<br>
><br>
> I was unaware that iperf3 can output json, am not sure what else can<br>
> be done with it.<br>
><br>
> We had tried to use the web10g stuff at one point but the kernel<br>
> patches were too invasive. A lot of what was in web10g has probably<br>
> made it into the kernel by now, perhaps we can start pulling out more<br>
> complete stats with things like netstat -ss or TCP_INFO?<br>
><br>
> Incidentally - I don't trust d-itg very far. Could use fdtimers, could<br>
> use realtime privs.<br>
><br>
>> -Aaron Wood<br>
>><br>
>> _______________________________________________<br>
>> Make-wifi-fast mailing list<br>
>> <a href="mailto:Make-wifi-fast@lists.bufferbloat.net">Make-wifi-fast@lists.bufferbloat.net</a><br>
>> <a href="https://lists.bufferbloat.net/listinfo/make-wifi-fast" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/listinfo/make-wifi-fast</a><br>
>><br>
><br>
><br>
><br>
> --<br>
> Dave Täht<br>
> Let's go make home routers and wifi faster! With better software!<br>
> <a href="http://blog.cerowrt.org" rel="noreferrer" target="_blank">http://blog.cerowrt.org</a><br>
<br>
<br>
<br>
--<br>
Dave Täht<br>
Let's go make home routers and wifi faster! With better software!<br>
<a href="http://blog.cerowrt.org" rel="noreferrer" target="_blank">http://blog.cerowrt.org</a><br>
_______________________________________________<br>
Make-wifi-fast mailing list<br>
<a href="mailto:Make-wifi-fast@lists.bufferbloat.net">Make-wifi-fast@lists.bufferbloat.net</a><br>
<a href="https://lists.bufferbloat.net/listinfo/make-wifi-fast" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/listinfo/make-wifi-fast</a><br>
</div></div></blockquote></div><br></div>