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 CCC203CB36; Fri, 6 Sep 2019 19:12:38 -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=1567811557; bh=AZ1UC1BkDDlV0eZooJvTzMc8+4vWMflzyT+i/xxf0a8=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=KRPPzdND4uj1NlKx40xyxRJkB2dwG6W/ox9Cpi9fbc5TEjLIjlgWnNbYIFS1i8boP yF+Md5xD8bJf8EusxZtfyydWodo/Cvpga9JCTBQZwTN0VbTeIaJx3o8/L4coEhbz/f huiH2TnniKL9pb5nO7tH7xrXsFbkJrMON8xbvzKvrTt45LfVRJv8oWAp1NI7/wb/4v UmPnLPPjiRiPZ5iWL/ZGTQAQ5wIQdy+X6JwJ928U+lfSRLN9m8BrwDONMgrgRPvekv LzBa4umGyekWjPiSdqw63yoQnjOhY9E/VbmVeWmB6xlpV+v31D4ltYr/bhcwRxO/xo i5RJ4Akt/s6ag== 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> <875zm5yr8m.fsf@toke.dk> Date: Sat, 07 Sep 2019 00:12:35 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87lfv1xbmk.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 23:12:39 -0000 Sebastian Moeller writes: > Hi Toke, > > >> On Sep 7, 2019, at 00:50, Toke H=C3=B8iland-J=C3=B8rgensen wrote: >>=20 >> Sebastian Moeller writes: >>=20 >>> Hi Toke, >>>=20 >>>=20 >>>> 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 improv= e. >>>>>>>=20 >>>>>>> I've been considering what one should run in parallel with the spee= d test=20 >>>>>>> to get an impression if the speedtest impacts performance of other = flows /=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 f= airly=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 protect= s=20 >>>>>>> against reflection attacks etc). >>>>>>>=20 >>>>>>> iperf3 can be used for this, but from what I can see the iperf3 ser= ver=20 >>>>>>> code isn't very friendly to multiple parallel tests or even resilie= nt=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-fac= ing >>>>>> 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... >>>=20 >>> From man ping (on linux): >>> -p pattern >>> You may specify up to 16 ``pad'' bytes to fill out the pac= ket 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. >>>=20 >>> From man ping (macosx 10.14): >>> -p pattern >>> You may specify up to 16 ``pad'' bytes to fill out the pack= et 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. >>=20 >> Yeah, but you can't read back the output... > > Yes, unfortunatley. > >>=20 >>> With fping I come up empty >>>=20 >>> From man netperf (not sure how this wirks for servers): >>> -F fill_file >>> Pre-fill the send buffers with data from the named file. T= his is intended to provide a means for avoid- >>> ing buffers that are filled with data which is trivially e= asy 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= ?) >>=20 >> 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=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 6972747= 4) >>> --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 >>=20 >> As above, we're doing --fill=3Drand 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