From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qv1-xf33.google.com (mail-qv1-xf33.google.com [IPv6:2607:f8b0:4864:20::f33]) (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 8C9483B29D for ; Wed, 24 Feb 2021 20:16:31 -0500 (EST) Received: by mail-qv1-xf33.google.com with SMTP id 15so2005486qvp.13 for ; Wed, 24 Feb 2021 17:16:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:reply-to:to:references:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=amAl6vCsB1avmOEY1yLWAPaJqrMzP2is7sEvcq7JbG0=; b=kFdfACUj8TTnGNFFig3u59e0fOiebXRYi/yLxLimjTVG1v3w8CdXTpHwafupQeXJQf EAbWi39OrfFqFrYD/6vlP5G6PoqDu/ymZOCKpPe1/4aeE/nnwybEZgWTiT8J98emF29R yilfbXMyaFl03NDhlwwcSh8XZXorZ5htY2p2TTSDJgdk21Kaf9U1iCS/CkCaT4YMa0gu ZlO2pshcW/D3ikK0NDjp7BcBFTntn8p0ywNPFGCnSvZzEVxaGJ8q5Fb+Jv9vRs8S44h7 sIV5qTcOkdtIGj23gOU1cjDVPEhOC6iFbPzVa2NZVLoMxFbez6OFjAWjPuRUKG8EpVUM DV3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:reply-to:to:references:message-id :date:user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=amAl6vCsB1avmOEY1yLWAPaJqrMzP2is7sEvcq7JbG0=; b=SFsKm15ZxxHF+4j5dHar8YFnlJtJJKBRojerDpINbjfiL6XhPQN9RDm++GEMUxULeF PdHjOvpMM8Wo+PExBeANF9oX8dOGG9cyjSyrtycBlebIiVXpkHlbHxt7Al5ppM5WJ0Uv tiAgJ6CnjMHEViwUhO1Yf3Y19Iu3zLKbWoUbxf8vJUB1ct3qOWTZrrjTJeLX9IWPZfrP I8WoeTd0b+vIgCOD4UfcwUoPuDurwDQJ9NYm9pzYr0Wprx3bHeqYnVTPpOIAG1qjnNaU 8ejvsqrtqwPJxKaxXfsyFgD2F2/Yc4z3LygxTZR2ZeMiH1wcjCmm/5juuxTY9VTbNh6L RDEg== X-Gm-Message-State: AOAM53295FsLN5qax62qUjAWh46/Rk2Yh6Oz4UCu52niY/BWV1UzZeB9 dR+9qEob3mD6Swlbv5RrIsCggam+ipg= X-Google-Smtp-Source: ABdhPJwOM2qmnXGtyo1uXLtj2fgWH9ulQ/O6HG+NLZqEgR7xlJjGcAePU6ZLb/IeLXvZ7a2IFcKSew== X-Received: by 2002:a0c:fd63:: with SMTP id k3mr519167qvs.30.1614215790919; Wed, 24 Feb 2021 17:16:30 -0800 (PST) Received: from [192.168.7.123] ([99.241.212.236]) by smtp.gmail.com with ESMTPSA id v4sm2482417qtp.72.2021.02.24.17.16.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 24 Feb 2021 17:16:30 -0800 (PST) From: David Collier-Brown X-Google-Original-From: David Collier-Brown Reply-To: davecb@spamcop.net, dave.collier-brown@indexexchange.com To: bloat@lists.bufferbloat.net References: Message-ID: Date: Wed, 24 Feb 2021 20:16:30 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Subject: Re: [Bloat] Updated Bufferbloat Test 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, 25 Feb 2021 01:16:31 -0000 I like it, but the next thing I wonder of is "how good am I versus what's normal?" Let's say cable modems run at 42 Giga-somethings per second and I have a cable modem. If I get 40 Gsps, or 95%, is that good or bad? Doing that as a little horizaontal graph might be a good approach, so you can see if you land in the range around 42 up, 2 down, better or much worse... --dave On 2021-02-24 1:22 p.m., Sina Khanifar wrote: > Hi all, > > A couple of months ago my co-founder Sam posted an early beta of the > Bufferbloat test that we’ve been working on, and Dave also linked to > it a couple of weeks ago. > > Thank you all so much for your feedback - we almost entirely > redesigned the tool and the UI based on the comments we received. > We’re almost ready to launch the tool officially today at this URL, > but wanted to show it to the list in case anyone finds any last bugs > that we might have overlooked: > > https://www.waveform.com/tools/bufferbloat > > If you find a bug, please share the "Share Your Results" link with us > along with what happened. We capture some debugging information on the > backend, and having a share link allows us to diagnose any issues. > > This is really more of a passion project than anything else for us – > we don’t anticipate we’ll try to commercialize it or anything like > that. We're very thankful for all the work the folks on this list have > done to identify and fix bufferbloat, and hope this is a useful > contribution. I’ve personally been very frustrated by bufferbloat on a > range of devices, and decided it might be helpful to build another > bufferbloat test when the DSLReports test was down at some point last > year. > > Our goals with this project were: > * To build a second solid bufferbloat test in case DSLReports goes > down again. > * Build a test where bufferbloat is front and center as the primary > purpose of the test, rather than just a feature. > * Try to explain bufferbloat and its effect on a user's connection > as clearly as possible for a lay audience. > > A few notes: > * On the backend, we’re using Cloudflare’s CDN to perform the actual > download and upload speed test. I know John Graham-Cunning has posted > to this list in the past; if he or anyone from Cloudflare sees this, > we’d love some help. Our Cloudflare Workers are being > bandwidth-throttled due to having a non-enterprise grade account. > We’ve worked around this in a kludgy way, but we’d love to get it > resolved. > * We have lots of ideas for improvements, e.g. simultaneous > upload/downloads, trying different file size chunks, time-series > latency graphs, using WebRTC to test UDP traffic etc, but in the > interest of getting things launched we're sticking with the current > featureset. > * There are a lot of browser-specific workarounds that we had to > implement, and latency itself is measured in different ways on > Safari/Webkit vs Chromium/Firefox due to limitations of the > PerformanceTiming APIs. You may notice that latency is different on > different browsers, however the actual bufferbloat (relative increase > in latency) should be pretty consistent. > > In terms of some of the changes we made based on the feedback we > receive on this list: > > Based on Toke’s feedback: > https://lists.bufferbloat.net/pipermail/bloat/2020-November/015960.html > https://lists.bufferbloat.net/pipermail/bloat/2020-November/015976.html > * We changed the way the speed tests run to show an instantaneous > speed as the test is being run. > * We moved the bufferbloat grade into the main results box. > * We tried really hard to get as close to saturating gigabit > connections as possible. We redesigned completely the way we chunk > files, added a “warming up” period, and spent quite a bit optimizing > our code to minimize CPU usage, as we found that was often the > limiting factor to our speed test results. > * We changed the shield grades altogether and went through a few > different iterations of how to show the effect of bufferbloat on > connectivity, and ended up with a “table view” to try to show the > effect that bufferbloat specifically is having on the connection > (compared to when the connection is unloaded). > * We now link from the results table view to the FAQ where the > conditions for each type of connection are explained. > * We also changed the way we measure latency and now use the faster > of either Google’s CDN or Cloudflare at any given location. We’re also > using the WebTiming APIs to get a more accurate latency number, though > this does not work on some mobile browsers (e.g. iOS Safari) and as a > result we show a higher latency on mobile devices. Since our test is > less a test of absolute latency and more a test of relative latency > with and without load, we felt this was workable. > * Our jitter is now an average (was previously RMS). > * The “before you start” text was rewritten and moved above the start > button. > * We now spell out upload and download instead of having arrows. > * We hugely reduced the number of cross-site scripts. I was a bit > embarrassed by this if I’m honest - I spent a long time building web > tools for the EFF, where we almost never allowed any cross-site > scripts. * Our site is hosted on Shopify, and adding any features via > their app store ends up adding a whole lot of gunk. But we uninstalled > some apps, rewrote our template, and ended up removing a whole lot of > the gunk. There’s still plenty of room for improvement, but it should > be a lot better than before. > > Based on Dave Collier-Brown’s feedback: > https://lists.bufferbloat.net/pipermail/bloat/2020-November/015966.html > * We replaced the “unloaded” and “loaded” language with “unloaded” > and then “download active” and “upload active.” In the grade box we > indicate that, for example, “Your latency increased moderately under > load.” > * We tried to generally make it easier for non-techie folks to > understand by emphasizing the grade and adding the table showing how > bufferbloat affects some commonly-used services. > * We didn’t really change the candle charts too much - they’re > mostly just to give a basic visual - we focused more on the actual > meat of the results above that. > > Based on Sebastian Moeller’s feedback: > https://lists.bufferbloat.net/pipermail/bloat/2020-November/015963.html > * We considered doing a bidirectional saturating load, but decided > to skip on implementing it for now. * It’s definitely something we’d > like to experiment with more in the future. > * We added a “warming up” period as well as a “draining” period to > help fill and empty the buffer. We haven’t added the option for an > extended test, but have this on our list of backlog changes to make in > the future. > > Based on Y’s feedback (link): > https://lists.bufferbloat.net/pipermail/bloat/2020-November/015962.html > * We actually ended up removing the grades, but we explained our > criteria for the new table in the FAQ. > > Based on Greg White's feedback (shared privately): > * We added an FAQ answer explaining jitter and how we measure it. > > We’d love for you all to play with the new version of the tool and > send over any feedback you might have. We’re going to be in a feature > freeze before launch but we'd love to get any bugs sorted out. We'll > likely put this project aside after we iron out a last round of bugs > and launch, and turn back to working on projects that help us pay the > bills, but we definitely hope to revisit and improve the tool over > time. > > Best, > > Sina, Arshan, and Sam. > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat -- David Collier-Brown, | Always do right. This will gratify System Programmer and Author | some people and astonish the rest davecb@spamcop.net | -- Mark Twain