Just a quick follow-up question @Sebastian @Simon: We're thinking of implementing a "download" button that would download the same data currently shown in the JSON view but instead as a CSV. Would that work?
Best, Sina. On Fri, Feb 26, 2021 at 12:23 AM Sina Khanifar <[email protected]> wrote: > > > would it be an option to embed the details link into the results page? > > > Having more detail available but not shown by default on the main page > > might keep the geeks happy and make diagnosis easier. > > Will give this a bit of thought and see if we can make it happen! > > On Thu, Feb 25, 2021 at 1:15 PM Sebastian Moeller <[email protected]> wrote: > > > > Hi Sina, > > > > most excellent! While I concur with Simon that "keeping it simple" is the > > right approach, would it be an option to embed the details link into the > > results page? > > > > Best Regards > > Sebastian > > > > > > > > > On Feb 25, 2021, at 21:50, Sina Khanifar <[email protected]> wrote: > > > > > >> https://bufferbloat.waveform.workers.dev/test-results?test-id=6fc7dd95-8bfa-4b76-b141-ed423b6580a9 > > > > > > One quick edit, I just changed the route to these, the debug data is > > > now available at: > > > > > > https://bufferbloat.waveform.com/test-results?test-id=6fc7dd95-8bfa-4b76-b141-ed423b6580a9 > > > > > > > > > On Thu, Feb 25, 2021 at 12:41 PM Sina Khanifar <[email protected]> wrote: > > >> > > >> Hi Sebastian! > > >> > > >>> [SM] not a bug, more of a feature request, could you add information on > > >>> whether the test ran over IPv6 or IPv4, and which browser/user agent > > >>> was involved (nothing too deep, just desktop/mobile and > > >>> firefox/chrome/safari/brave/...) as well as the date and time of the > > >>> test? All of these can help to interpret the test results. > > >> > > >> We actually collect all this data, it's just a little bit hidden. If > > >> you take the test-id from the end of the URL and put it at the end of > > >> a URL like this: > > >> > > >> https://bufferbloat.waveform.workers.dev/test-results?test-id=6fc7dd95-8bfa-4b76-b141-ed423b6580a9 > > >> > > >> You'll get a whole bunch of extra info, including useragent, a linux > > >> timestamp, and a bunch of other fun stuff :). We'll consider surfacing > > >> this more at some point in the future though! > > >> > > >>> Small typo "waus" instead of "ways". > > >> > > >> Thanks for catching this! A fix is in the works :). > > >> > > >> On Thu, Feb 25, 2021 at 2:49 AM Sebastian Moeller <[email protected]> > > >> wrote: > > >>> > > >>> Hi Sina, > > >>> > > >>> great work! I took the liberty to advertise this test already for some > > >>> weeks, because even in its still evolving developing state it was/is > > >>> already producubg interesting actionable results. Thanks foe fixing the > > >>> latency numbers for (desktop) Safari. More below. > > >>> > > >>> > > >>>> On Feb 24, 2021, at 19:22, Sina Khanifar <[email protected]> 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. > > >>> > > >>> [SM] not a bug, more of a feature request, could you add > > >>> information on whether the test ran over IPv6 or IPv4, and which > > >>> browser/user agent was involved (nothing too deep, just desktop/mobile > > >>> and firefox/chrome/safari/brave/...) as well as the date and time of > > >>> the test? All of these can help to interpret the test results. > > >>> > > >>> > > >>>> > > >>>> 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. > > >>> > > >>> [SM] I think this was a decent decision, as it seems your tests > > >>> has less issues even filling 1Gbps links than most others. > > >>> > > >>> > > >>>> * 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. > > >>> > > >>> [SM] Reasonable trade-off, and hopefully potential for pleasant > > >>> surprises in the future ;) > > >>> > > >>>> * 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. > > >>> > > >>> [SM] Great, if only so it feels comparable to "other" speedtests. > > >>> > > >>> > > >>>> * We moved the bufferbloat grade into the main results box. > > >>> > > >>> [SM] +1; that helps set the mood ;) > > >>> > > >>>> * 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. > > >>> > > >>> [SM] "There are a number of different waus of measuring and defining > > >>> jitter. For the purpose of this test, we calculate jitter by taking the > > >>> average of the deviations from the mean latency." > > >>> > > >>> Small typo "waus" instead of "ways". > > >>> > > >>> Best Regards > > >>> Sebastian > > >>> > > >>> > > >>>> > > >>>> 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 > > >>>> [email protected] > > >>>> https://lists.bufferbloat.net/listinfo/bloat > > >>> > > _______________________________________________ Bloat mailing list [email protected] https://lists.bufferbloat.net/listinfo/bloat
