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

["Toke Høiland-Jørgensen" <toke@toke.dk>]

Sebastian Moeller <moeller0@gmx.de> writes:

> Hi Toke,
>
>
>> On Sep 7, 2019, at 00:50, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>> 
>> Sebastian Moeller <moeller0@gmx.de> writes:
>> 
>>> 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.
>> 
>> 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