Re: [Cerowrt-devel] [Bloat] Ubiquiti Launches a Speed Test Network

[Sebastian Moeller <moeller0@gmx.de>]

Hi Toke,


> On Sep 6, 2019, at 19:59, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
> 
> Sebastian Moeller <moeller0@gmx.de> writes:
> 
>> Hi Toke,
>> 
>>> On Sep 6, 2019, at 10:27, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>>> 
>>> Mikael Abrahamsson <swmike@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