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

[Sebastian Moeller <moeller0@gmx.de>]

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?


Best Regards
	Sebastian

> 
> -Toke
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat