From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 19C813CB36; Fri, 6 Sep 2019 13:59:25 -0400 (EDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1567792763; bh=7t1o5O61GwKQmmHVs95Oxmr+0zncVR8ZFm9/ru7SakU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=P18aQD9pHoamAiFJXyLWot8lFVlliCnBZfGzzapPdEct3QIdD8E3D00kO3fmJnsxW qYzX3EmYdQStU14IIQ10H87GR62u0AgxEXFClh2KeX6xiXrCg5SdiWsbBjqW0+LBH2 MGtnhq76rDg/KtZh9+ezNhVnqZwtrQrPb+rpW7jLcZTSjG9VQrrqeoqSNHKbPSE1bc KQdP5BAZGtsxNJLQd6weBEue4GcEO2EDoSe2a/uo3DWP6tDvfmaculbvJBoHx7bxhN LTuZpIt+TmIKtX9GO/+XSZeSFRgmUauLCHcDgfop+09IhIXITNXJIdCtmSKyjBVMOT pGmf0+ze3ngow== To: Sebastian Moeller Cc: Mikael Abrahamsson , Matt Taggart , cerowrt-devel , bloat@lists.bufferbloat.net In-Reply-To: <63E4F227-7BC3-4238-B3F2-8B57118AAFD1@gmx.de> References: <874l1p25ka.fsf@toke.dk> <63E4F227-7BC3-4238-B3F2-8B57118AAFD1@gmx.de> Date: Fri, 06 Sep 2019 18:59:21 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87ef0tz4p2.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Cerowrt-devel] [Bloat] Ubiquiti Launches a Speed Test Network X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2019 17:59:25 -0000 Sebastian Moeller writes: > Hi Toke, > >> On Sep 6, 2019, at 10:27, Toke H=C3=B8iland-J=C3=B8rgensen wrote: >>=20 >> Mikael Abrahamsson writes: >>=20 >>> On Wed, 4 Sep 2019, Matt Taggart wrote: >>>=20 >>>> So an interesting idea but they have some things they could improve. >>>=20 >>> I've been considering what one should run in parallel with the speed te= st=20 >>> to get an impression if the speedtest impacts performance of other flow= s /=20 >>> realtime flows, similar to what dslreports speedtest does. >>>=20 >>> I've considered running one or several simulated voip calls (50pps) and= =20 >>> record RTT, PDV, packet loss etc for this session. >>>=20 >>> It would be interesting to hear any suggestions people have for a fairl= y=20 >>> simple codebase that does this that can be included in these kinds of t= est=20 >>> clients (both server and client end, and of course one that protects=20 >>> against reflection attacks etc). >>>=20 >>> iperf3 can be used for this, but from what I can see the iperf3 server= =20 >>> code isn't very friendly to multiple parallel tests or even resilient=20 >>> against hung clients that doesn't close the test nicely. >>>=20 >>> I also considered using WebRTC or VoIP libraries, does anyone know what= =20 >>> RTT/PDV/packet loss data can be extracted from some common ones? >>=20 >> 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: >>=20 >> 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... -Toke