
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

<html>

<body>

<div dir="auto">

<div dir="auto">Agreed - average jitter is useless, needs to be peak/maximum. Disallowing a very small number of exception points is ok.</div><div dir="auto"><br></div><div dir="auto">Simon</div><div dir='auto'><br></div>

<div id="aqm-original" style="color: black;">

<div dir="auto">On February 24, 2021 2:10:55 PM Dave Taht <dave.taht@gmail.com> wrote:</div>

<div><br></div>

<blockquote type="cite" class="gmail_quote" style="margin: 0 0 0 0.75ex; border-left: 1px solid #808080; padding-left: 0.75ex;">

<div dir="auto">So I've taken a tiny amount of time to run a few tests. For starters,</div>

<div dir="auto">thank you very much</div>

<div dir="auto">for your dedication and time into creating such a usable website, and faq.</div>

<div dir="auto"><br></div>

<div dir="auto">I have several issues though I really haven't had time to delve deep</div>

<div dir="auto">into the packet captures. (others, please try taking em, and put them</div>

<div dir="auto">somewhere?)</div>

<div dir="auto"><br></div>

<div dir="auto">0) "average" jitter is a meaningless number. In the case of a</div>

<div dir="auto">videoconferencing application,</div>

<div dir="auto">what matters most is max jitter, where the app will choose to ride the</div>

<div dir="auto">top edge of that, rather than follow it. I'd prefer using a 98%</div>

<div dir="auto">number, rather than 75% number, to weight where the typical delay in a</div>

<div dir="auto">videoconfernce might end up.</div>

<div dir="auto"><br></div>

<div dir="auto">1) The worst case scenario of bloat affecting a users experience is</div>

<div dir="auto">during a simultaneous up and download, and I'd rather you did that</div>

<div dir="auto">rather than test them separately. Also you get</div>

<div dir="auto">a more realistic figure for the actual achievable bandwidth under</div>

<div dir="auto">contention and can expose problems like strict priority queuing in one</div>

<div dir="auto">direction or another locking out further flows.</div>

<div dir="auto"><br></div>

<div dir="auto">2) I get absurdly great results from it with or without sqm on on a</div>

<div dir="auto">reasonably modern cablemodem (buffercontrol and pie and a cmts doing</div>

<div dir="auto">the right things)</div>

<div dir="auto"><br></div>

<div dir="auto">This points to any of number of problems (features!) It's certainly my</div>

<div dir="auto">hope that all the cdn makers at this point have installed bufferbloat</div>

<div dir="auto">mitigations. Testing a cdn's tcp IS a great idea, but as a</div>

<div dir="auto">bufferbloated test, maybe not so much.</div>

<div dir="auto"><br></div>

<div dir="auto">The packet capture of the tcp flows DOES show about 60ms jitter... but</div>

<div dir="auto">no loss. Your test shows:</div>

<div dir="auto"><br></div>

<div dir="auto">https://www.waveform.com/tools/bufferbloat?test-id=6fc7dd95-8bfa-4b76-b141-ed423b6580a9</div>

<div dir="auto"><br></div>

<div dir="auto">And is very jittery in the beginning of the test on its estimates. I</div>

<div dir="auto">really should be overjoyed at knowing a cdn is doing more of the right</div>

<div dir="auto">things, but in terms of a test... and linux also has got a ton of</div>

<div dir="auto">mitigations on the client side.</div>

<div dir="auto"><br></div>

<div dir="auto">3) As a side note, ecn actually is negotiated on the upload, if it's</div>

<div dir="auto">enabled on your system.</div>

<div dir="auto">Are you tracking an ecn statistics at this point (ecnseen)? It is not</div>

<div dir="auto">negotiated on the download (which is fine by me).</div>

<div dir="auto"><br></div>

<div dir="auto">I regrettable at this precise moment am unable to test a native</div>

<div dir="auto">cablemodem at the same speed as a sqm box, hope to get further on this</div>

<div dir="auto">tomorrow.</div>

<div dir="auto"><br></div>

<div dir="auto">Again, GREAT work so far, and I do think a test tool for all these</div>

<div dir="auto">cdns - heck, one that tested all of them at the same time, is very,</div>

<div dir="auto">very useful.</div>

<div dir="auto"><br></div>

<div dir="auto">On Wed, Feb 24, 2021 at 10:22 AM Sina Khanifar <sina@waveform.com> wrote:</div>

<blockquote type="cite" class="gmail_quote" style="margin: 0 0 0 0.75ex; border-left: 1px solid #0099CC; padding-left: 0.75ex;">

<div dir="auto"><br></div>

<div dir="auto">Hi all,</div>

<div dir="auto"><br></div>

<div dir="auto">A couple of months ago my co-founder Sam posted an early beta of the</div>

<div dir="auto">Bufferbloat test that we’ve been working on, and Dave also linked to</div>

<div dir="auto">it a couple of weeks ago.</div>

<div dir="auto"><br></div>

<div dir="auto">Thank you all so much for your feedback - we almost entirely</div>

<div dir="auto">redesigned the tool and the UI based on the comments we received.</div>

<div dir="auto">We’re almost ready to launch the tool officially today at this URL,</div>

<div dir="auto">but wanted to show it to the list in case anyone finds any last bugs</div>

<div dir="auto">that we might have overlooked:</div>

<div dir="auto"><br></div>

<div dir="auto">https://www.waveform.com/tools/bufferbloat</div>

<div dir="auto"><br></div>

<div dir="auto">If you find a bug, please share the "Share Your Results" link with us</div>

<div dir="auto">along with what happened. We capture some debugging information on the</div>

<div dir="auto">backend, and having a share link allows us to diagnose any issues.</div>

<div dir="auto"><br></div>

<div dir="auto">This is really more of a passion project than anything else for us –</div>

<div dir="auto">we don’t anticipate we’ll try to commercialize it or anything like</div>

<div dir="auto">that. We're very thankful for all the work the folks on this list have</div>

<div dir="auto">done to identify and fix bufferbloat, and hope this is a useful</div>

<div dir="auto">contribution. I’ve personally been very frustrated by bufferbloat on a</div>

<div dir="auto">range of devices, and decided it might be helpful to build another</div>

<div dir="auto">bufferbloat test when the DSLReports test was down at some point last</div>

<div dir="auto">year.</div>

<div dir="auto"><br></div>

<div dir="auto">Our goals with this project were:</div>

<div dir="auto">* To build a second solid bufferbloat test in case DSLReports goes down again.</div>

<div dir="auto">* Build a test where bufferbloat is front and center as the primary</div>

<div dir="auto">purpose of the test, rather than just a feature.</div>

<div dir="auto">* Try to explain bufferbloat and its effect on a user's connection</div>

<div dir="auto">as clearly as possible for a lay audience.</div>

<div dir="auto"><br></div>

<div dir="auto">A few notes:</div>

<div dir="auto">* On the backend, we’re using Cloudflare’s CDN to perform the actual</div>

<div dir="auto">download and upload speed test. I know John Graham-Cunning has posted</div>

<div dir="auto">to this list in the past; if he or anyone from Cloudflare sees this,</div>

<div dir="auto">we’d love some help. Our Cloudflare Workers are being</div>

<div dir="auto">bandwidth-throttled due to having a non-enterprise grade account.</div>

<div dir="auto">We’ve worked around this in a kludgy way, but we’d love to get it</div>

<div dir="auto">resolved.</div>

<div dir="auto">* We have lots of ideas for improvements, e.g. simultaneous</div>

<div dir="auto">upload/downloads, trying different file size chunks, time-series</div>

<div dir="auto">latency graphs, using WebRTC to test UDP traffic etc, but in the</div>

<div dir="auto">interest of getting things launched we're sticking with the current</div>

<div dir="auto">featureset.</div>

<div dir="auto">* There are a lot of browser-specific workarounds that we had to</div>

<div dir="auto">implement, and latency itself is measured in different ways on</div>

<div dir="auto">Safari/Webkit vs Chromium/Firefox due to limitations of the</div>

<div dir="auto">PerformanceTiming APIs. You may notice that latency is different on</div>

<div dir="auto">different browsers, however the actual bufferbloat (relative increase</div>

<div dir="auto">in latency) should be pretty consistent.</div>

<div dir="auto"><br></div>

<div dir="auto">In terms of some of the changes we made based on the feedback we</div>

<div dir="auto">receive on this list:</div>

<div dir="auto"><br></div>

<div dir="auto">Based on Toke’s feedback:</div>

<div dir="auto">https://lists.bufferbloat.net/pipermail/bloat/2020-November/015960.html</div>

<div dir="auto">https://lists.bufferbloat.net/pipermail/bloat/2020-November/015976.html</div>

<div dir="auto">* We changed the way the speed tests run to show an instantaneous</div>

<div dir="auto">speed as the test is being run.</div>

<div dir="auto">* We moved the bufferbloat grade into the main results box.</div>

<div dir="auto">* We tried really hard to get as close to saturating gigabit</div>

<div dir="auto">connections as possible. We redesigned completely the way we chunk</div>

<div dir="auto">files, added a “warming up” period, and spent quite a bit optimizing</div>

<div dir="auto">our code to minimize CPU usage, as we found that was often the</div>

<div dir="auto">limiting factor to our speed test results.</div>

<div dir="auto">* We changed the shield grades altogether and went through a few</div>

<div dir="auto">different iterations of how to show the effect of bufferbloat on</div>

<div dir="auto">connectivity, and ended up with a “table view” to try to show the</div>

<div dir="auto">effect that bufferbloat specifically is having on the connection</div>

<div dir="auto">(compared to when the connection is unloaded).</div>

<div dir="auto">* We now link from the results table view to the FAQ where the</div>

<div dir="auto">conditions for each type of connection are explained.</div>

<div dir="auto">* We also changed the way we measure latency and now use the faster</div>

<div dir="auto">of either Google’s CDN or Cloudflare at any given location. We’re also</div>

<div dir="auto">using the WebTiming APIs to get a more accurate latency number, though</div>

<div dir="auto">this does not work on some mobile browsers (e.g. iOS Safari) and as a</div>

