Re: [Bloat] [Rpm] [Starlink] [LibreQoS] net neutrality back in the news

On 30/09/2023 14:19, Sebastian Moeller via Bloat wrote: > > P.S.: Of course if we look close enough we surely can find corner-cases where > either the EU regulations or the translation into national law result in less > desirable outcomes, but "nothing is perfect" and all in all the regulations

[Bloat] This is the bufferbloat mailing list

Could I suggest that the discussion return to that topic please? ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] [Starlink] Annoyed at 5/1 Mbps...

On 21/03/2023 13:31, Sebastian Moeller via Bloat wrote: (...) > Noki's proprietary (aka not ITU) @% Gbps PON seems to be abbreviated 25GS-PON. 25GSPON is in fact not proprietary. It was standardised by means of an MSA (multi-source agreement) rather than through the ITU-T, but it is standardised a

Re: [Bloat] FCC requires broadband "Nutritional Label"

On 18/11/2022 13:36, Rich Brown via Bloat wrote: > Even though the label only specifies "typical latency", I have a sense that > this is a good step forward. Shame that the latency has to be specified in Ms (megaseconds) though. ISPs will feel justified in rounding it down to 0.

Re: [Bloat] ONTs and ITU - T G.988

On 13/01/2022 00:42, Dave Taht wrote: > My 1st question is - are there any ONTs that actually do do pause > frames? Or providers that configure for them? In my (limited) experience most network operators want ONTs to be transparent to pause frames. > My second is - what is a cheap way to setup a

Re: [Bloat] [Cerowrt-devel] uplink bufferbloat and scheduling problems

On 01/12/2021 21:26, David P. Reed wrote: > In any CSMA link (WiFi), there is no "up" or "down". There is only > sender and receiver, and each station and the AP are always doing both. Generally though the silicon used in WiFi APs is much more capable than that used in STAs. The capabilities of (p

Re: [Bloat] fq_codel wikipedia page in progress

On 15/11/2021 23:47, Kenneth Porter wrote: > On 11/15/2021 2:15 PM, Kenneth Porter wrote: >> >> I'd also suggest changing the page title to match the capitalization >> and hyphen of the RFC. >> >> https://datatracker.ietf.org/doc/html/rfc8290 > > Following my own advice to mimic other protocol pag

Re: [Bloat] Fwd: [Galene] Galene news

On 04/09/2021 16:20, Dave Taht wrote: > I like galene a lot, because it's written in pure go, and has a pretty > good implementation of the gcc congestion control algorithm. It also > can be made to run > on a home router, and the prospect of sending baby video from upstairs > to downstairs and not

Re: [Bloat] fcc input

On 26/03/2021 20:09, Dave Taht wrote: > I have often thought hard about trying to explain things better via > animations, and on more than one occasion tried to find an animator > who could turn this old 8m talk from "people as packets" into "unruly > animals as packets". > > https://www.youtube.c

Re: [Bloat] Router congestion, slow ping/ack times with kernel 5.4.60

On 07/11/2020 13:37, Thomas Rosenstein via Bloat wrote: > Nonetheless, I tested it and no difference :) The relevant test would be to run your experiment while IPv6 is completely disabled in the kernel. ___ Bloat mailing list Bloat@lists.bufferbloat.net

Re: [Bloat] I hate my ISP

On 03/05/2020 05:57, Taran Lynn wrote: > Hello, > > So evidently Viasat doesn't know how to handle bufferbloat at all with > their exede satellite service. It's been really bad today. I've attached > flent's tcp_1up results for those interested. Note that the base RTT is > 600ms and upload is usua

Re: [Bloat] datapoint from one vendor regarding bloat

On 11/04/2019 19:54, Jonathan Morton wrote: >> On 11 Apr, 2019, at 1:38 pm, Mikael Abrahamsson wrote: >> >> The mbs defines the MBS for the PIR bucket and the cbs defines the CBS for >> the CIR bucket > > What do these lumps of jargon refer to? If you're truly interested in the answer: the docu

Re: [Bloat] Does VDSL interleaving+FEC help bufferbloat?

On 04/01/2019 18:10, Dave Taht wrote: > dsl interleave was added primarily to make multicast udp tv streams > work better (as they are very intolerant of packet loss). Often (as in > free's implementation) these streams are "invisible" to the overlying > IP applications. It typically adds at least

Re: [Bloat] vyatta in AT&T 5G gear

On 16/10/2018 17:14, Dave Taht wrote: > And what was so wrong with the "everything as a file" model?? On a single box - not a lot. On a 5G network, which might consist of 10^3 - 10^5 boxes you need aggregation and abstraction layers. ___ Bloat mailing l

Re: [Bloat] first bufferbloat free cablemodem?

On 06/10/18 05:14, Dave Taht wrote: > I would so love for the review on this to be true. > > https://express.google.com/product/Arris-SURFboard-Cable-Modem-and-AC2350-Wi-Fi-Router-with-Arris-Secure-Home-Internet-by-McAfee/0_17937886568302066345_0 > Could you post a link that can be viewed from o

Re: [Bloat] [Make-wifi-fast] [Cerowrt-devel] closing up my make-wifi-fast lab

On 30/08/18 22:36, bkil wrote: > 1b. > Let's assume that we are a good citizen using more expensive highly > directional antennae and we live at the perimeter. Considering that For some reason I only received this today. Your points about the use of directional antennas should be mitigated, at le

Re: [Bloat] [Cerowrt-devel] beating the drum for BQL

On 24/08/18 15:44, Mikael Abrahamsson wrote: > On Fri, 24 Aug 2018, Jan Ceuleers wrote: > >> On 24/08/18 13:46, Jan Ceuleers wrote: >>> On 24/08/18 10:06, Dave Taht wrote: >>>> Random curiosity: what do various SFP+ interfaces (notably gpon) eat? >>>

Re: [Bloat] [Cerowrt-devel] beating the drum for BQL

On 24/08/18 13:46, Jan Ceuleers wrote: > On 24/08/18 10:06, Dave Taht wrote: >> Random curiosity: what do various SFP+ interfaces (notably gpon) eat? > > I have taken a look at a couple. I see numbers in the range 1.7 - 2.2W > for GPON ONTs. Just to be clear: that&#

Re: [Bloat] [Cerowrt-devel] beating the drum for BQL

On 24/08/18 10:06, Dave Taht wrote: > Random curiosity: what do various SFP+ interfaces (notably gpon) eat? I have taken a look at a couple. I see numbers in the range 1.7 - 2.2W for GPON ONTs. ___ Bloat mailing list Bloat@lists.bufferbloat.net https://l

Re: [Bloat] [Cerowrt-devel] beating the drum for BQL

On 24/08/18 01:35, Sebastian Moeller wrote: > Sure, but my ISP charged 4 EUR per month for the DSL-router that adds > up to 12*2*4 = 96 EUR over the 2 years contract duration and to 12*5*4 = 240 > over my renting duration; assuming that my ISP does not need to make a profit > on this devic

Re: [Bloat] [Cerowrt-devel] beating the drum for BQL

On 23/08/18 15:06, Sebastian Moeller wrote: > Or we could convince customers to stop buying toy router's that only > work under a severely limited set of circumstances and opt for devices that > pack enough CPU-punch to be actually adequate for modern internet speed > tiers, no? Now if the

Re: [Bloat] [Cerowrt-devel] fcc initial comments due sept 10

On 11/08/18 05:34, dpr...@deepplum.com wrote: > Just to remind everyone, "Broadband" is a term invented by the cable industry > to describe "bundled cable TV, phone, and Internet", pretty much "aka DOCSIS". No, it's not. Not that's important, but the term was coined many years ago by the telecom

[Bloat] Fwd: Fixing bufferbloat with PF and OpenBSD

Forwarded Message Subject:Fixing bufferbloat with PF and OpenBSD Date: Wed, 04 Jul 2018 09:17:55 GMT From: OpenBSD Journal <> Fixing bufferbloat with PF and OpenBSD In this post

Re: [Bloat] [Cerowrt-devel] Invisibility of bufferbloat and its remedies

On 20/06/18 01:41, Jonathan Morton wrote: >> On 19 Jun, 2018, at 11:34 pm, valdis.kletni...@vt.edu wrote: >> >> Do we have a good cookbook on how to determine the set-rate? > > On DSL, the sync rates in each direction should usually be readable from the > modem; they are typically reported on the

[Bloat] Fwd: [Bug 1436945] Re: devel: consider fq_codel as the default qdisc for networking

Took 3 years after Dave approached them, but Ubuntu is finally adopting fq_codel as the default qdisc. Forwarded Message Subject: [Bug 1436945] Re: devel: consider fq_codel as the default qdisc for networking Date: Thu, 24 May 2018 14:50:09 - From: Laurent Bonnaud Reply-To:

Re: [Bloat] The Blind Men and the Elephant.

On 12/02/18 18:55, Dave Taht wrote: > I would certainly like to see translations and outreach into China... > Taiwan... Japan... India... Central and South America... Africa... > > but to me the simpler thing would be to garner folk to ask at > vendor/isp press conferences: "Have you implemented R

Re: [Bloat] The Blind Men and the Elephant.

On 12/02/18 02:11, Jim Gettys wrote: > My version is up: dunno why the ietf web site doesn't have it up yet (It > was supposed to go up 7pm ET). > > https://gettys.wordpress.com/2018/02/11/the-blind-men-and-the-elephant/ > > We will push this on social media first thing in the morning.  Those of

Re: [Bloat] [Make-wifi-fast] benefits of ack filtering

On 03/12/17 11:35, Juliusz Chroboczek wrote: > I'm lost here. What exact problem is the ACK hack supposed to work > around? Ridiculous amount of asymmetry in the last-hop WiFi link, or > outrageous amounts of asymmetry in a transit link beyond the last hop? My understanding is that the issue tha

Re: [Bloat] benefits of ack filtering

On 01/12/17 01:28, David Lang wrote: > Stop thinking in terms of single-flow benchmarks and near idle > 'upstream' paths. Nobody has said it so I will: on wifi-connected endpoints the upstream acks also compete for airtime with the downstream flow. ___ B

Re: [Bloat] Steam In Home Streaming on ath9k wifi

Resending with the from-address with which I'm subscribed to the list On 26/11/17 18:53, Dave Taht wrote: > On Sun, Nov 26, 2017 at 2:05 AM, Jonathan Morton > wrote: >> Another explanation for latency spikes on the order of 100ms is that a >> periodic (and wholly unnecessary) scan for other APs

Re: [Bloat] Steam In Home Streaming on ath9k wifi

On 26/11/17 14:03, Jan Ceuleers wrote: > Disabling the scans needed to be done on the AP side though (in > hostapd.conf): > > # If set non-zero, require stations to perform scans of overlapping > # channels to test for stations which would be affected by 40 MHz traffic. > # T

Re: [Bloat] Steam In Home Streaming on ath9k wifi

On 26/11/17 12:54, Steinar H. Gunderson wrote: > It's not about the AP, it's about the client. (APs can detect extension > channel interference without doing a scan, although I don't know if you need > this fallback at all on 5 GHz.) You are absolutely right. I have disabled the scans and now the

Re: [Bloat] Steam In Home Streaming on ath9k wifi

On 26/11/17 11:05, Jonathan Morton wrote: > Another explanation for latency spikes on the order of 100ms is that a > periodic (and wholly unnecessary) scan for other APs is run, which > requires the wifi radio to be temporarily tuned away from the currently > associated AP's frequency. My understa

Re: [Bloat] Steam In Home Streaming on ath9k wifi

On 26/11/17 08:29, Caleb Cushing wrote: > from desktop > > Pinging 192.168.1.105 with 32 bytes of data: > Reply from 192.168.1.105 : bytes=32 time<1ms TTL=128 I've also performed a ping test via wifi to the AP. Here are the stats for 100 pings: 100 packets transmitted, 100

Re: [Bloat] Fixing bufferbloat in 2017

On 28/11/16 03:16, Jim Gettys wrote: > Ookla may have made themselves long term irrelevant by their recent > behavior. When your customers start funding development of a > replacement (as Comcast has), you know they aren't happy. > > So I don't sweat Ookla: helping out the Comcast test effort is

Re: [Bloat] fixing bufferbloat in 2017

On 22/11/16 16:32, Dave Taht wrote: > What's left to do? Furthering adoption of the code that contains the bloat-related improvements. In my view, the single biggest potential contributor towards driving such adoption would be for Ookla to start measuring and reporting bufferbloat, thereby puttin

Re: [Bloat] bufferbloat at high edge rates

On 15/11/16 16:23, James Cloos wrote: >> "j" == jb writes: > > j> It can be downloaded here from the sticky: > j>http://www.dslreports.com/forum/speedtestbinary > > That links to: > > > http://www.dslreports.com/r0/download/2293455~bc6f17b1568921811497422ad3fff3b5/dslrcli-linux-amd64

Re: [Bloat] 22 seconds til bloat on gfiber?

On 27/10/16 21:48, Aaron Wood wrote: > That sounds like it was in the right ballpark. Trenching is so > expensive, only doing it every couple decades sounds like a reasonable > plan (even better if you trench conduit that you can run replaceable > cables in (which is what AT&T did when they took

Re: [Bloat] 22 seconds til bloat on gfiber?

On 26/10/16 03:05, Benjamin Cronce wrote: > Sorry to side track > > 1:1 split bandwidth wise, still a 1:16 or whatever fiber split. Each > port can handle 40Gb/s, which is 32 lambdas of 1.25Gb/s, each customer > getting their own lambda. The ONT can either be WDM-PON or GPON with an > inline filte

Re: [Bloat] 22 seconds til bloat on gfiber?

On 25/10/16 00:10, Benjamin Cronce wrote: > WDM-PON, giving each customer their own lambda of bandwidth. Effectively > a 1:1 split. Not quite. All it means is that multiple PONs coexist on the same outside plant, each on a different wavelength, and each serving multiple end-users. Allows for highe

Re: [Bloat] ultrafast broadband conference june 27-30

On 18/06/16 13:14, Toke Høiland-Jørgensen wrote: > Yup. Unfortunately we've had no luck thus far. > > https://www.dslreports.com/speedtest is an alternative speedtest that > does include bufferbloat scores. Yes, but it isn't used by ISPs when they qualify product. Would it be worth pursuing an R

Re: [Bloat] ultrafast broadband conference june 27-30

On 18/06/16 12:51, Toke Høiland-Jørgensen wrote: > I know of at least one DSL vendor who supposedly has started paying > attention after pressure from a clueful ISP; not idea if they started > shipping non-bloated products yet. Got it. To get more ISPs interested in this subject we need to get Oo

Re: [Bloat] ultrafast broadband conference june 27-30

On 18/06/16 12:24, Jonathan Morton wrote: >> So it seems that you and I agree that it's not G.fast itself that is >> bloated, but the lack of proper buffer management in certain (most?) DSL >> modems, regardless of whether they support G.fast or some other flavour >> of DSL. > > Right. We’re hopi

Re: [Bloat] ultrafast broadband conference june 27-30

On 18/06/16 12:09, Jonathan Morton wrote: > These buffers are not inherent to the link technology. > If they were, we’d be calling for different link technology. Thanks for confirming my suspicions. But this is exactly what Dave was doing, since he blamed the uplink bloat on "g.fast technologies".

Re: [Bloat] ultrafast broadband conference june 27-30

On 13/06/16 18:05, Dave Taht wrote: > Is anyone going to this? I sure hope the g.fast technologies have > their uplink bloat fixed, at least. Dave, (Been trying to send this for the past few days unsuccessfully; perhaps the DNS gremlins caused it to bounce. Now sending via gmail). As I'm sure ev

Re: [Bloat] Speed tests - attribution of latency to relevant network hops

On 30/07/15 15:04, Bill Ver Steeg (versteb) wrote: > You do have to be careful using ttl tricks and/or ICMP packets for > fine-grained timing measurements. On many middleboxes, there is a "fast path" > that is done in a highly optimized manner (often in silicon) and a "slow > path". In a non-zer

Re: [Bloat] Speed tests - attribution of latency to relevant network hops

On 30/07/15 06:52, Mikael Abrahamsson wrote: > On Wed, 29 Jul 2015, David Lang wrote: > >> unless you measure it per hop, how are you going to attribute it to >> each hop? and unless you have a server at that layer to talk to, how >> do you know what the latency or bandwidth is? > > Measuring lat

[Bloat] Speed tests - attribution of latency to relevant network hops

Dear list, Now that dslreports has set the benchmark on combining speed testing with latency measurements I was thinking about what the next steps could be. Here's what I came up with: Would it be useful to try and attribute the latency to certain relevant network hops, like so: First hop: round

Re: [Bloat] Graph of bloat

On 08/07/15 18:32, Dave Taht wrote: > Judging from that graphic... I don't think huff and puff was designed > for the bufferbloated era! so the question remains, in hal's tests, > did ntp adjust the clock backwards? Dave, No, ntpd did not adjust the time backwards. What's going on in that graph

Re: [Bloat] Graph of bloat

On 08/07/15 18:11, Jan Ceuleers wrote: > On 08/07/15 17:55, Dave Taht wrote: >> That is a very interesting graph! Does ntp adjust system time backward >> based on getting nearly all it's samples with well over a 1/2 second >> of induced delay? > > If there is a co

Re: [Bloat] Graph of bloat

On 08/07/15 17:55, Dave Taht wrote: > That is a very interesting graph! Does ntp adjust system time backward > based on getting nearly all it's samples with well over a 1/2 second > of induced delay? If there is a consistent asymmetrical delay then yes. If the delay asymmetry is not persistent (b

[Bloat] Fwd: [Bug 1436945] Re: devel: consider fq_codel as the default qdisc for networking

Disappointing... Forwarded Message Subject: [Bug 1436945] Re: devel: consider fq_codel as the default qdisc for networking Date: Wed, 08 Jul 2015 10:50:05 - From: Andy Whitcroft Reply-To: Bug 1436945 <1436...@bugs.launchpad.net> To: jan.ceule...@computer.org ** Changed in:

Re: [Bloat] Question about fq_codel vs modem buffers

On 02/05/15 04:49, Rich Brown wrote: > But I don't know enough about the physical characteristics of cable/dsl links to understand how they actually work, nor how fq_codel can (or can't) accommodate degradation. I know a little about the DSL PHY behaviour. It is possible for line conditions to d

Re: [Bloat] Adblock - or another extension - is incorrectly blocking the speed test

On 26/04/15 06:17, jb wrote: > The warning is correct in that it is probably NOSCRIPT. I think. > All the speed test knows is that an API call to all servers was brutally > failed > in an unexpected way. There is no visibility into what caused the > failure, only > that it should not occur in a cle

Re: [Bloat] Adblock - or another extension - is incorrectly blocking the speed test

On 25/04/15 13:44, jb wrote: > The message appears when the speed test is blocked from reaching a test > server. > > It has turned out to be almost always either Adblock, AdblockPlus or > NOSCRIPT > > The error message is correct, at least, has been so far: it is always an > extension > and whate

[Bloat] Adblock - or another extension - is incorrectly blocking the speed test

Dear list, I'm unable to use the speed test with either of my main browsers (Firefox and Chrome, both under Linux) because of the above error message. Even if I temporarily completely disable Adblock. What is the problem here? Because what is incorrect is the error message, not my use of browser

Re: [Bloat] The Dark Problem with AQM in the Internet?

On 08/28/2014 06:35 PM, Fred Baker (fred) wrote: > When a message is lost due to an error, how do you determine whose fault > it is? Links need to be engineered for the optimum combination of power, bandwidth, overhead and residual error that meets requirements. I agree with your implied point tha

Re: [Bloat] sigcomm wifi

On 08/21/2014 09:57 PM, Steinar H. Gunderson wrote: > I'll stop preaching the Cisco gospel soon (well, e.g. Aruba would probably > also do just the same thing :-) ), but in a WLC-based solution, there's a > setting to just refuse the first few associations on 2.4 GHz if it detects > the client is 5

Re: [Bloat] [aqm] the side effects of 330ms lag in the real world

On 04/29/2014 07:01 PM, Toke Høiland-Jørgensen wrote: > However, as that graph shows, it is quite possible to completely avoid > bufferbloat by deploying the right shaping. And in that case fibre > *does* have a significant latency advantage. The best latency I've seen > to the upstream gateway on

Re: [Bloat] TCP TFO client behaviour

On 12/11/2012 05:59 PM, Eric Dumazet wrote: > I really wonder why this is sent to these lists instead of netdev ? Some of us (well: me) have been banned from netdev. As a matter of fact: not only from netdev, but from the whole of vger.kernel.org. For asking the networking maintainer to tone down

Re: [Bloat] Dashboard dedicated to BufferBloat issue

On 09/21/2012 11:09 AM, Branco Camporeto wrote: > For helping me and tracking all events about bufferbloat, I did this > public dashboard. http://www.netvibes/bufferbloat > I keep updating it. I suspect that URL should be http://www.netvibes.com/bufferbloat Jan _

Re: [Bloat] the observed sack oddity

On 10/11/2011 03:09 PM, David Täht wrote: I have put up screenshots of tcptrace -G and xplot.org's analysis of my most recent capture of an ipv6 connection over freebox (wired) from a debloat-testing kernel here in france (pre 3.1 by a lot) to a 2.6.16 kernel (the aformentioned netsonar box) in r