Sebastian Moeller <moell...@gmx.de> writes: > 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.
Yeah, but you can't read back the output... > 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?) We're already using -F /dev/urandom to prevent the netperf data from being compressible... And also, this cannot be read back. > 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 As above, we're doing --fill=rand today. > 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? Well, I'm sorta skeptical that anyone would actually look at those packet dumps ;) _______________________________________________ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
