From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp72.ord1c.emailsrvr.com (smtp72.ord1c.emailsrvr.com [108.166.43.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 07A8E3B29E for ; Thu, 16 May 2019 12:40:15 -0400 (EDT) Received: from smtp2.relay.ord1c.emailsrvr.com (localhost [127.0.0.1]) by smtp2.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id BD58EC026F; Thu, 16 May 2019 12:40:14 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=g001.emailsrvr.com; s=20190322-9u7zjiwi; t=1558024814; bh=4dTo5aKIXQykwlQbOSeV+x5ghgZX/RI/EeEEAnExNpY=; h=Subject:From:Date:To:From; b=UVEbfWhcxXdgIJtXoQHy2nhNV6xsoQ7SRRioFk86pg+au6M8MkXgrY/3GZaZAyxaY DMuY+fl1Oz370U8FCyZJJ4aWsa0z8i5SWzV/FfJunWdFCHItMgfgxnuVbArR9+9cuw fOxX6l6rm9wFb1mQXHVh9H/emTHIFAPgcnwCEKno= X-Auth-ID: jf@jonathanfoulkes.com Received: by smtp2.relay.ord1c.emailsrvr.com (Authenticated sender: jf-AT-jonathanfoulkes.com) with ESMTPSA id 371E5C02F7; Thu, 16 May 2019 12:40:14 -0400 (EDT) X-Sender-Id: jf@jonathanfoulkes.com Received: from jonathans-mbp.lan (h179.160.141.67.dynamic.ip.windstream.net [67.141.160.179]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Thu, 16 May 2019 12:40:14 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) From: Jonathan Foulkes X-Priority: 3 (Normal) In-Reply-To: <25460D05-4F53-4317-9722-2878B160BD7B@gmx.de> Date: Thu, 16 May 2019 12:40:13 -0400 Cc: "David P. Reed" , Rich Brown , cerowrt-devel , bloat Content-Transfer-Encoding: quoted-printable Message-Id: <46519182-D358-458B-AE2B-CDD5B26E93D7@jonathanfoulkes.com> References: <2936.1557856670@turing-police> <1557859131.759530583@apps.rackspace.com> <1557871532.754117608@apps.rackspace.com> <87lfz81x7b.fsf@toke.dk> <1557876841.69888745@apps.rackspace.com> <25460D05-4F53-4317-9722-2878B160BD7B@gmx.de> To: Sebastian Moeller X-Mailer: Apple Mail (2.3445.104.8) Subject: Re: [Bloat] (no subject) X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2019 16:40:15 -0000 > @Jonathan from your experience how tricky is it to get reliable = speedtest endpoints and how reliable are they in practice. And do you do = any sanitization, like take another measure immediate if the measured = rate differs from the last by more than XX% or something like that? It is tricky to get the profiling of a line right. For one, access to = the test endpoints need to be managed so concurrency does not swamp the = server/link capacity, otherwise the test results are suspect. You = don=E2=80=99t know if measured capacity was limited due to link = constraints or server capacity. We spent a good bit of time engineering = our capacity testing infrastructure and process to the point of where it = is quite reliable in terms of metrics. Multiple measurements over time are required to correctly profile a = line. Generally, early morning (4am or so) tests find the high-water = mark on most lines. As discussed elsewhere, another challenge as line capacity goes up, is = where the source of the test is run from. On-router testing is fine for = sub-100mbps, but becomes more and more of challenge as speeds go up. = Testing a Gbps line using an in-router process takes a pretty beefy box = in terms of CPU and NICs. Best regards, Jonathan > On May 15, 2019, at 3:31 AM, Sebastian Moeller = wrote: >=20 > Hi All, >=20 >=20 > I believe the following to be relevant to this discussion: = https://apenwarr.ca/log/20180808 > Where he discusses a similar idea including implementation albeit = aimed at lower bandwidth and sans the automatic bandwidth tracking. >=20 >=20 >> On May 15, 2019, at 01:34, David P. Reed wrote: >>=20 >>=20 >> Ideally, it would need to be self-configuring, though... I.e., = something >> like the IQRouter auto-measuring of the upstream bandwidth to tune = the >> shaper. >=20 > @Jonathan from your experience how tricky is it to get reliable = speedtest endpoints and how reliable are they in practice. And do you do = any sanitization, like take another measure immediate if the measured = rate differs from the last by more than XX% or something like that? >=20 >=20 >>=20 >> Sure, seems like this is easy to code because there are exactly two = ports to measure, they can even be labeled physically "up" and "down" to = indicate their function. >=20 > IMHO the real challenge is automated measurements over the internet at = Gbps speeds. It is not hard to get some test going (by e.g. tapping into = ookla's fast net of confederated measurement endpoints) but getting = something where the servers can reliably saturate 1Gbps+ seems somewhat = trickier (last time I looked one required a 1Gbps connection to the = server to participate in speedtest.net, obviously not really suited for = measuring Gbps speeds). > In the EU there exists a mandate for national regulators to establish = and/or endorse an anointed "official" speedtests, untended to keep ISP = marketing honest, that come with stricter guarantees (e.g. the official = German speedtest, breitbandmessung.de will only admit tests if the = servers are having sufficient bandwidth reserves to actually saturate = the link; the enduser is required to select the speed-tier giving them a = strong hint about the required rates I believe). > For my back-burner toy project "per-packet-overhead estimation on = arbitrary link technology" I am currently facing the same problem, I = need a traffic sink and source that can reliably saturate my link so I = can measure maximum achievable goodput, so if anybody in the list has = ideas, I am all ears/eyes. >=20 >>=20 >> For reference, the GL.iNet routers are tiny and nicely packaged, and = run >> OpenWrt; they do have one with Gbit ports[0], priced around $70. I = very >> much doubt it can actually push a gigabit, though, but I haven't had = a >> chance to test it. However, losing the WiFi, and getting a slightly >> beefier SoC in there will probably be doable without the price going >> over $100, no? >>=20 >> I assume the WiFi silicon is probably the most costly piece of = intellectual property in the system. So yeah. Maybe with the right parts = being available, one could aim at $50 or less, without sales channel = markup. (Raspberry Pi ARM64 boards don't have GigE, and I think that = might be because the GigE interfaces are a bit pricey. However, the = ARM64 SoC's available are typically Celeron-class multicore systems. I = don't know why there aren't more ARM64 systems on a chip with dual GigE, = but I suspect searching for them would turn up some). >=20 > The turris MOX (https://www.turris.cz/en/specification/) might be a = decent startimg point as it comes with one Gbethernet port and both a = SGMII and a PCIe signals routed on a connector, they also have a 4 and = an 8 port switch module, but for our purposes it might be possible to = just create a small single Gb ethernet port board to get started.=20 >=20 > Best Regards > Sebastian >=20 >>=20 >> -Toke >>=20 >> [0] https://www.gl-inet.com/products/gl-ar750s/ >> _______________________________________________ >> Cerowrt-devel mailing list >> Cerowrt-devel@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/cerowrt-devel >=20 > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat