From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 300533CB36; Fri, 6 Sep 2019 14:33:30 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1567794794; bh=hMobBQjUVa9FS+yX+Glxe6Q/bOBS6qolmjH9NwWBsiY=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=Mucnpz6xTImjNcG7u4VXxID6GrVt159glcPU5mN0+T+nemAvj5BX9KVwf3j6Xn913 zMkl4pVQ0zdHRSlexeBiVIrP+Dl4L0EdywsbvfgCp7LJfr/g8iSJn0WJilBCumPVRd 2qCpONRGmd5QzhcGsHy3Tpqw397TCr/eKwvJmzF4= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from hms-beagle2.lan ([77.185.127.96]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0LdZAI-1iVysV47hy-00ikNT; Fri, 06 Sep 2019 20:33:14 +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: <87ef0tz4p2.fsf@toke.dk> Date: Fri, 6 Sep 2019 20:33:06 +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> To: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= X-Mailer: Apple Mail (2.3445.104.11) X-Provags-ID: V03:K1:Y/cJZgW0HJv5UgUb/7cvf12n635mmekGQSUKbqMh05majn0Li2t MXxNB2XE8umHwUkHrpwycEykrUpwmk6OTyeQTvgve8f2yvDQKWf8wEGEhc2R4w4IlmjLx+g SMSp7hsBHqZkJ/2r8CSk/st6u3nEGwFUpW5bsZ9tPzX7MflLJk0P2uNmsuAPQ0s+khVfvDe 2V8CEHUbPiyVlyoMuR3Jg== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:nBo5nPt0jjk=:i1jsaNoJqEVB3WCfX+9UmR SgxojC5HqeORY1ZEwoIUQgOVZcD2XlGwb8pos/NORvVjKzAZ2Oq4w+7XAt4M5FyUmlfO0TQNd YLVCY0fAQnY1bN4gRGdB6If877aEuvjGsZDHBgSUX5Y9ew1SOm1mM5EP9XOJr8lu99uJR3Z0i EAczSldjr8kyxl9JTvaXUV5icLOBlQj+ElUyF3vct6dUNbnbpeoyBr9aaksWpjj0M/Xln8Q5r 8NB7ZhclmHgYP4IRuOUy2nI6w+X9LCcZEjVRI8MsgRsZWIDYFZfdGa5HXdfiny7CGy1+NSkcB s+frvQ+bBLbGnyPAf7Aan0UwRKWmp3bztrLcDrh0Ezw7B37wOTHY06yZVH8BzYpzF6rtg+cYD K/indQI6Yyv6Ja9AT5/XmtG2beu2nSg8/KU8ifm71EjREqJZBxCgIMUU0aCTLh6TJUF6xDSCD s+0o0/wKSyjtndS4LMpHYsM7X0Wfh4ZxMfecn1/d1CizeOYDq/Uqv9LbEItVxj+r9if3/WFam Js4UbHsvbIWfJwG047JfLwdywnVuVYhtk6RVqm70+HkX63XAukWDYWtOIiGwRjPOV6I4Dl9Ki jqY8yysqNgcVWZJ4a5xFVS6E1HVpb9Ha71O9mnpier263PHB487jqsAt7IozhmEMLZTgP5KiW 6ze0NFL9ggnOLegfUfgRi0pktVU4sldmuQMDsq5LO3G0lhQwEtyAuxn3RMb854U+wi6YIyxo5 SgHN4+18hJg/y0YYaizIz8wwuqgnpDhYSQ7xhqagE50nUTSzbWVhUakpqVdTO6R43+wgPCqyO n96yRQHCoDL6QLUaRVC3CSAAa/DcQMd9SwCYTKaCZKHzkpmLDn2woms8nsg3sGDt5em9Y8RXd AoJE5Ya957pQKjzbyaT7PU2ccSMLRl//Jq7QF6oo/vOiKO7Z5VQsuwxGELI/yQlXrN2Tysnpu tzyeKHh2Wd1f2/9e5P19NgIzl7N+At/RnzpN2Gztk+mPBF7nPke2Yzj4VfloHZy7jyTE4JvsX NVkH7he9h6KyXSQfCWvcSr0Jqx97+CRvqBC9xUWaTSoa8u/P83QBwTn73+ISGOjWmsihgA3DL 7Dl7QMUEnt3LzIgTkw3t7xgj/cRO/HGggmbRHHIvgJqSukCiCAkv5ohdhdUtInqQqHQh7JJSw CYt8q9yie5r0ndVeeMsNz2LlAGp5IJf2n+26eJqQjh7Ork5QXofRO3UBYdKVaYjW6OvEIOpcE FyG9l8rR4Fn1k7cgk 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 18:33:30 -0000 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 = 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... =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. =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. With fping I come up empty =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?) =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 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 > -Toke