Hi Toke,
> On Sep 6, 2019, at 10:27, Toke Høiland-Jørgensen <[email protected]> wrote:
>
> Mikael Abrahamsson <[email protected]> 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
> [email protected]
> https://lists.bufferbloat.net/listinfo/bloat
_______________________________________________
Bloat mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/bloat
