Hi Toke,
> On Sep 7, 2019, at 00:50, Toke Høiland-Jørgensen <t...@toke.dk> wrote: > > 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... Yes, unfortunatley. > >> 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 Well, we could do 8 bytes DSCP in ASCII followed by ~1498Bytes randomness, but really which uploads actually use compression? > >> 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. Sama as above, but maybe Pete could be convinced to do the read back of the first X bytes automatically. > >> 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 ;) Oh, I promise I will do this, occasionally ;) Best Regards Sebastian _______________________________________________ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
