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 3E5B53B2A4; Wed, 15 May 2019 04:30:56 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1557909052; bh=ZwwUTXAERuuiCdL1/E/vnxE1NA16mfvCkzKSqohCZHU=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=cKTyprfpcQLX13RMg/ywpgllMvopSMaxCaY9lWT5BoGeZrrGxS7H1GNksZuizTafY z2sPFfaELtG4II2ROnQrbDXExvMSf+Yb3PwAC9WCQex/u5mRCvtjiqmPsOFKfpNmxO qmuo1AeyxDzAcBkUP209JeNKgKyahnUBu0lwVF74= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [172.17.3.45] ([134.76.241.253]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MeU4s-1gsaUK2N0u-00aUyA; Wed, 15 May 2019 10:30:52 +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: Date: Wed, 15 May 2019 10:30:51 +0200 Cc: "David P. Reed" , Jonathan Foulkes , Rich Brown , cerowrt-devel , bloat Content-Transfer-Encoding: quoted-printable Message-Id: <4127D694-1872-40F2-A42E-4F805AFA8895@gmx.de> 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: =?utf-8?Q?Dave_T=C3=A4ht?= X-Mailer: Apple Mail (2.3445.104.11) X-Provags-ID: V03:K1:IQjCpsk7BTafgDilDL2fHdlZExNHnasm1iVP3mj9PIOk7HmnHWT W6z5hqZzfgvopu0cIqmPk8+Sw6medFfoG0Ezi/wIdEsMtnqUwu7bmkxs7GI3SxSYJp9fBD6 ql5HPIPu7fLjaxtEbzDmKjJyk9w+wlxyrdJ1H9SshigTk8t6qtokFF2D1q+2S9j9EIrseeu pekdXvquGYdjqI3M6XQPA== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:GRSWSXraKto=:VgBqJOthm9srbIkSCCdamR fbl5kxyz4ifSIwwGusbMzfxeOB32TF4rXjsXgKzpBb5TyMAezSbXhHig+I7vRNoyy7VG1QM9K 71R61LNxXM4L4Pz51YrSj6+PNNnof6myHfOEl3sN5IPjRpkoT9MKIUfX4BY2HWmB5H0X7PQxo kCQYR50zIl2Dmh59R1h+vaq/f4w8d6tdhg5dT93X510PjFba3Ln7NmtbhK+nYRnvRkBPdufb1 p876dV+kCJ9hYoo0Af1lEYY2LLmgGTdddWB1J3YzBg4AQnmzgWD2f+D/GwbN7RrNsep1rZisr jST0IVNewz8vQNJ8R+xtrlNlMY+6NOB/zO9ZduMgIYuXU1QND6cLZLIxwwkll55FTH8RXKhUh pbN7k8RmDfpzjjkEE8VgS+KeCAebPQnqJxP3uhEtZJ+AZqnfM5Tr3iPr1EXxZ1izUV5X0+L0E EGrNBtF7YxgZeJwYO5hUz4bLWsQaL1biq9av7NH1SGuuRkVeM4Kta/BwOG19tbZ0qPKED5t1e BYYziVRNYxR7fr5k2JhvHSJxDv8YEbMJKOYoJNQ77nKJ+hlyuSDm0M9nv9Myg3FFO+p6rrvAO 3TwO/RGWv5+olph3NF9NFEZ9BFfASOR/Fa+6EYsZW6yWVlKzZK0V0oXai/+voh4zcDjkQJLYN djhb/sfkpIjacSkQ2P3d2rxenN29F2R/2AkcJugphHz1Djw1EfuCeEJ4yWXlu2oC6SoLAzTEk Y/PewkOGZEUqk2DnKTNM++C6OltPR5OXilRHHUb2e2O6QMhrqcRgOrEx/1mbi53UcGKfCf/uT F5RRszlQ/r2Rmc0b3tQFGQ249eiENhxa9vJImtt/qipcl0NkZDw3TE4fk/FwoBI2OBMTIJ4rt 6bRHGIgjIg+pPgeizPqjarMuWQKhNHNVPLdCWAwAy6h3KaHxdglVaJqj1nxZ3qOagXvfOC+iB quKiHbR6LYg== Subject: Re: [Cerowrt-devel] [Bloat] (no subject) 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: Wed, 15 May 2019 08:30:56 -0000 Hi Dave, > On May 15, 2019, at 09:58, Dave Taht wrote: >=20 > If it helps any: Nick Feamster and Jason Livingood just published " > Internet Speed Measurement: Current Challenges and Future > Recommendations " ( https://arxiv.org/pdf/1905.02334.pdf ) a few days > ago, and outlines quite a few problems going forward at higher speeds. Excellent, will read (once time permits). > I do wish the document had pointed out more clearly that router based > measurements have problems also, +1, especially newer SoCs which implement power features can run = into situations where depending on the load characteristics the CPUs = throttle back (in frequency) and perfomance becomes quite choppy, which = might not show up in bandwidth measurement but can really affect the = experienced bufferbloat. I currently think it better for the load = generation to be done by different hosts than the DUT/de-bloater... > with weaker cpus unable to source > enough traffic for an accurate measurement, but I do hope this > document has impact, and it's a good read, regardless. >=20 > Still, somehow getting it right at lower speeds is always on my mind. At lower speeds measuring the bandwidth is not that hard, since = overloading the CPU and the server;s bandwidth gets less likely, no? > I'd long ago hoped that DSL devices would adopt BQL, and that > cablemodems would also, thus moving packet processing a little higher > on the stack so more advanced algorithms like cake could take hold. Well, to make this happen we need to talk to modem = manufacturers, so mostly intel/lantiq and broadcom I believe. I happen = to have exact zero insiders in both companies in my "rolodex", but with = in a group as diverse and expert as this list is, someone here must know = someone that could get the word out inside those companies, no? For BQL on docsis modems though, I believe cablelabs might be = the best route (not that BQL on a docsis modem will help a lot, given = that we have, AFAICT, no open source OS running on a docsis modem, same = seems true for GPON). Best Regards Sebastian >=20 > On Wed, May 15, 2019 at 9:32 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 >> 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 >=20 >=20 > --=20 >=20 > Dave T=C3=A4ht > CTO, TekLibre, LLC > http://www.teklibre.com > Tel: 1-831-205-9740