Sebastian Moeller <moell...@gmx.de> writes: > 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,
That would be less straight-forward, though, because then we can't just pass in /dev/urandom. Besides, for TCP you can already identify the packets based on the 5-tuple (since you're supposedly doing this manually anyway ;)). > but really which uploads actually use compression? Tunnels, mostly... >>> 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. Certainly not opposed to adding this support to Flent if it materialises in irtt :) -Toke _______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat