Re: [Bloat] [Cake] Fwd: [Galene] Dave on bufferbloat and jitter at 8pm CET Tuesday 23

On 2/25/21 11:30 AM, Toke Høiland-Jørgensen wrote: Ah, wireguard doesn't have XDP support, so that's likely not going to work; and if you run it on the physical interface, even if you didn't get driver errors, the tool would just see the encrypted packets which is not terribly helpful (it

Re: [Bloat] [Cake] Fwd: [Galene] Dave on bufferbloat and jitter at 8pm CET Tuesday 23

On 2/25/21 9:18 AM, Taraldsen Erik wrote: This is getting rather rather Telenor internal and probably is not true for other ISP's, but here we go.  Mobile Broad Band (MBB) is handled by Telenor's Mobile division. Fixed Wireless Access (FWA) is handled by Telenors Fixed division (the same

Re: [Bloat] Updated Bufferbloat Test

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 wrote: > >>

Re: [Bloat] Updated Bufferbloat Test

Having more detail available but not shown by default on the main page might keep the geeks happy and make diagnosis easier. Simon On February 25, 2021 12:11:02 PM Sina Khanifar wrote: Thanks for the kind words, Simon! Since you are measuring buffer bloat - how much latency *can* be caused

Re: [Bloat] Updated Bufferbloat Test

Yes, if you want to know how well real time communication is going to work, something close to peak or 95%ile of total latency is the relevant measure. Showing less data and keeping it simple is ideal, so users don't get confused. Simon On February 25, 2021 12:11:02 PM Sina Khanifar wrote:

Re: [Bloat] Updated Bufferbloat Test

> 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,

Re: [Bloat] Updated Bufferbloat Test

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?

Re: [Bloat] Updated Bufferbloat Test

Hi Sina, let me try to invite Daniel Lakeland (cc'd) into this discussion. He is doing tremendous work in the OpenWrt forum to single handedly help gamers getting the most out of their connections. I think he might have some opinion and data on latency requirements for modern gaming.

Re: [Bloat] Updated Bufferbloat Test

Thanks for the kind words, Simon! > Since you are measuring buffer bloat - how much latency *can* be caused by > the excessive buffering, expressing the jitter number in terms of 95%ile > would be appropriate - as that’s closely related to how large the excessive > buffer is. The average

Re: [Bloat] Updated Bufferbloat Test

> [SM] Maybe the solution would be to increase the frequency of the RTT > measures and increase the quantile somewhat, maybe 90 or 95? I think we scaled back the frequency of our RTT measurements to avoid CPU issues, but I think we can increase them a little and then use 95th percentile latency

Re: [Bloat] Updated Bufferbloat Test

Hi Sina, That sounds great, and I understand the desire to separate the fixed component of latency and the buffer bloat / variable part. Messaging that in a way that accurately conveys the end user impact and the impact due to unmitigated buffers while being easy to understand is tricky.

Re: [Bloat] Updated Bufferbloat Test

> So perhaps this can feed into the rating system, total latency < 50mS is an > A, < 150mS is a B, 600mS is a C or something like that. The "grade" we give is purely a measure of bufferbloat. If you start with a latency of 500 ms on your connection, it wouldn't be fair for us to give you an F

Re: [Bloat] Trouble Installing PPing in MacOS

Thanks, I have tried moving around the src directory hierarchy to no avail, including searching for explicit references to 'pping'. On Thu, Feb 25, 2021 at 11:52 AM Toke Høiland-Jørgensen wrote: > Jason Iannone writes: > > > Hi, > > > > I'm new here. Can anyone help me get pping installed? As

[Bloat] fcc's samknows tests of the internet

see page 31 for the latency under load test. The voip is terrible where perhaps, something like irtt would be useful, and they could really use a videoconferencing test. https://data.fcc.gov/download/measuring-broadband-america/2020/Technical-Appendix-fixed-2020.pdf -- "For a successful

Re: [Bloat] Trouble Installing PPing in MacOS

Jason Iannone writes: > Hi, > > I'm new here. Can anyone help me get pping installed? As far as I can tell, > cmake, make, and make install all worked, but I don't have pping. Does > anyone with a bigger brain than mine have a suggestion? > > $ pping > -bash: pping: command not found My bet

Re: [Bloat] Updated Bufferbloat Test

Toke Høiland-Jørgensen writes: >> * 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

Re: [Bloat] Updated Bufferbloat Test

So perhaps this can feed into the rating system, total latency < 50mS is an A, < 150mS is a B, 600mS is a C or something like that. Simon On February 25, 2021 5:49:26 AM Mikael Abrahamsson wrote: On Thu, 25 Feb 2021, Simon Barber wrote: The ITU say voice should be <150mS, however in the

Re: [Bloat] Updated Bufferbloat Test

On Thu, 25 Feb 2021, Simon Barber wrote: The ITU say voice should be <150mS, however in the real world people are a lot more tolerant. A GSM -> GSM phone call is ~350mS, and very few people complain about that. That said the quality of the conversation is affected, and staying under 150mS is

Re: [Bloat] Updated Bufferbloat Test

And what counts is round trip end to end total latency. This is fixed latency plus jitter (variation above the fixed) - ie peak total latency. Peak total or high percentile 95/98 will be a much closer approximation to the performance of a real world jitter buffer in a voip system than average

Re: [Bloat] Updated Bufferbloat Test

On Thu, Feb 25, 2021 at 5:38 AM Simon Barber wrote: > > The ITU say voice should be <150mS, however in the real world people are a > lot more tolerant. Because they have to be. A call with 5ms latency is amazing. >A GSM -> GSM phone call is ~350mS, and very few people complain about that.

Re: [Bloat] Updated Bufferbloat Test

The ITU say voice should be <150mS, however in the real world people are a lot more tolerant. A GSM -> GSM phone call is ~350mS, and very few people complain about that. That said the quality of the conversation is affected, and staying under 150mS is better for a fast free flowing

Re: [Bloat] Updated Bufferbloat Test

Sina Khanifar writes: > 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 Thank you for the update, and especially this very detailed changelog! I'm impressed! A few

Re: [Bloat] Updated Bufferbloat Test

Hi Sina, > On Feb 25, 2021, at 06:56, Sina Khanifar wrote: > > Thanks for the feedback, Dave! > >> 0) "average" jitter is a meaningless number. In the case of a >> videoconferencing application, what matters most is max jitter, where the >> app will choose to ride the top edge of that,

Re: [Bloat] Updated Bufferbloat Test

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

Re: [Bloat] [Cake] Fwd: [Galene] Dave on bufferbloat and jitter at 8pm CET Tuesday 23

This is getting rather rather Telenor internal and probably is not true for other ISP's, but here we go. Mobile Broad Band (MBB) is handled by Telenor's Mobile division. Fixed Wireless Access (FWA) is handled by Telenors Fixed division (the same group who does DSL, DOCSIS and GPON). To

Re: [Bloat] Updated Bufferbloat Test

Hmm, I'm not quite sure what you mean here - not all cable modems are equal, surely? Some cable modems will run at 42 Gsps but others will run at 0.1 Gsps. I'm not sure a comparison to a global average would be helpful? I think our "grading" system is meant to give at least some indication of

Re: [Bloat] Updated Bufferbloat Test

Thanks for sharing. Out of curiosity, how do our results compare with DSLReports on your connection? On Wed, Feb 24, 2021 at 2:16 PM Kenneth Porter wrote: > > My results: > > > > My LAN is 100 Mbps. I'm

Re: [Bloat] [Cake] Fwd: [Galene] Dave on bufferbloat and jitter at 8pm CET Tuesday 23

"Nils Andreas Svee" writes: > I ran it on my router though, which has a decent amount of TCP flows running > at any given time. > It's all going over a wg tunnel though, that might be wonky for all I > know. Ah, wireguard doesn't have XDP support, so that's likely not going to work; and if you

Re: [Bloat] Updated Bufferbloat Test

On Wed, 24 Feb 2021, Sina Khanifar wrote: https://www.waveform.com/tools/bufferbloat I thought I just wanted to confirm that the tool seems to accurately seems to measure even higher speeds. This is my 1000/1000 debloated with FQ_CODEL to 900/900: