From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 4B3E03B29E; Thu, 16 May 2019 18:12:59 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1558044775; bh=H+ZyIFvpvr48iIaoUzOySYzC9Yh/qWnlDaU0sadN/Fg=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=KpCnSbvE/es3pMPXB04kWKcq3pZ/c1y9C/3S0BqErcxs5hKdDqi8x6mzDv7ozDpPk 9PqPuBmuGCuYD7ApXv3rMZZyP18pgZbEwb84xNQ75IARxjSY99kB4Kw8EKxThdd4fK n2KpF6zL2y5EBgP2wPc0N5qMkeD8WBF4x8hJkA6Q= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from hms-beagle2.lan ([77.190.94.213]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0Lta9E-1gi3xD2TMi-010sYA; Fri, 17 May 2019 00:12:55 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Sebastian Moeller X-Priority: 3 (Normal) In-Reply-To: <46519182-D358-458B-AE2B-CDD5B26E93D7@jonathanfoulkes.com> Date: Fri, 17 May 2019 00:12:54 +0200 Cc: "David P. Reed" , Rich Brown , cerowrt-devel , bloat Content-Transfer-Encoding: quoted-printable Message-Id: 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> <46519182-D358-458B-AE2B-CDD5B26E93D7@jonathanfoulkes.com> To: Jonathan Foulkes X-Mailer: Apple Mail (2.3445.104.11) X-Provags-ID: V03:K1:mKH0gjGp6qemj183RV6kuzcKS8mTgcBhvjLSZgpdhH3YRl7fTp9 Sni/UX86j4N4jKSDErdw4sUfI7sKo9DlpTjEaRQFmpQ2pxDQwBwFqC9c0ZnOG2ORuOGMUaH 1aAi1ZP9Qbv1LZijSDVEHuLlMxZfM+J2xeNhsqyLYkJJxC+Bx1KbALY3bSvJ1HO0S/2u5cf NWsNSrABrl/9BlfnHjmEw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:zNQ6PIevM3c=:BcHBm97PFJ86/eGmqMRwHK r6RvNxquxj7ZzPxFyrbshKpMFUamT//1VP97IVQGOjPVLiO45gcH7ydlRlvDmFi4bCeDwbmWG p3BftHCd63ZVTkT1B0JbSseU+8fJdJ+F+FWtzYnKQfKNIiUahod7S7tFUEsiJYDdz4MBuFoq1 fXm+sZyUd0++OePR1V2RnwqLBVDDT9jWN1uEOTCA3UL/HSuYAZjFCsb2IN/v2Ye8ZmrQE6u1d pt8htgxW61VBWkDkt539x8I67VSQl9KamMC44RyJbZr2igoPtrV/S1u4h0HkJsnD4jnsYcZYQ sFRsncWnO9FFqUcmL+mlmaqAZhR813FLyIFdBWObwhg3n20OO4JD5NgrDuItSmtc5znPuL1dY /4QCI/cEsr9QfPU8oGhoGozd0ipgLn46agT4mfn5thxVNAn+WHDMcPbJ+YdHZSyMww4BTwoFE cVru5QQ479KxlHPfL66+Ir/dvkUVWVVt8CtBsffGzYSSydcUdXqUF7kgZOuFCk/LOBUUm1iru wAN+BwJ8Jer9sd8K1LAYY4ERahsZq87tytauD0bFRcQV9YYunitWONwguKqbilN0IbpWssCb9 D3l8tvKXY4JZsGhdYKzCPBGps/oMXhWzf1nhq2WIe9N8r8u5nfYUFOMw4GG7IIQBjSNZ8UJ6m UwGf/icao1nxJ+ZvI27EijhgPhJ/HnVGRE14XO49gvGJ3DgNbynT/2WzapZDMOtYO46cM48gM NidKYr8K65g8oIQeBOsGNY3ure+n+uLaos0HG+WPbadtCk9gGf0n63w+Kl/XCzdNW4k/+bKf0 lyjfd85c1oH+coXxvgOZFpaUf7jKL0ez1lbBG4LFlvxJI8z7pxQ+Lp2XFhoeRY2QkJ8CbWjMn LmalVl6H08p9v6ykhc3dnqnwWuRzQ46vkYZ4qWVYtMtNt6huoBY4cSg1QC0Uqq0CvJkUSuwqX //iLhfWJMUTVYrgOWjq+JFU2w7Zh/k4JJmedNa/N8lUbcL0mIOdJK 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 22:12:59 -0000 Hi Jonathan, thanks for your isights, it is always good to talk to folks (or would = that be foulkes) that actually implemented an idea ;) > On May 16, 2019, at 18:40, Jonathan Foulkes = wrote: >=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 > 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. Ah, I was reading similar things for the German regulators = official speedtest site and wondered how often that does cause issues in = reality; thanks to your data point I understand this is not just a = theoretical concern. >=20 > 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. Again, thanks for sharing, while obvious post-hoc, not something = I would have looked for (I would have given way more importance to the = most recent measurement; clearly demonstrating that I have not actually = tried to implement something like this ;) ). >=20 > 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. Great; that certainly puts a somewhat higher lower performance = bound on devices to be useful for David's idea, the CPU(s) need to be = beefy enough to both shape at Gbps speeds as well as actually generate = enough traffic to saturate the link.... Again thanks a lot for sharing! Best Regards Sebastian >=20 > Best regards, >=20 > Jonathan >=20 >> 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 >=20