iperf 2.0.8 <https://sourceforge.net/projects/iperf2/> 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:

[image: Inline image 1]
[image: Inline image 1]

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