<div dir="ltr"><a href="https://sourceforge.net/projects/iperf2/">iperf 2.0.8</a> has microsecond end/end latencies per each report interval in mean/min/max/stdev for "end/end" latencies, use -e for enhanced reports.  Histograms/PDFs are in prototype stage (see below.)   Isochronous traffic is also being prototyped.   (The server will merelyindicate a jitter buffer overun/underrun to indicate a problem.)  <div><br></div><div>All of this does require synchronized clocks.   A quality oscillator to act as a PTP grandmaster can be found in the open market using various time sources or and OCXO can run in free wheeling mode.   I use a GPS disciplined oscillator from spectracom and it's been working great.   <div><br></div><div><pre style="color:rgb(0,0,0);word-wrap:break-word;white-space:pre-wrap">[  3] 0.05-0.10 sec  1558200 Bytes  249312000 bits/sec   0.157 ms    0/ 1060 (0%)  <b>1.985/ 1.098/ 3.219/ 0.473 ms</b> 21280 pps</pre></div><div><br></div><div>This above provides mean/min/max/stdev per every packet.  Though per the central limit theorem the underlying distribution is lost and sometimes the underlying distribution is needed.  Hence, a proposal is to support histograms, something like:</div><div><br></div><div><pre style="color:rgb(0,0,0);word-wrap:break-word;white-space:pre-wrap">[  3] 0.05-0.10 sec  PDF(bins/binsize=10k/10us, 10/90=137/261)=110:1 111:2 113:1 114:4 115:2 116:4 118:2 119:6 120:3 121:6 122:2 123:1 124:5 125:6 126:7 127:3 128:4 129:3 130:9 131:4 132:7 133:6 134:5 135:7 136:1 137:6 138:10 139:9 140:9 141:8 142:9 143:9 144:14 145:7 146:6 147:6 148:10 149:7 150:7 151:4 152:12 153:8 154:6 155:7 156:10 157:5 158:9 159:4 160:2 161:7 162:6 163:9 164:3 165:5 166:11 167:5 168:8 169:4 170:6 171:8 172:8 173:4 174:5 175:11 176:6 177:8 178:2 179:6 180:10 181:10 182:7 183:4 184:7 185:9 186:11 187:5 188:4 189:8 190:7 191:8 192:2 193:4 194:10 195:12 196:7 197:3 198:4 199:10 200:8 201:5 202:3 203:9 204:8 205:8 206:2 207:5 208:10 209:9 210:6 211:4 212:5 213:13 214:9 215:5 216:5 217:10 218:10 219:4 220:4 221:6 222:15 223:6 224:5 225:5 226:5 227:5 228:13 229:5 230:5 231:9 232:7 233:7 234:1 235:9 236:6 237:7 238:8 239:4 240:2 241:8 242:11 243:4 244:3 245:5 246:7 247:7 248:3 249:3 250:11 251:8 252:5 253:3 254:2 255:12 256:7 257:7 258:2 259:8 260:9 261:9 262:3 263:3 264:8 265:7 266:4 267:4 268:4 269:7 270:5 271:3 272:2 273:3 274:4 275:4 276:1 277:1 278:4 279:2 280:2 281:2 282:2 283:2 284:1 285:2 287:2 288:3 289:2 290:1 292:1 293:2 297:1 298:2 302:2 303:1 307:1 308:1 312:2 317:2 321:1 322:1</pre><div><br></div></div><div>It's assumed a higher level tool will parse and handle the histograms.   Example plots might look like: </div><div><br></div><div><img src="cid:ii_15483dccc28a0827" alt="Inline image 1" width="562" height="422"><br></div><div><img src="cid:ii_15483dd6777e50ce" alt="Inline image 1" width="562" height="422"><br></div><div><br></div><div>Bob</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 5, 2016 at 7:08 PM, Aaron Wood <span dir="ltr"><<a href="mailto:woody77@gmail.com" target="_blank">woody77@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 dir="ltr">I saw Dave's tests on WMM vs. without, and started thinking about test setups for systems when QoS is in use (using classification, not just SQM/AQM).<div><br></div><div>There are a LOT of assumptions made when QoS systems based on marked packets is used:</div><div><br></div><div>- That traffic X can starve others</div><div>- That traffic X is more/most important</div><div><br></div><div>Our test tools are not particularly good at anything other than hammering the network (UDP or TCP).  At least TCP has a built-in congestion control.  I've seen many UDP (or even raw IP) test setups that didn't look anything like "real" traffic.</div><div><br></div><div>I know Dave has wanted an isochronous traffic tool that could simulate voip traffic (with in-band one-way latency/jitter/loss measurement capabilities).  </div><div><br></div><div>What other tools do we need, for replicating traffic types that match how these QoS types in wifi are meant to be used?  I think we're doing an excellent job of showing how they can be abused.  Abusing is pretty easy, at this point (rrul, iPerf, etc).</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>-Aaron Wood</div></font></span></div>
<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></blockquote></div><br></div>