iperf 2.0.8 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.)

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.

[  3] 0.05-0.10 sec  1558200 Bytes  249312000 bits/sec   0.157 ms    0/ 1060 (0%)  1.985/ 1.098/ 3.219/ 0.473 ms 21280 pps

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:

[  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

It's assumed a higher level tool will parse and handle the histograms. Example plots might look like:

Bob

On Thu, May 5, 2016 at 7:08 PM, Aaron Wood <woody77@gmail.com> wrote:

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).

There are a LOT of assumptions made when QoS systems based on marked packets is used:

- That traffic X can starve others
- That traffic X is more/most important

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.

I know Dave has wanted an isochronous traffic tool that could simulate voip traffic (with in-band one-way latency/jitter/loss measurement capabilities).

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).

-Aaron Wood

_______________________________________________
Make-wifi-fast mailing list
Make-wifi-fast@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/make-wifi-fast