From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.toke.dk (mail.toke.dk [IPv6:2a00:7660:6da:2001::664]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 168BC3CB36; Fri, 6 Sep 2019 18:50:05 -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=1567810202; bh=4TvB91HHRhxOfXqyIZKb4lnLzjLUv5u1CjVi/qtP9KY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=jKwFvDAgUKZsj4vm7tSUfSgkgTtvBCwDAnzciyNPalFwifvu2PT1Vqu5AncQtLcR7 R9LxyxfAbHfrlaN219DUZyXvkry0VlbrTLXjyqt59qwc0Shx5fQWWFfA5KbF8ykVJg 5RI2VK9qKozjSyiGXmJ70x5BeoQsZGVPJG2i88jTTcHy+zOuVt0Nx6SLawPi5NyP3p 3CcpnaCH4cMo5zfWfitOJ5L3Ada3g4DljlqLJuro8hLUWhNFs1mCx711gHD5mbCbLp KMM0CQoH4qStIzisw4wyrARAgYMdXwsQjXWf5gHZmB4+4iRs4foOKMbaq2isZWsYIQ evGSsTFSOvWGw== To: Sebastian Moeller Cc: Mikael Abrahamsson , Matt Taggart , cerowrt-devel , bloat@lists.bufferbloat.net In-Reply-To: References: <874l1p25ka.fsf@toke.dk> <63E4F227-7BC3-4238-B3F2-8B57118AAFD1@gmx.de> <87ef0tz4p2.fsf@toke.dk> Date: Fri, 06 Sep 2019 23:50:01 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <875zm5yr8m.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 22:50:05 -0000 Sebastian Moeller writes: > Hi Toke, > > >> On Sep 6, 2019, at 19:59, Toke H=C3=B8iland-J=C3=B8rgensen wrote: >>=20 >> Sebastian Moeller writes: >>=20 >>> Hi Toke, >>>=20 >>>> 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 = test=20 >>>>> to get an impression if the speedtest impacts performance of other fl= ows /=20 >>>>> realtime flows, similar to what dslreports speedtest does. >>>>>=20 >>>>> I've considered running one or several simulated voip calls (50pps) a= nd=20 >>>>> record RTT, PDV, packet loss etc for this session. >>>>>=20 >>>>> It would be interesting to hear any suggestions people have for a fai= rly=20 >>>>> simple codebase that does this that can be included in these kinds of= test=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 serve= r=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 wh= at=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 >>>=20 >>> 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? >>=20 >> 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 pack= et you send. This is useful for diagnosing data-depen=E2=80=90 > 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 packe= t 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... > 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. Th= is is intended to provide a means for avoid- > ing buffers that are filled with data which is trivially ea= sy to compress. A good choice for a file that > should be present on any system is this manpage - netperf.m= an. 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. > From irtt help client: > --fill=3Dfill 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=3Dfill 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=3Drand today. > 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? Well, I'm sorta skeptical that anyone would actually look at those packet dumps ;)