Hi Toke,
> On Sep 6, 2019, at 19:59, Toke Høiland-Jørgensen <t...@toke.dk> wrote: > > 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... From man ping (on linux): -p pattern You may specify up to 16 ``pad'' bytes to fill out the packet you send. This is useful for diagnosing data-depen‐ dent problems in a network. For example, -p ff will cause the sent packet to be filled with all ones. From man ping (macosx 10.14): -p pattern You may specify up to 16 ``pad'' bytes to fill out the packet you send. This is useful for diagnosing data-dependent problems in a network. For example, ``-p ff'' will cause the sent packet to be filled with all ones. With fping I come up empty From man netperf (not sure how this wirks for servers): -F fill_file Pre-fill the send buffers with data from the named file. This is intended to provide a means for avoid- ing buffers that are filled with data which is trivially easy to compress. A good choice for a file that should be present on any system is this manpage - netperf.man. Other files may be provided as part of the distribution.: (so this would require us to distribute/generate 63 files for each dscp?) From irtt help client: --fill=fill fill payload with given data (default none) none: leave payload as all zeroes rand: use random bytes from Go's math.rand pattern:XX: use repeating pattern of hex (default 69727474) --fill-one fill only once and repeat for all packets --sfill=fill request server fill (default not specified) see options for --fill server must support and allow this fill with --allow-fills This might actually work, and if it required a packetdump to compare DSCP and intended DSCP that would already be much better than what we have today, no? > > -Toke _______________________________________________ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
