Re: [Bloat] A Transport Protocol's View of Starlink

On Wed, 22 May 2024 06:16:17 -0700 Kenneth Porter via Bloat wrote: > This technical paper on Starlink by the chief scientist at APNIC crossed my > feed this week. [I thought I'd share it to the Starlink list here but my > application to join that list seems to have gotten stuck so I'll share

Re: [Bloat] Trying to *really* understand Linux pacing

On Wed, 7 Feb 2024 07:05:27 -0500 Dave Taht via Bloat wrote: > I also tend to think that attempting it in various cloudy > environments and virtualization schemes, and with certain drivers, the > side effects are not as well understood as I would like. For example, > AWS's nitro lacks BQL as

Re: [Bloat] Best approach for debloating Airbnb host?

On Tue, 17 Oct 2023 06:26:17 -0700 Dave Taht via Bloat wrote: > > 2. What would I recommend? Obviously, inserting something with cake into > > the mix would help a lot. Even if they were willing to let me examine their > > entire network (Comcast router, Apple Airport in our Airbnb unit, other

Re: [Bloat] Easiest/most effective way to test software against adverse networks?

On Sat, 5 Aug 2023 13:35:40 -0400 Sean DuBois via Bloat wrote: > I am working on improving Pion's Google Congestion Control algorithm > https://github.com/pion/interceptor/tree/master/pkg/gcc. As I start to use > it in more real world networks I find flaws. > > How are people testing software

Re: [Bloat] [Cake] Two questions re high speed congestionmanagement anddatagram protocols

On Mon, 10 Jul 2023 23:27:46 +0200 Sebastian Moeller wrote: > For what it is worth, the tsv working group is considering whether to process > mp-dccp on the standards track, but then the IETF seems not to care too > deeply about open-source licence compliance. Or recent kernel implementations

Re: [Bloat] [Cake] Two questions re high speed congestionmanagement anddatagram protocols

On Wed, 28 Jun 2023 10:32:32 -0400 (EDT) "David P. Reed" wrote: > How to find a kernel maintainer to care about DCCP, seems to be the question > for Linux. > I am tempted... Not to get involved with IETF "barriers" (what a mess, given > the folks in IETF who resisted in AQM, I wouldn't last a

Re: [Bloat] Two questions re high speed congestion management anddatagram protocols

On Tue, 27 Jun 2023 12:47:01 -0700 (PDT) David Lang wrote: > On Mon, 26 Jun 2023, David P. Reed via Bloat wrote: > > > Sorry for top posting, but ... Bigger question: > > Why would DCCP be deprecated by Linux kernel? > > Who makes that decision? Who argues against it? > > Linus or the

Re: [Bloat] Two questions re high speed congestion management anddatagram protocols

On Mon, 26 Jun 2023 23:41:59 -0400 (EDT) "David P. Reed" wrote: > Sorry for top posting, but ... Bigger question: > Why would DCCP be deprecated by Linux kernel? > Who makes that decision? Who argues against it? No one uses it, and unused protocols are targeted by hackers. And there are few

Re: [Bloat] Two questions re high speed congestion management and datagram protocols

On Sat, 24 Jun 2023 14:41:52 -0400 (EDT) "David P. Reed via Bloat" wrote: > I also was looking back to DCCP as a useful way to get a UDP that handled > congestion without engaging the higher layers, and preserving the other > flexibility of UDP. DCCP never got widely used, and Linux is on the

Re: [Bloat] why do people still study RED?

On Wed, 31 May 2023 16:28:14 -0600 Dave Taht via Bloat wrote: > An otherwise good paper on RED vs drop tail here: > > https://arxiv.org/pdf/2303.10220.pdf > > Is it because we completely lack any analytical methods for taking a > hard look at drop or marking from the head, as codel does, or

Re: [Bloat] hystart++

On Sun, 28 May 2023 06:46:48 -0600 Dave Taht via Bloat wrote: > Does a linux implementation of this exist? It looks promising... > > https://datatracker.ietf.org/doc/html/rfc9406 > Not that I know of. Contact the authors and they may be able to help. Microsoft is more open source friendly

[Bloat] Traffic shaping for evil?

This showed up on Human Infrastructure mailing list and others might be interested. https://adriano.fyi/post/2023/2023-04-16-att-traffic-shaping-makes-websites-unusable/ ___ Bloat mailing list Bloat@lists.bufferbloat.net

Re: [Bloat] WSL2 + fq_codel

quantum 1514 target > 5.0ms interval 100.0ms memory_limit 32Mb ecn > > On Sat, Feb 25, 2023 at 11:07 PM Dave Taht via Bloat < > bloat@lists.bufferbloat.net> wrote: > >> On Sat, Feb 25, 2023 at 12:54 PM Stephen Hemminger >> wrote: >> > >> > On Sat,

Re: [Bloat] WSL2 + fq_codel

On Sat, 25 Feb 2023 15:37:02 -0500 Michael Richardson via Bloat wrote: > Dave Taht via Bloat wrote: > > I so want to believe... I so want to believe... can anyone confirm? > > > >

Re: [Bloat] Fwd: [New post] How Good is FWA Wireless?

On Wed, 8 Feb 2023 16:43:59 -0800 Dave Taht via Bloat wrote: > On Wed, Feb 8, 2023 at 2:41 PM Luis A. Cornejo > wrote: > > > > As a former T-mobile HSI customer, I can attest the horrible queue > > management. The deprioritization was so bad that it became basically > > unusable, even a ping

Re: [Bloat] [Rpm] the grinch meets cloudflare's christmas present

On Wed, 4 Jan 2023 15:11:34 -0500 David Collier-Brown via Bloat wrote: > On 1/4/23 15:02, rjmcmahon via Bloat wrote: > > Curious to why people keep calling capacity tests speed tests? A semi > > at 55 mph isn't faster than a porsche at 141 mph because its load > > volume is larger. > >

Re: [Bloat] Fwd: NANOG 87: Call for Presentations | N86 PC Picks + More

On Thu, 10 Nov 2022 08:58:39 -0800 Dave Taht via Bloat wrote: > I keep hoping that someone from starlink will start showing up at > traditional venues such as this. How is Starlink going, now that Elon has shown how he can screw up a company. ___

Re: [Bloat] [Make-wifi-fast] The most wonderful video ever about bufferbloat

On Wed, 19 Oct 2022 14:33:28 -0700 (PDT) David Lang via Bloat wrote: > On Wed, 19 Oct 2022, Stuart Cheshire via Bloat wrote: > > > On Mon, Oct 17, 2022 at 5:02 PM Stuart Cheshire wrote: > > > >> Accuracy be damned. The analogy to common experience resonates more. > > > > I feel it is not

Re: [Bloat] Researchers discover major roadblock in alleviating network congestion

On Fri, 5 Aug 2022 00:45:12 +0300 Jonathan Morton via Bloat wrote: > > On 4 Aug, 2022, at 3:21 pm, Bjørn Ivar Teigen via Bloat > > wrote: > > > > Main take-away (as I understand it) is something like "In real-world > > networks, jitter adds noise to the end-to-end delay such that any

Re: [Bloat] gaming latencies

Apparently audiophiles are willing to spend extra money on a switch with better power supply and carbon frame to reduce noise in digital signals. https://www.tomshardware.com/news/ethernet-switch-for-audiophiles ___ Bloat mailing list

Re: [Bloat] Bechtolschiem

On Fri, 2 Jul 2021 09:42:24 -0700 Dave Taht wrote: > "Debunking Bechtolsheim credibly would get a lot of attention to the > bufferbloat cause, I suspect." - dpreed > > "Why Big Data Needs Big Buffer Switches" - > http://www.arista.com/assets/data/pdf/Whitepapers/BigDataBigBuffers-WP.pdf >

Re: [Bloat] Really getting 1G out of ISP?

On Tue, 22 Jun 2021 22:51:18 + "Livingood, Jason" wrote: > > It doesn't help that all the local ISP's claim 10Mbit upload even with 1G > > download. Is this a head end provisioning problem or related to Docsis 3.0 > > (or later) modems? > > I'll cover this in an upcoming technical paper

Re: [Bloat] Really getting 1G out of ISP?

On Tue, 22 Jun 2021 23:04:18 + "Livingood, Jason" wrote: > > For DOCSIS the issue seems to be an unfortunate frequency split between up > > and downstream and use of lower efficiency coding schemes. > > Performance really takes a big step forward once a person has a D3.1 modem in >

[Bloat] Really getting 1G out of ISP?

Is there any consumer hardware that can actually keep up and do AQM at 1Gbit. It seems everyone seems obsessed with gamer Wifi 6. But can only do 300Mbit single stream with any kind of QoS. It doesn't help that all the local ISP's claim 10Mbit upload even with 1G download. Is this a head end

Re: [Bloat] virtio_net: BQL?

On Mon, 17 May 2021 16:32:21 -0700 Dave Taht wrote: > On Mon, May 17, 2021 at 4:00 PM Stephen Hemminger > wrote: > > > > On Mon, 17 May 2021 14:48:46 -0700 > > Dave Taht wrote: > > > > > On Mon, May 17, 2021 at 1:23 PM Willem de Bruijn > > >

Re: [Bloat] virtio_net: BQL?

On Mon, 17 May 2021 14:48:46 -0700 Dave Taht wrote: > On Mon, May 17, 2021 at 1:23 PM Willem de Bruijn > wrote: > > > > On Mon, May 17, 2021 at 2:44 PM Dave Taht wrote: > > > > > > Not really related to this patch, but is there some reason why virtio > > > has no support for BQL? > > > >

Re: [Bloat] Questions for Bufferbloat Wikipedia article

On Tue, 6 Apr 2021 23:59:53 +0200 Erik Auerswald wrote: > Hi, > > On Tue, Apr 06, 2021 at 10:02:21PM +0200, Bless, Roland (TM) wrote: > > On 06.04.21 at 20:50 Erik Auerswald wrote: > > >On Tue, Apr 06, 2021 at 08:31:01AM +0200, Sebastian Moeller wrote: > > >>>On Apr 6, 2021, at 02:47, Erik

Re: [Bloat] Questions for Bufferbloat Wikipedia article

On Mon, 5 Apr 2021 08:46:15 -0400 Rich Brown wrote: > Dave Täht has put me up to revising the current Bufferbloat article on > Wikipedia (https://en.wikipedia.org/wiki/Bufferbloat) > > Before I get into it, I want to ask real experts for some guidance... Here > goes: > > 1) What is *our*

Re: [Bloat] [Cerowrt-devel] a start at the FCC filing

Start with Ron Wyden On Thu, Mar 4, 2021, 7:54 PM Dave Taht wrote: > I am planning to take my time on this. I would like for example, to > at least communicate well with a republican senator and a democratic one. > > Admittedly, if we can upgrade everybody to 100Mbit, everybody can have > all 4

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

On Tue, 23 Feb 2021 17:14:31 -0800 Dave Taht wrote: > wow, that is (predictably) miserable, even with cake. The only > solution that is going to > work is to somehow actively monitor your link quality and adjust cake > to suit. Or we can start trying to use kathie's passive ping tools. > > On

Re: [Bloat] OpenWrt Stability?

On Tue, 5 Jan 2021 12:08:56 -0500 Rich Brown wrote: > > On Jan 5, 2021, at 12:00 PM, Stephen Hemminger wrote: > > > > I having lots of issues with openwrt stability. > > I know the OpenWrt dev's are going hammer and tongs to produce a 2x.0x > release

Re: [Bloat] Openwrt stability?

On Tue, 5 Jan 2021 11:49:58 -0500 Daniel Sterling wrote: > On Tue, Jan 5, 2021 at 11:10 AM Michael Richardson wrote: > > > > Stephen Hemminger wrote: > > > Any idea how to debug this? Is there a way to get serial console? > > > > It depends upon

[Bloat] Openwrt stability?

I having lots of issues with openwrt stability. Today's issue seems to be some device on one leg of the home LAN causing OpenWrt router to crash. That leg has Xbox and other audio gear. Any idea how to debug this? Is there a way to get serial console?

[Bloat] NeST: Network Stack Tester

This looks interesting: https://blog.apnic.net/2020/09/18/nest-a-simpleefficient-tool-to-study-congestion-control/ Good - using namespaces for testing is a good idea. - testbed is GPLv2 Bad - using iperf as your main test tool encourages buffer bloat - Does 5G really need yet another

Re: [Bloat] the future belongs to pacing

On Sun, 05 Jul 2020 13:43:27 -0400 Michael Richardson wrote: > Sebastian Moeller wrote: > > of the sending rate, no? BBRv2 as I understand it will happily run > > roughshod over any true rfc3168 AQM on the path, I do not have the > > numbers, but I am not fully convinced that

Re: [Bloat] intel gives up on home gateways

On Tue, 28 Apr 2020 09:57:26 -0700 Dave Taht wrote: > H/T sebastian: > > https://investors.maxlinear.com/press-releases/detail/395/maxlinear-to-acquire-intels-home-gateway-platform > > Gawd knows what this means. > It means somebody is getting a bonus, and somebody is out of a job

Re: [Bloat] Rigorous Coffee Shop Bloat Testing

On Wed, 4 Sep 2019 06:24:07 +0300 Jonathan Morton wrote: > > On 4 Sep, 2019, at 6:17 am, Dave Taht wrote: > > > > …and people jump off of cable as soon as > > they can get fiber... but that's due to the RTT more than the bandwidth. > > And also due to the downright predatory pricing/billing

Re: [Bloat] Rigorous Coffee Shop Bloat Testing

On Tue, 3 Sep 2019 10:29:51 -0700 Dave Taht wrote: > On Tue, Sep 3, 2019 at 8:57 AM Rich Brown wrote: > > > > > On Sep 3, 2019, at 11:22 AM, bloat-requ...@lists.bufferbloat.net wrote: > > > > > > The coffee shop tests were fun, but I(we) needed more rigor when doing > > > them. What I'd

Re: [Bloat] [Cake] Fwd: Re: Unable to create htb tc classes more than 64K

On Mon, 26 Aug 2019 09:35:14 +0200 Toke Høiland-Jørgensen wrote: > Turns out that with the "earliest departure time" support in sched_fq, > it is now possible to write a shaper in eBPF, thus avoiding the global > qdisc lock in sched_htb. This is pretty cool, if you ask me! :) > > -Toke >

Re: [Bloat] How can I tell if fq_codel is running?

On Tue, 30 Jul 2019 15:34:21 -0700 Kenneth Porter wrote: > I'm running CentOS 7 on a Dell R230 as a small office router. It's on a > slow ADSL link, 1.5 Mbps down and 150 kbps up. The kernel supports > fq_codel, as does the tg3 driver used by the interfaces. > > In the past I've run the

[Bloat] Blog post: "Do packet drops matter for TCP"

Good summary of bufferbloat from network operator point of view. https://blog.ipspace.net/2019/06/do-packet-drops-matter-for-tcp.html?ck_subscriber_id=182966812 ___ Bloat mailing list Bloat@lists.bufferbloat.net

Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

On Wed, 20 Mar 2019 19:04:17 + "Holland, Jake" wrote: > Hi Bob & Greg, > > I agree there has been a reasonably open conversation about the L4S > work, and thanks for all your efforts to make it so. > > However, I think there's 2 senses in which "private" might be fair that > I didn't see

Re: [Bloat] transparenty bridge/tap with fq_codel

On Mon, 11 Mar 2019 16:01:36 -0700 Dev wrote: > I built a transparent bridge on a Debian platform earlier running fq_codel > between eth2 and eth3 as br0 which seemed to improve throughput. > > Now, I’m wondering if there’s a way to copy some of those packets to another > onboard NIC eth4

Re: [Bloat] fq_codel on bridge throughput test/config

On Fri, 4 Jan 2019 12:33:28 -0800 Dev wrote: > Okay, thanks to some help from the list, I’ve configured a transparent bridge > running fq_codel which works for multiple subnet traffic. Here’s my setup: > > Machine A ——— 192.168.10.200 — — bridge fq_codel machine B —— laptop C > 192.168.10.150

Re: [Bloat] ExLL: An Extremely Low-latency Congestion Control for Mobile Cellular Networks

On Wed, 5 Dec 2018 14:56:35 +0100 "Bless, Roland (TM)" wrote: > Hi, > > Am 04.12.18 um 19:03 schrieb Dave Taht: > > I guess someone could modify quic to do this also. > > > > https://sci-hub.tw/https://dl.acm.org/citation.cfm?doid=3281411.3281430 > > It seems that it isn't "extremely

Re: [Bloat] when does the CoDel part of fq_codel help in the real world?

On Fri, 30 Nov 2018 06:51:34 +0100 (CET) Mikael Abrahamsson wrote: > On Thu, 29 Nov 2018, Stephen Hemminger wrote: > > > The problem is that any protocol is mostly blind to the underlying > > network (and that can change). To use dave's analogy it is like being > >

Re: [Bloat] when does the CoDel part of fq_codel help in the real world?

On Wed, 28 Nov 2018 23:35:53 -0800 Dave Taht wrote: > > As someone who works with moving packets, it's perplexing to me to > > interact with transport peeps who seem enormously focused on > > "goodput". My personal opinion is that most people would be better off > > with 80% of their available

Re: [Bloat] one benefit of turning off shaping + fq_codel

On Tue, 27 Nov 2018 18:14:01 + "Holland, Jake" wrote: > On 2018-11-23, 08:33, "Dave Taht" wrote: > Back in the day, I was a huge fan of async logic, which I first > encountered via caltech's cpu and later the amulet. > >

Re: [Bloat] [Codel] found another good use for a queue today, possibly

On Mon, 26 Nov 2018 18:17:32 -0800 Dave Taht wrote: > I had been investigating various hashing schemes for speeding up the > babeld routing protocol daemon, and dealing with annoying bursty cpu > behavior (resizing memory, bursts of packets, thundering herds of > retractions), and, although it's

Re: [Bloat] vyatta in AT 5G gear

On Tue, 23 Oct 2018 09:38:10 +0200 Jonas Mårtensson wrote: > > > > Linux Foundation announced Danos, but no code is yet available. > > > > Yeah I know, but you seemed to know it is written in Go, which I can't find > any information about, so I thought maybe you had more information. > >

Re: [Bloat] vyatta in AT 5G gear

On Tue, 16 Oct 2018 17:46:44 -0700 Dave Taht wrote: > Jan Ceuleers writes: > > > 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

Re: [Bloat] vyatta in AT 5G gear

On Tue, 16 Oct 2018 08:14:36 -0700 Dave Taht wrote: > On Tue, Oct 16, 2018 at 8:06 AM Stephen Hemminger > wrote: > > > > On Tue, 16 Oct 2018 11:59:18 +0200 > > Stefan Alfredsson wrote: > > > > > On 2018-10-16 11:31, Mikael Abrahamsson wrote: > &g

Re: [Bloat] vyatta in AT 5G gear

On Tue, 16 Oct 2018 11:59:18 +0200 Stefan Alfredsson wrote: > On 2018-10-16 11:31, Mikael Abrahamsson wrote: > > > On Mon, 15 Oct 2018, Dave Taht wrote: > > > >> Vyos (the open source fork of vyatta) was one of the first to add > >> fq_codel support... I wonder > >> > >>

Re: [Bloat] lwn.net's tcp small queues vs wifi aggregation solved

On Thu, 21 Jun 2018 10:31:18 -0500 Caleb Cushing wrote: > actually... all of my devices, including my desktop connect through wifi > these days... and only one of them isn't running some variant of linux. > Sigh. My experience with wifi is that it is not stable enough for that. Both AP's I

Re: [Bloat] benefits of ack filtering

On Wed, 29 Nov 2017 10:41:41 -0800 Dave Taht wrote: > On Wed, Nov 29, 2017 at 10:21 AM, Juliusz Chroboczek wrote: > >> The better solution would of course be to have the TCP peeps change the > >> way TCP works so that it sends fewer ACKs. > > > > Which tends

Re: [Bloat] emulating non-duplex media in linux qdiscs

On Sun, Oct 8, 2017 at 6:54 PM, Dave Taht wrote: > I have been hacking away at netem for a while now in the hope that > eventually - with a great deal more hacking - it could be used to more > accurately emulate shared media like wifi and lte. > > (Some people try to

Re: [Bloat] fq_codel is *five* years old today

Rich, you gave a good "glass is half full" story but my experience is currently much worse. Here is the "glass is mostly empty" story. > There have been so many improvements in so many ways... > > - Cake is the acknowledged winner in SQM But is still not upstream and requires tuning. In real

[Bloat] TCP BBR over LTE

Interesting talk at Netdev 2.1 Verizon testing TCP BBR over LTE. https://www.netdevconf.org/2.1/session.html?chung Compared TCP Cubic vs BBR while driving on highway from Boston to New Jersey. Will post paper and youtube link when available ___

Re: [Bloat] [Make-wifi-fast] [Cake] flent testers wanted prior to next release

On Tue, 31 Jan 2017 17:35:40 +0100 Toke Høiland-Jørgensen <t...@toke.dk> wrote: > Stephen Hemminger <step...@networkplumber.org> writes: > > > On Tue, 20 Dec 2016 11:02:44 -0800 > > Dave Taht <dave.t...@gmail.com> wrote: > > > >> Toke has been

Re: [Bloat] [Cake] flent testers wanted prior to next release

On Tue, 20 Dec 2016 11:02:44 -0800 Dave Taht wrote: > Toke has been busy adding new features to the flent network test tool. > I consider it *almost* stable enough for a new release. Some of the > development has been focused on making the flent-gui much faster and > more

Re: [Bloat] Fixing bufferbloat in 2017

My experience has been that the media and developer attention span is short lived, and maybe that is part of the problem. Gaming is a niche market, and therefore is easily ignored; plus the classic gaming market is dying and I am not sure anyone is really investing in it. The current hot topic

Re: [Bloat] fixing bufferbloat in 2017

> BQL for vmxnet3 (if possible). Virtual router are becoming common. BQL could be implemented in vmxnet3, but probably not in virtio. virtio defers freeing packets to try and have better cache behavior ___ Bloat mailing list Bloat@lists.bufferbloat.net

Re: [Bloat] QCut - "Understanding on-device bufferbloat for cellular upload", Guo et al

On Tue, 15 Nov 2016 12:00:29 -0500 Rich Brown wrote: > Google Alerts sent a link to this paper: "Understanding on-device bufferbloat > for cellular upload" available at: http://dl.acm.org/citation.cfm?id=2987490 > (ACM Paywall...) > > In my two-minute skim of the

Re: [Bloat] DualPI2 qdisc implementation available for Linux

Why not submit it upstream where it can get more review and will get picked up by more users? On Fri, Jul 29, 2016 at 2:08 AM, De Schepper, Koen (Nokia - BE) < koen.de_schep...@nokia-bell-labs.com> wrote: > Hi all, > > For those who missed the L4S BoF, the PI2 AQM with DualQ option is >

Re: [Bloat] [Cake] are anyone playing with dpdk and vpp?

DPDK gets impressive performance on large systems (like 14M packets/sec per core), but not convinced on smaller systems. Performance depends on having good CPU cache. I get poor performance on Atom etc. Also driver support is limited (mostly 10G and above) On Wed, Apr 27, 2016 at 12:28 PM, Aaron

Re: [Bloat] Hardware upticks

On Tue, 5 Jan 2016 11:37:02 -0800 Dave Täht wrote: > > > On 1/5/16 11:29 AM, Steinar H. Gunderson wrote: > > On Tue, Jan 05, 2016 at 10:57:13AM -0800, Dave Täht wrote: > >> Context switch time is probably one of the biggest hidden nightmares in > >> modern OOO cpu architectures

Re: [Bloat] Hardware upticks

On Wed, 6 Jan 2016 01:22:13 +0100 "Steinar H. Gunderson" <sgunder...@bigfoot.com> wrote: > On Tue, Jan 05, 2016 at 04:06:03PM -0800, Stephen Hemminger wrote: > > The expensive part is often having to save and restore all the state in > > registers and other bits

Re: [Bloat] Hardware upticks

On Wed, 6 Jan 2016 01:55:37 +0100 "Steinar H. Gunderson" <sgunder...@bigfoot.com> wrote: > On Tue, Jan 05, 2016 at 04:53:14PM -0800, Stephen Hemminger wrote: > >> Also, I've never ever seen the actual context switch turn up high in a perf > >> profile. Is t

Re: [Bloat] bufferbloat email list server upgrade going slow and badly

On Mon, 4 Jan 2016 15:38:05 -0800 Dave Täht wrote: > all the bufferbloat.net servers are in the process of migrating to a > new co-location facility. the lists - if not the archives - should be > alive again, at least. > > There is a stupid bug somewhere stopping the archived

Re: [Bloat] TCP congestion detection - random thoughts

You just reinvented delay based congestion control. This has been tried int many forms dating back to TCP Vegas. https://en.wikipedia.org/wiki/TCP_Vegas Unfortunately, it often failed in practice (which no one ever wanted to publish), Some of the reasons are: * Delay based CC is sensitive to

Re: [Bloat] General Bufferbloat Testing Document.

On Fri, 15 May 2015 12:16:56 -0400 Jim Gettys j...@freedesktop.org wrote: Even before I knew about the wonderful DSLreports bufferbloat test, I had started working on a document to help people like that (e.g. Ookla) understand how to do bufferbloat testing. The document also grew a bit

Re: [Bloat] Question about Buffer Bloat and Verizon Fios

On Wed, 08 Apr 2015 09:56:48 -0700 Alex Elsayed eternal...@gmail.com wrote: Dave Taht wrote: On Wed, Apr 8, 2015 at 5:05 AM, ga...@djlatino.com wrote: snip Reason is Verizon has a combo router/modem. They CAN be configured in a bridge mode if you desire, but you can usually just

Re: [Bloat] Question about Buffer Bloat and Verizon Fios

...@djlatino.com wrote: I'm going to order them from Amazon. A pair of moca is $110.00. Thanks Sent from my iPhone On Apr 8, 2015, at 6:18 PM, Stephen Hemminger step...@networkplumber.org wrote: On Wed, 08 Apr 2015 09:56:48 -0700 Alex Elsayed eternal...@gmail.com wrote: Dave Taht

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

On Sat, 30 Aug 2014 09:05:58 +0300 Jonathan Morton chromati...@gmail.com wrote: On 29 Aug, 2014, at 5:37 pm, Jerry Jongerius wrote: did you check to see if packets were re-sent even if they weren't lost? on of the side effects of excessive buffering is that it's possible for a packet

[Bloat] T-Mobile LTE buffer bloat

I got one of these Samsung LTE hotspot. Not surprisingly it has huge bloat and a stupid http proxy that netalyzer claims rewrites images. Bandwidth: Up 1.6 Mbit/sec Down 4.3Mbit/sec Latency: 140ms 0% loss Buffering: Uplink 5100ms Down 1800ms How can the uplink side be so bad! 5 seconds???

Re: [Bloat] T-Mobile LTE buffer bloat

On Thu, 31 Oct 2013 00:34:12 +0100 (CET) Mikael Abrahamsson swm...@swm.pp.se wrote: On Wed, 30 Oct 2013, Stephen Hemminger wrote: Not surprisingly it has huge bloat and a stupid http proxy that netalyzer claims rewrites images. This could be done in the provider network, did you try

Re: [Bloat] sweet tcp

On Tue, 9 Jul 2013 19:38:40 +0200 Jaume Barcelo jaume.barc...@upf.edu wrote: To be more specific, TCP would be at any time increasing or decreasing the congestion window. In other words, it will be moving in one direction (right or left) along the x axis of Fig. 1 of Getty's paper. Each RTT,

Re: [Bloat] Google's experiments with QUIC and SPDY

On Fri, 28 Jun 2013 01:33:22 -0700 Hal Murray hmur...@megapathdsl.net wrote: Has anybody tried this stuff in a bloat sensitive environment? Experimenting with QUIC http://blog.chromium.org/2013/06/experimenting-with-quic.html QUIC (Quick UDP Internet Connections) is an early-stage

Re: [Bloat] tc linklayer ADSL calc broken after commit 56b765b79 (htb: improved accuracy at high rates)

On Wed, 29 May 2013 08:52:04 -0700 Eric Dumazet eric.duma...@gmail.com wrote: On Wed, 2013-05-29 at 15:13 +0200, Jesper Dangaard Brouer wrote: I recently discovered that the (traffic control) tc linklayer calculations for ATM/ADSL have been broken by: commit 56b765b79 (htb: improved

Re: [Bloat] Network test tools for many parallel/concurrent connections?

On Tue, 14 May 2013 15:48:38 +0200 Jesper Dangaard Brouer jbro...@redhat.com wrote: (I'm testing fq_codel and codel) I need a test tool that can start many TCP streams (1024). During/after the testrun I want to know if the connections got a fair share of the bandwidth. Can anyone

Re: [Bloat] Bufferbloat Paper

The tone of the paper is a bit of if academics don't analyze it to death it must not exist. The facts are interesting, but the interpretation ignores the human element. If human's perceive delay Daddy the Internet is slow, then they will change their behavior to avoid the problem: it hurts when I

Re: [Bloat] [Codel] better testing, linux 3.6.1, cerowrt credits, other stuff

On Wed, 10 Oct 2012 19:27:11 -0400 Michael Richardson m...@sandelman.ca wrote: But: It became obvious fast that long RTT tests were needed, which I've been trying to establish the infrastructure to do toke I assume that by infrastructure you mean (netperf) servers toke

Re: [Bloat] high speed networking from userspace

On Tue, 13 Mar 2012 13:28:52 +0100 Hagen Paul Pfeifer ha...@jauu.net wrote: On Mon, 12 Mar 2012 17:09:44 -0700, Dave Taht dave.t...@gmail.com wrote: is the by the same guy that did QFQ, and the results are quite impressive. He (today) announced support for this interface for Linux.

Re: [Bloat] [PATCH net-next] sch_red: Adaptative RED AQM

On Thu, 08 Dec 2011 17:06:03 +0100 Eric Dumazet eric.duma...@gmail.com wrote: Changes against our RED implementation are : max_p is no longer a negative power of two (1/(2^Plog)), but a Q0.32 fixed point number, to allow full range described in Adatative paper. To deliver a random number,

Re: [Bloat] Not all the world's a WAN

On Wed, 17 Aug 2011 18:26:00 -0700 Patrick J. LoPresti lopre...@gmail.com wrote: Hello, BufferBloat crusaders. Permit me briefly to describe my application. I have a rack full of Linux systems, all with 10GbE NICs tied together by a 10GbE switch. There are no routers or broader Internet

Re: [Bloat] Notes about hacking on AQMs

On Wed, 8 Jun 2011 10:52:07 -0600 Dave Taht dave.t...@gmail.com wrote: On Wed, Jun 8, 2011 at 10:41 AM, Eric Dumazet eric.duma...@gmail.com wrote: Le mercredi 08 juin 2011 à 09:51 -0600, Dave Taht a écrit : And they are *all* wrong to varying extents, which is why I like the 'mondo

Re: [Bloat] Goodput fraction w/ AQM vs bufferbloat

On Sat, 7 May 2011 19:39:22 +0300 Jonathan Morton chromati...@gmail.com wrote: On 7 May, 2011, at 1:10 am, Stephen Hemminger wrote: Rate = (MSS/RTT)*(1 / sqrt{p}) where: Rate: is the TCP transfer rate or throughputd MSS: is the maximum segment size (fixed for each Internet path

[Bloat] Fwd: Identifying TCP congestion control algorithms, and measurement results

This showed up on the end-to-end mailing list and might be of interest to this group. It is interesting how many hosts are still using BIC (probably RHEL/Centos 5). BIC is known to be broken and unfair. From: Lisong Xu lisong...@gmail.com Date: Tue, Mar 15, 2011 at 3:36 PM Subject: [e2e]