From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 0B7693CB36; Fri, 6 Sep 2019 18:56:30 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1567810576; bh=llFdTMOJKF56UAmTaIHo7H6/mayFMiO2OgxMSY12asQ=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=EkIqrEjQjBEEs1t61xkrns/HN0iv14h4LLWLbw3zlHFJcP8b9uvwzLqjavLnG9X9o 2lhEl6z/LNflBSYqNEdJ0311ZymP2CAlWfRKTmZLCdxs3n9QXyXmjI7tNfiNygoUqO MMP6iLfQ0K/a49XTtla9F1drPhgzEnhc0ptZmR2o= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from hms-beagle2.lan ([77.181.49.56]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MYfJW-1hawOw2Wna-00VMTV; Sat, 07 Sep 2019 00:56:16 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Sebastian Moeller In-Reply-To: <875zm5yr8m.fsf@toke.dk> Date: Sat, 7 Sep 2019 00:56:13 +0200 Cc: Mikael Abrahamsson , Matt Taggart , cerowrt-devel , bloat@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: References: <874l1p25ka.fsf@toke.dk> <63E4F227-7BC3-4238-B3F2-8B57118AAFD1@gmx.de> <87ef0tz4p2.fsf@toke.dk> <875zm5yr8m.fsf@toke.dk> To: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= X-Mailer: Apple Mail (2.3445.104.11) X-Provags-ID: V03:K1:L4om8nqO4FOAEQyXBd54rnSw5/n1vPlPEsbtetVmau2L3dAOgmJ y6AssI9jO6CjPTYhmaHBBr0tMrIgE0HYeNVNujnaFwW/jsRl3GwSXaLI+CfQmwf9cmozhCd NCGK+46S7a436EuIiSZQfp7vGPE0AkIj9ihG9NXxP8faGx7t+LdBhbkpRgdl2NHQ/UcawgB z7s2VA2c9psmLVj+/CKDQ== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:V80L9wkx8p0=:KF2iddVUh8gMsWl7c9XrDM May5ELzqjjhLqiBrxcza4ueOWYPrXQS7MJkCKM6pzr4lxoua7Sze+E6P+aL/9Vb7jU87OIrvi kFIIEp9VB5xG7iPp7uQQ4i6gHg80gjbLhUJqq9lwwi20XeYJw604AG0fa9ZaFxKkpHJQ3LCsP vbsBU7egiat7PVBWF95T48FSNO1TF+h2VW5e9oicYBomGOvGW1+gWduY7toTm1Eg0wux6dJ+X ODxgI36bBCFMH/luOeNBn8bLlvI5qjCkrEhJdm/s+cjDbKe8drT/pBeM8ckNOAVE00OAoXTLB AE9datTZGXTz4jse5Y8IZ5JZAatHKPdCHS8hGz0qKv/FKAUJhZEWOdK0tAEDmMblyRo5THU4L QIUpTXjibYwDGwWf8+7bP0BMF8bZou7IQI10/ckIkskYwWgOhQsLcRTo63rxExa6kTow9Bwkf TvebV6Dgk+wkp5JK0Jb1CtHeSohAVEE9vw7Th9AGecsUqtZ9mZliYa81YxiCaJbEiAon5ScJf IEj+gwTD2NbCBTc5sMgg5D4lw/0t93ohPjAMQDB/kfUPQWPJYqfcHKd3z+9QDojcUXnLWYmYR rv9i0fDd/9aj6pg79bk6NN5PYndDQvgaWDrolpudJVwRKT25ZWDjRd+NlTTlSVSDD7L1ocxbN 4yLKTVM6m/j1oKyuQ82W9gDK5rDIS8aHboUHbdlr01YKSk9Qq1HV94frzTG8ECN0MZUCXHeJL odOCFjT4rDelMFKgWqZrdmqAoIyN65OdxgKgMTKeblxOXAwN8j/xZU6hWZluCpamQEeuO+51b wNGmR2YHVNCUMzTNfdOBimeOh+dB+zDmAATNNS3q7Vpvf0Y9g1dzhqeKGNLrl55YwIBcbvS7s FHA9kdsQ2MudzX+ZfmswowPuujWgSNBbgoRjanQ2/t83Q5XvbAaWe/wmn375jcb/DJ0DLqyoD RDFKRIG3AQIath1WOKJ4ZCMO/jKy/3XJrYCpNAV+QRhlCQXV7Oak5DrGQuH+rzQMxIURQBgWR w/cAqk/ep1LizEZZqbZdKzwGb5UsRic7IZlbTjpO4YlHlvMMPDrNaa7JaMux2UzIvQuQPetb4 vpgBFZwWZEtMzpmjJMi45MCy+elZTB3Le2eAxDZbT/aeXaJptj8QB7jipJdw5MPQlC5EmCDbQ TpZg9EdT4lHjiPJx7cbmz9KAFX8A3BBehzB08c4I39oPqoIVkJCGqt8bxlJDBXNqtMB+VsWET IEado+TcKVKAijKz1 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:56:31 -0000 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 = 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 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 = fairly=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 = 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 >>>>=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 >> =46rom man ping (on linux): >> -p pattern >> You may specify up to 16 ``pad'' bytes to fill out the = packet 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 >> =46rom man ping (macosx 10.14): >> -p pattern >> You may specify up to 16 ``pad'' bytes to fill out the = packet 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 >> =46rom man netperf (not sure how this wirks for servers): >> -F fill_file >> Pre-fill the send buffers with data from the named file. = This is intended to provide a means for avoid- >> ing buffers that are filled with data which is trivially = easy 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, but really which uploads actually use compression? >=20 >> =46rom 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 >=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. >=20 >> 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? >=20 > Well, I'm sorta skeptical that anyone would actually look at those > packet dumps ;) Oh, I promise I will do this, occasionally ;) Best Regards Sebastian