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 it

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 does

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 to

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 m

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 network

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 test

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 the

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

[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 https://lists.bufferbloat.net/lis

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? > > > > https://raw.githubusercontent.com/microsoft/WSL2-Linux-Kernel/linux-msft-wsl-5.15.y/Microsoft/config-wsl

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. > > They'

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. ___ Bloat

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 an

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 algorith

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 Bloat@lists.bufferb

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

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

[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 pro

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? > > > > Th

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 A

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* defi

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 Tu

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

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 your

[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 c

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 typical

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 typica

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

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 Wonder

[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 https://lists.bufferbloat.net/listinfo/blo

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 co

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 for

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 low-lat

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 ba

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. > > https://en.wikipedia.org/wiki/Asynchronous_circuit#Asy

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&T 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. > > /Jon

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

On Sun, 21 Oct 2018 11:36:43 +0200 Jonas Mårtensson wrote: > Hi Stephen, > > DaNoS has yang/netconf database based control plane > > (in Go) and DPDK (or switch offload?) based dataplane. > > > > Do you have more information about DANOS and using Go for the control > plane? The AT&T design us

Re: [Bloat] vyatta in AT&T 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 yo

Re: [Bloat] vyatta in AT&T 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&T 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 > >> > >> http://linuxgizmos

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 have

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 to perturb the way the TCP self-clo

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 describe these as simplex (wh

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 wor

[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 ___ Blo

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 wrote: > Stephen Hemminger writes: > > > 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 co

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 responsive (as our data

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 h

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 paper, I see they describe how

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

Re: [Bloat] Open Source Speed Test (was fast.com - Netflix's speed monitoring)

On Tue, 23 Aug 2016 18:42:07 + "Livingood, Jason" wrote: > FWIW, we at Comcast just announced public beta of a new > soon-to-be-open-source web-based speed test (see > http://labs.comcast.com/beta-testing-a-new-open-source-speed-test). We plan > to have a hackathon at Princeton in early No

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 W

Re: [Bloat] Hardware upticks

On Wed, 6 Jan 2016 01:55:37 +0100 "Steinar H. Gunderson" 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 this because of some samplin

Re: [Bloat] Hardware upticks

On Wed, 6 Jan 2016 01:22:13 +0100 "Steinar H. Gunderson" 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 on context switch. > > A

Re: [Bloat] Hardware upticks

The expensive part is often having to save and restore all the state in registers and other bits on context switch. On Tue, Jan 5, 2016 at 4:01 PM, Steinar H. Gunderson wrote: > On Tue, Jan 05, 2016 at 03:36:10PM -0600, Benjamin Cronce wrote: > > You can't have different virtual memory space an

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 - they only go f

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 pages from > making

Re: [Bloat] LWN article discussing the FCC blunder, as well a VW's (The Internet of criminal things)

On Thu, 24 Sep 2015 14:30:14 -0400 Rich Brown wrote: > Would you provide a link to the FCC article (for those of us who don't have a > LWN subscription)? Thanks. > > > On Sep 24, 2015, at 7:44 AM, David Collier-Brown wrote: > > > > > >

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 cr

Re: [Bloat] General Bufferbloat Testing Document.

On Fri, 15 May 2015 12:16:56 -0400 Jim Gettys 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 > beyond that topic, by

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

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

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

On Wed, 08 Apr 2015 09:56:48 -0700 Alex Elsayed wrote: > Dave Taht wrote: > > > On Wed, Apr 8, 2015 at 5:05 AM, wrote: > > >> Reason is Verizon has a combo router/modem. > > > > They CAN be configured in a bridge mode if you desire, but you can > > usually just put cero in front of it to do

Re: [Bloat] Comcast upped service levels -> WNDR3800 can't cope...

On Sat, 30 Aug 2014 14:02:57 +0300 Jonathan Morton wrote: > It seems that TBF has dire warnings all over it about having limited > packet-rate capacity which depends on the value of HZ, while HTB has some > sort of solution to that problem. Packet scheduling has not depended on HZ for 3 or mor

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

On Sat, 30 Aug 2014 09:05:58 +0300 Jonathan Morton 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 > >> to >

Re: [Bloat] curious.....

On Sat, 21 Dec 2013 20:38:41 -0500 Dan Siemon wrote: > On Sun, 2013-12-08 at 20:02 +0100, Sebastian Moeller wrote: > > About prioritizing, I am less optimistic as I can not see how the system > > can behave well under extreme load; I for one would be quite unhappy if an > > device on my interna

Re: [Bloat] curious.....

On Sun, 08 Dec 2013 12:41:52 -0800 Hal Murray wrote: > > > Even at 1000 symmetric I still think it would be a good idea to isolate > > really latency critical traffic from the rest, even if under normal > > circumstances there should be no problem, I guess a "better safe than sorry" > > appr

Re: [Bloat] T-Mobile LTE buffer bloat

On Thu, 31 Oct 2013 00:34:12 +0100 (CET) Mikael Abrahamsson 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

[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??? Might

[Bloat] Fw: video about QFQ+ and DRR

Thought this might be interesting to this list. --- From: Paolo Valente Hi, I just uploaded the following 7-minute video showing the QoS and the execution time of QFQ+, compared to those of DRR: http://youtu.be/bG2ACt4na7A I would like to advertise this video. If I may ask for your help, do you

Re: [Bloat] sweet tcp

On Tue, 9 Jul 2013 19:38:40 +0200 Jaume Barcelo 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, the performance is

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

On Fri, 28 Jun 2013 01:33:22 -0700 Hal Murray 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 network > protoco

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 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 accuracy at high rate

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

On Tue, 14 May 2013 15:48:38 +0200 Jesper Dangaard Brouer 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 recomment tools

Re: [Bloat] [aqm] PIE code available

On Fri, 10 May 2013 16:39:05 -0700 Vijay Subramanian wrote: > Hi folks, > > We are finally in a position to release the PIE (Proportional Integral > controller Enhanced) Linux code. > Many of you are already aware of the work at IETF and discussions on PIE on > the aqm and bloat mailing lists. T

Re: [Bloat] Solving bufferbloat with TCP using packet delay

On Thu, 21 Mar 2013 07:21:52 +1100 grenville armitage wrote: > > > On 03/21/2013 02:36, Steffan Norberhuis wrote: > > Hello Everyone, > > > > For a project for the Delft Technical University myself and 3 > > students are writing a review paper on the buffer bloat problem and > > its possible so

Re: [Bloat] Flow queuing performance (was: Re: [tsvwg] New Version Notification for draft-baker-tsvwg-aqm-recommendation-00.txt)

On Sun, 17 Mar 2013 15:12:16 -0400 Jim Gettys wrote: > As a result, at the last Linux Plumber's Conference in August, there was > general consensus that we could replace PFIFO_FAST as the default qdisc in > Linux, awaiting just our confidence that fq_codel (or something very > similar) was mature

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 whe

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

On Wed, 10 Oct 2012 19:27:11 -0400 Michael Richardson 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> far

[Bloat] OSCON Ignite?

Is anybody coming to Oscon? I was thinking about doing a Bufferbloat talk during their Ignite session. On Monday evening, July 16, we'll be hosting Ignite OSCON and we're looking for presenters. Ignite is a series of high-energy "speed presentations." Each presenter gets five minutes on s

Re: [Bloat] high speed networking from userspace

On Tue, 13 Mar 2012 13:28:52 +0100 Hagen Paul Pfeifer wrote: > > On Mon, 12 Mar 2012 17:09:44 -0700, Dave Taht 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. > > > > shades of VJ's 'network

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

On Thu, 08 Dec 2011 17:06:03 +0100 Eric Dumazet 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, we now use a rec

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

On Wed, 17 Aug 2011 18:26:00 -0700 "Patrick J. LoPresti" 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 connectivity.

Re: [Bloat] Notes about hacking on AQMs

On Wed, 8 Jun 2011 10:52:07 -0600 Dave Taht wrote: > On Wed, Jun 8, 2011 at 10:41 AM, Eric Dumazet 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 classifier' idea for DSCP+firew

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

On Sat, 7 May 2011 19:39:22 +0300 Jonathan Morton 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

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

On Fri, 6 May 2011 14:56:01 -0700 Fred Baker wrote: > > On May 6, 2011, at 8:14 AM, richard wrote: > > If every packet takes two attempts then the ratio will be 1/2 - 1 unit > > of googput for two units of throughput (at least up to the choke-point). > > This is worst-case, so the ratio is likel

  1   2   >