Sebastian Moeller <moell...@gmx.de> writes: > Hi Toke, > >> On Sep 6, 2019, at 10:27, Toke Høiland-Jørgensen <t...@toke.dk> wrote: >> >> Mikael Abrahamsson <swm...@swm.pp.se> writes: >> >>> On Wed, 4 Sep 2019, Matt Taggart wrote: >>> >>>> So an interesting idea but they have some things they could improve. >>> >>> I've been considering what one should run in parallel with the speed test >>> to get an impression if the speedtest impacts performance of other flows / >>> realtime flows, similar to what dslreports speedtest does. >>> >>> I've considered running one or several simulated voip calls (50pps) and >>> record RTT, PDV, packet loss etc for this session. >>> >>> It would be interesting to hear any suggestions people have for a fairly >>> simple codebase that does this that can be included in these kinds of test >>> clients (both server and client end, and of course one that protects >>> against reflection attacks etc). >>> >>> iperf3 can be used for this, but from what I can see the iperf3 server >>> code isn't very friendly to multiple parallel tests or even resilient >>> against hung clients that doesn't close the test nicely. >>> >>> I also considered using WebRTC or VoIP libraries, does anyone know what >>> RTT/PDV/packet loss data can be extracted from some common ones? >> >> Pete coded up this wonderful tool for UDP-based latency testing; it's >> even supported in Flent, and available on some (all?) the public-facing >> servers: >> >> https://github.com/heistp/irtt > > This reminds of a tangentially related question, do we/could we > actually write the requested DSCP into the packet payloads so we could > see/display dscp bleaching/remapping packets experience during > transit? For irtt, ping and even netperf TCP/UDP flows?
irtt could definitely do this; not sure if it does. Ping and Netperf, probably not... -Toke _______________________________________________ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