<div dir="auto">result we show a higher latency on mobile devices. Since our test is</div>

<div dir="auto">less a test of absolute latency and more a test of relative latency</div>

<div dir="auto">with and without load, we felt this was workable.</div>

<div dir="auto">* Our jitter is now an average (was previously RMS).</div>

<div dir="auto">* The “before you start” text was rewritten and moved above the start button.</div>

<div dir="auto">* We now spell out upload and download instead of having arrows.</div>

<div dir="auto">* We hugely reduced the number of cross-site scripts. I was a bit</div>

<div dir="auto">embarrassed by this if I’m honest - I spent a long time building web</div>

<div dir="auto">tools for the EFF, where we almost never allowed any cross-site</div>

<div dir="auto">scripts. * Our site is hosted on Shopify, and adding any features via</div>

<div dir="auto">their app store ends up adding a whole lot of gunk. But we uninstalled</div>

<div dir="auto">some apps, rewrote our template, and ended up removing a whole lot of</div>

<div dir="auto">the gunk. There’s still plenty of room for improvement, but it should</div>

<div dir="auto">be a lot better than before.</div>

<div dir="auto"><br></div>

<div dir="auto">Based on Dave Collier-Brown’s feedback:</div>

<div dir="auto">https://lists.bufferbloat.net/pipermail/bloat/2020-November/015966.html</div>

<div dir="auto">* We replaced the “unloaded” and “loaded” language with “unloaded”</div>

<div dir="auto">and then “download active”  and “upload active.” In the grade box we</div>

<div dir="auto">indicate that, for example, “Your latency increased moderately under</div>

<div dir="auto">load.”</div>

<div dir="auto">* We tried to generally make it easier for non-techie folks to</div>

<div dir="auto">understand by emphasizing the grade and adding the table showing how</div>

<div dir="auto">bufferbloat affects some commonly-used services.</div>

<div dir="auto">* We didn’t really change the candle charts too much - they’re</div>

<div dir="auto">mostly just to give a basic visual - we focused more on the actual</div>

<div dir="auto">meat of the results above that.</div>

<div dir="auto"><br></div>

<div dir="auto">Based on Sebastian Moeller’s feedback:</div>

<div dir="auto">https://lists.bufferbloat.net/pipermail/bloat/2020-November/015963.html</div>

<div dir="auto">* We considered doing a bidirectional saturating load, but decided</div>

<div dir="auto">to skip on implementing it for now. * It’s definitely something we’d</div>

<div dir="auto">like to experiment with more in the future.</div>

<div dir="auto">* We added a “warming up” period as well as a “draining” period to</div>

<div dir="auto">help fill and empty the buffer. We haven’t added the option for an</div>

<div dir="auto">extended test, but have this on our list of backlog changes to make in</div>

<div dir="auto">the future.</div>

<div dir="auto"><br></div>

<div dir="auto">Based on Y’s feedback (link):</div>

<div dir="auto">https://lists.bufferbloat.net/pipermail/bloat/2020-November/015962.html</div>

<div dir="auto">* We actually ended up removing the grades, but we explained our</div>

<div dir="auto">criteria for the new table in the FAQ.</div>

<div dir="auto"><br></div>

<div dir="auto">Based on Greg White's feedback (shared privately):</div>

<div dir="auto">* We added an FAQ answer explaining jitter and how we measure it.</div>

<div dir="auto"><br></div>

<div dir="auto">We’d love for you all to play with the new version of the tool and</div>

<div dir="auto">send over any feedback you might have. We’re going to be in a feature</div>

<div dir="auto">freeze before launch but we'd love to get any bugs sorted out. We'll</div>

<div dir="auto">likely put this project aside after we iron out a last round of bugs</div>

<div dir="auto">and launch, and turn back to working on projects that help us pay the</div>

<div dir="auto">bills, but we definitely hope to revisit and improve the tool over</div>

<div dir="auto">time.</div>

<div dir="auto"><br></div>

<div dir="auto">Best,</div>

<div dir="auto"><br></div>

<div dir="auto">Sina, Arshan, and Sam.</div>

<div dir="auto">_______________________________________________</div>

<div dir="auto">Bloat mailing list</div>

<div dir="auto">Bloat@lists.bufferbloat.net</div>

<div dir="auto">https://lists.bufferbloat.net/listinfo/bloat</div>

</blockquote>

<div dir="auto"><br></div>

<div dir="auto"><br></div>

<div dir="auto"><br></div>

<div dir="auto">-- </div>

<div dir="auto">"For a successful technology, reality must take precedence over public</div>

<div dir="auto">relations, for Mother Nature cannot be fooled" - Richard Feynman</div>

<div dir="auto"><br></div>

<div dir="auto">dave@taht.net <Dave Täht> CTO, TekLibre, LLC Tel: 1-831-435-0729</div>

<div dir="auto">_______________________________________________</div>

<div dir="auto">Bloat mailing list</div>

<div dir="auto">Bloat@lists.bufferbloat.net</div>

<div dir="auto">https://lists.bufferbloat.net/listinfo/bloat</div>

</blockquote>

</div><div dir="auto"><br></div>

</div></body>

</html>