[Bloat] Clearing out the moderation queues

--- Begin Message --- Hey everyone I'm going through the moderation queue of these two lists, and, well, turns out there was a bit of a backlog. Up to four years of backlog, in fact. I'm letting everything through that is not spam, so if you're wondering why a lot of old emails suddenly show up

Re: [Bloat] Quick question about lists

--- Begin Message --- Erika Miller writes: > Quick question about lists > Is it okay if we feature lists.bufferbloat in our next email newsletter? > It's a perfect fit for a piece we're doing and I think our audience would > find some of the content on your site super useful. Hi Erika Your

Re: [Bloat] this explains speedtest stuff

--- Begin Message --- Kenneth Porter writes: > On 4/23/2020 6:20 PM, Dave Taht wrote: >> I used layer_cake with this overriding the defaults on my cable modems >> in /etc/config/sqm >> >> option iqdisc_opts 'docsis wash besteffort nat ingress ' >> option eqdisc_opts 'docsis

Re: [Bloat] this explains speedtest stuff

--- Begin Message --- Kenneth Porter writes: > On 4/25/2020 9:00 AM, Dave Taht wrote: >> Oh, I misread your report. I thought this was cake, not fq_codel. Care >> to try that? > > I'd love to if I knew how to add cake to CentOS 7. I've installed kernel > modules for unsupported Ethernet

Re: [Bloat] this explains speedtest stuff

--- Begin Message --- Kenneth Porter writes: > Maybe we need some Youtube videos showing end user experiences of the > benefit of reduced latency. The (now defunct) RITE project did this one, which I thought was rather good: https://youtu.be/F1a-eMF9xdY -Toke --- End Message ---

Re: [Bloat] CAKE in openwrt high CPU

Mikael Abrahamsson writes: > On Tue, 1 Sep 2020, Toke Høiland-Jørgensen wrote: > >> Yup, the number of cores is only going to go up, so for CAKE to stay >> relevant it'll need to be able to take advantage of this eventually :) > > https://www.hardkernel.com/shop/odroid-h2plus/ is an interesting

Re: [Bloat] CAKE in openwrt high CPU

Luca Muscariello writes: > On Thu, Sep 3, 2020 at 3:19 PM Mikael Abrahamsson via Bloat > wrote: >> >> On Tue, 1 Sep 2020, Toke Høiland-Jørgensen wrote: >> >> > Yup, the number of cores is only going to go up, so for CAKE to stay >> > relevant it'll need to be able to take advantage of this

Re: [Bloat] CAKE in openwrt high CPU

Mikael Abrahamsson writes: > On Mon, 31 Aug 2020, Toke Høiland-Jørgensen wrote: > >> And what about when you're running CAKE in 'unlimited' mode? > > I tried this: > > # tc qdisc add dev eth0 root cake bandwidth 900mbit So the difference from before is just the lack of inbound shaping, or?

Re: [Bloat] CAKE in openwrt high CPU

On 3 September 2020 17:31:07 CEST, Luca Muscariello wrote: >On Thu, Sep 3, 2020 at 4:32 PM Toke Høiland-Jørgensen >wrote: >> >> Luca Muscariello writes: >> >> > On Thu, Sep 3, 2020 at 3:19 PM Mikael Abrahamsson via Bloat >> > wrote: >> >> >> >> On Tue, 1 Sep 2020, Toke Høiland-Jørgensen

[Bloat] Applying FQ-CoDel to multipath tunnelled QUIC

This popped up in my Google Scholar alerts: https://www.diva-portal.org/smash/get/diva2:1451478/FULLTEXT02 It's a master's thesis (from my old university in Karlstad) describing an integration of FQ-CoDel into a QUIC-based tunnel implementation, with what seems to be very nice results[0] :)

Re: [Bloat] CAKE in openwrt high CPU

Mikael Abrahamsson via Bloat writes: > Hi, > > I migrated to an APU2 (https://www.pcengines.ch/apu2.htm) as residential > router, from my previous WRT1200AC (marvell armada 385). > > I was running OpenWrt 18.06 on that one, now I am running latest 19.07.3 > on the APU2. > > Before I had

Re: [Bloat] CAKE in openwrt high CPU

Jonathan Foulkes writes: >> Right, so some benefit might be possible here. Does the NIC have >> multiple hardware queues (`ls /sys/class/net/$IFACE/queues` should tell >> you)? > > Here is the output of: > /sys/devices/virtual/net/eth0.2/queues# ls > rx-0 tx-0 >

Re: [Bloat] How about a topical LWN article on demonstrating the real-world goodness of CAKE?

Dave Collier-Brown writes: > LWN said OK, but I'm stuck on the search for a striking test, one that > resonates with "grandma". > > My next two thoughts, probably for the current long weekend, is either > to call a loop-back number with Skype and/or ask Toke how he got "Big > Buck Bunny" to

Re: [Bloat] Other CAKE territory (was: CAKE in openwrt high CPU)

David Collier-Brown writes: > On 2020-09-03 10:32 a.m., Toke Høiland-Jørgensen via Bloat wrote > >> Yeah, offloading of some sort is another option, but I consider that >> outside of the "CAKE stays relevant" territory, since that will most >> likely invol

Re: [Bloat] CAKE in openwrt high CPU

Jonathan Foulkes writes: > Toke, that link returns a 404 for me. Ah, seems an extra character snuck in at the end - try this: https://github.com/dtaht/sch_cake/commit/3152477235c934022049fcddc063c45d37ec10e6 > For others, I’ve found that testing cake throughput with isolation options >

Re: [Bloat] CAKE in openwrt high CPU

Sebastian Moeller writes: > Hi Toke, > > >> On Sep 1, 2020, at 18:11, Toke Høiland-Jørgensen via Bloat >> wrote: >> >> Jonathan Foulkes writes: >> >>> Toke, that link returns a 404 for me. >> >> Ah, seems an extra character snu

Re: [Bloat] CAKE in openwrt high CPU

Mikael Abrahamsson writes: > On Mon, 31 Aug 2020, Toke Høiland-Jørgensen wrote: > >> Hmm, you say CAKE and FQ-Codel - so you're not enabling the shaper (that >> would be FQ-CoDel+HTB)? An exact config might be useful (or just the >> output of tc -s qdisc). > > Yeah, I guess I'm also using HTB to

Re: [Bloat] CAKE in openwrt high CPU

Jonathan Morton writes: >> On 1 Sep, 2020, at 9:45 pm, Toke Høiland-Jørgensen via Bloat >> wrote: >> >> CAKE takes the global qdisc lock. > > Presumably this is a default mechanism because CAKE doesn't handle any > locking itself. > > Obviously it

Re: [Bloat] CAKE in openwrt high CPU

Jonathan Foulkes writes: > Thanks Toke, we currently are on an MT7621a @880, so a dual-core. Right, so some benefit might be possible here. Does the NIC have multiple hardware queues (`ls /sys/class/net/$IFACE/queues` should tell you)? > And we are looking for a good quad-core platform that

Re: [Bloat] cake + ipv6

Daniel Sterling writes: > On Mon, Sep 28, 2020 at 11:14 AM Toke Høiland-Jørgensen wrote: >> It depends. A 'sparse' flow should get consistent priority > >> That's per flow. But you're misunderstanding the 100ms value. That's the >> 'interval', which is (simplifying a bit) the amount of time

Re: [Bloat] cake + ipv6

Daniel Sterling writes: > I guess the reason I'm surprised is I'm confused about the following: > > For UDP streams that use <1mbit down , should I expect cake in ingress > mode to keep those at low latency even in the face of a constantly > full queue / backlog, using "besteffort" but also

[Bloat] Detecting FQ at the bottleneck

This popped up in my Google Scholar mentions: https://arxiv.org/pdf/2010.08362 It proposes using a delay-based CC when FQ is present, and a loss-based when it isn't. It has a fairly straight-forward mechanism for detecting an FQ bottleneck: Start two flows where one has 2x the sending rate than

Re: [Bloat] Phoronix: Linux 5.9 to allow FQ_PIE as default

Rich Brown writes: > Is there any "there" here? I'm sorry, what? :) > https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1193738-linux-5-9-to-allow-defaulting-to-fq-pie-queuing-discipline-for-fighting-bufferbloat As far as the patch, allowing fq_pie as default makes sense

Re: [Bloat] Is still netperf a valid tool?

--- Begin Message --- Sergio Belkin writes: > Hi, > I've seen that many of the recommended tools to diagnose/troubleshoot > bufferbloat use netperf. > Netperf in https://github.com/HewlettPackard/netperf has many years of > inactivity. In fact, in recent versions of distros don't include it. >

[Bloat] Finally shipping: Second print run of "Bufferbloat and Beyond" (my thesis)

--- Begin Message --- Hi everyone Dave already spilled the beans a few months ago. However, everything got delayed by COVID-related logistics challenges, and since this has now finally been cleared up and shipping has commenced, I thought I'd make an "official" announcement: The second print run

Re: [Bloat] [Ecn-sane] Fwd: [tsvwg] Fwd: Working Group Last Call: QUIC protocol drafts

--- Begin Message --- Dave Taht writes: > I am happy to see quic in last call. there are a ton of interoperble > implementations now. And in related news, this RFC of pacing from userspace was posted on netdev yesterday:

Re: [Bloat] New speed/latency/jitter test site from Cloudflare

--- Begin Message --- Adam Hunt writes: > https://speed.cloudflare.com/ > https://blog.cloudflare.com/test-your-home-network-performance/ > https://news.ycombinator.com/item?id=23313657 Ah, cool; we already had a mention of this the other day, but didn't see the announcement or discussion.

Re: [Bloat] New speed/latency/jitter test site from Cloudflare

--- Begin Message --- Jonathan Morton writes: >> On 3 Jun, 2020, at 7:48 pm, Dave Taht wrote: >> >> I am of course, always interested in how they are measuring latency, and >> where. > > They don't seem to be adding more latency measurements once the > download tests begin. So in effect they

Re: [Bloat] What's a good non-intrusive way to look at bloat (and perhaps things like gout (:-))

--- Begin Message --- Jonathan Morton writes: >> On 4 Jun, 2020, at 1:21 am, Dave Collier-Brown >> wrote: >> >> We've good tools to measure network performance under stress, by the >> simple expedient of stressing it, but is there a good approach I >> could recommend to my company to monitor

Re: [Bloat] Phoronix: Linux 5.9 to allow FQ_PIE as default

Jonathan Morton writes: > In any case, it is already possible to chose any qdisc you like (with > default parameters) as the default qdisc. I'm really not sure what > the fuss is about. No, it isn't - not at compile time. Which is what the phoronix post references. It's literally this commit:

Re: [Bloat] Phoronix: Linux 5.9 to allow FQ_PIE as default

Rich Brown writes: > I was asking whether there was anything "there" (that is, interesting) > in that Phoronix posting / Linux announcement. Ah. No, as I said, not really; the patch just added fq_pie to the list of qdiscs that can be set as default via sysctl... >> On Jul 15, 2020, at 9:02 AM,

Re: [Bloat] Xfinity Flex streaming box starves on cake?

Kenneth Porter writes: > I suspect that my Xfinity Flex box has too small an internal buffer and is > starving when fed by my cake-enabled OpenWrt router. From your config you have around 10x the downstream bandwidth you need for streaming, so unless you are really hitting your connection hard

Re: [Bloat] Why you need at least 3Mbps upload to get good game performance with ~1500byte packets: Doing the math

Sebastian Moeller writes: > Hi Toke, > > >> On Dec 9, 2020, at 12:20, Toke Høiland-Jørgensen wrote: >> >> Sebastian Moeller writes: >> >>> Hi Toke, >>> >>> >>>> On Dec 9, 2020, at 11:52, Toke Høiland-Jørgensen via B

Re: [Bloat] Why you need at least 3Mbps upload to get good game performance with ~1500byte packets: Doing the math

Kenneth Porter writes: > > > Upstream article: > >

Re: [Bloat] Why you need at least 3Mbps upload to get good game performance with ~1500byte packets: Doing the math

Sebastian Moeller writes: > Hi Toke, > > >> On Dec 9, 2020, at 11:52, Toke Høiland-Jørgensen via Bloat >> wrote: >> >> Kenneth Porter writes: >> >>> <https://forum.openwrt.org/t/why-you-need-at-least-3mbps-upload-to-get-good-game-per

Re: [Bloat] BBR implementations, knobs to turn?

Jesper Dangaard Brouer writes: > Hi Erik, > > I really appreciate that you are reaching out to the bufferbloat community > for this real-life 5G mobile testing. Lets all help out Erik. Yes! FYI, I've been communicating off-list with Erik for quite some time, he's doing great work but fighting

Re: [Bloat] configuration on an OpenVPN server

Matt Taggart writes: > Hi, > > I would like to configure SQM on an OpenVPN server and I am thinking > about how to do this. I have already setup piece_of_cake on the upstream > connection(in this case 900Mbit down/250Mbit up). I think that by itself > should do a decent job of keeping things

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

>> Also, it's TX, and we are only doing RX, as I said already somewhere, >> it's async routing, so the TX data comes via another router back. > > Okay, but as this is a router you also need to transmit this > (asymmetric) traffic out another interface right. > > Could you also provide

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

Thomas Rosenstein via Bloat writes: > Hi all, > > I'm coming from the lartc mailing list, here's the original text: > > = > > I have multiple routers which connect to multiple upstream providers, I > have noticed a high latency shift in icmp (and generally all connection) > if I run b2

Re: [Bloat] We built a new bufferbloat test and keen for feedback

Sam Westwood writes: > Hi everyone, > > My name is Sam and I'm the co-founder and COO of Waveform.com. At Waveform > we provide equipment to help improve cell phone service, and being in the > industry we've always been interested in all aspects of network > connectivity. Bufferbloat for us has

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

"Thomas Rosenstein" writes: > On 4 Nov 2020, at 17:10, Toke Høiland-Jørgensen wrote: > >> Thomas Rosenstein via Bloat writes: >> >>> Hi all, >>> >>> I'm coming from the lartc mailing list, here's the original text: >>> >>> = >>> >>> I have multiple routers which connect to multiple upstream

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

"Thomas Rosenstein" writes: >> If so, this sounds more like a driver issue, or maybe something to do >> with scheduling. Does it only happen with ICMP? You could try this >> tool >> for a userspace UDP measurement: > > It happens with all packets, therefore the transfer to backblaze with 40 >

Re: [Bloat] We built a new bufferbloat test and keen for feedback

Dave Collier-Brown writes: > Tried it, and I really like the header and use of candle-charts! > > I got this: > > [cid:part1.81AC21AC.758FE66F@indexexchange.com] > > I'd like to be able to explain it to non-techie folks (my grandma, and also > my IT team at work (;-)), so I wonder on their

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

"Thomas Rosenstein" writes: > On 5 Nov 2020, at 12:21, Toke Høiland-Jørgensen wrote: > >> "Thomas Rosenstein" writes: >> If so, this sounds more like a driver issue, or maybe something to do with scheduling. Does it only happen with ICMP? You could try this tool for a

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

"Thomas Rosenstein" writes: > On 5 Nov 2020, at 13:38, Toke Høiland-Jørgensen wrote: > >> "Thomas Rosenstein" writes: >> >>> On 5 Nov 2020, at 12:21, Toke Høiland-Jørgensen wrote: >>> "Thomas Rosenstein" writes: >> If so, this sounds more like a driver issue, or maybe something

Re: [Bloat] Comparing bufferbloat tests (was: We built a new bufferbloat test and keen for feedback)

Dave Collier-Brown writes: > On 2020-11-05 6:48 a.m., Toke Høiland-Jørgensen via Bloat wrote: > > Also, holy cow, what's going on with your connection? The unloaded > latency says 17/110/200 min/median/max RTT. Is that due to bad > measurements, or do you have a lot of cross traff

Re: [Bloat] Comparing bufferbloat tests (was: We built a new bufferbloat test and keen for feedback)

> I believe TLS handshake time is not included here. I’m using the > Resource Timing API > > to measure the time-to-first-byte for a request that I’m sending to > retrieve a static file. The resource loading phases >

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

"Thomas Rosenstein" writes: > On 6 Nov 2020, at 12:18, Jesper Dangaard Brouer wrote: > >> On Fri, 06 Nov 2020 10:18:10 +0100 >> "Thomas Rosenstein" wrote: >> > I just tested 5.9.4 seems to also fix it partly, I have long > stretches where it looks good, and then some increases again.

Re: [Bloat] Comparing bufferbloat tests (was: We built a new bufferbloat test and keen for feedback)

Stephen Hemminger writes: > PS: Why to US providers have such asymmetric bandwidth? Getting something > symmetric > requires going to a $$$ business rate. For Cable, the DOCSIS standard is asymmetric by design, but not *that* asymmetric. I *think* the rest is because providers have to assign

Re: [Bloat] Openwrt stability?

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

Re: [Bloat] Rebecca Drucker's talk sounds like it exposes an addressable bloat issue in Ciscos

Jonathan Morton writes: > The virtual-clock algorithm I implemented in Cake is essentially a > deficit-mode algorithm. During any continuous period of traffic > delivery, defined as finding a packet in the queue when one is > scheduled to deliver, the time of delivering the next packet is >

Re: [Bloat] Thanks to developers / htb+fq_codel ISP shaper

Robert Chacon writes: >> Cool! What kind of performance are you seeing? The README mentions being >> limited by the BPF hash table size, but can you actually shape 2000 >> customers on one machine? On what kind of hardware and at what rate(s)? > > On our production network our peak throughput is

Re: [Bloat] Thanks to developers / htb+fq_codel ISP shaper

Robert Chacon writes: > Toke, > > Thank you very much for pointing me in the right direction. > I am having some fun in the lab tinkering with the 'mq' qdisc and Jesper's > xdp-cpumap-tc. > It seems I will need to use iptables or nftables to filter packets to > corresponding queues, since mq

Re: [Bloat] Measuring CoDel

Hal Murray writes: > Toke said: >> Yeah, the overhead of CoDel itself (and even FQ-CoDel) is basically nil (as >> in, we have not been able to measure it), when otherwise doing forwarding >> using the regular Linux stack. > > I may be able to help with that. > > Are you familiar with Dick

[Bloat] New OpenWrt release fixing several dnsmasq CVEs

Hi everyone In case you haven't seen, there's a new OpenWrt release out[0] that fixes several CVEs in dnsmasq; seems like quite a bunch at once[1]. So in the interest of keeping everyone's routers safe, here's a gentle nudge to update :) -Toke [0]

Re: [Bloat] Thanks to developers / htb+fq_codel ISP shaper

Robert Chacon writes: > Hello everyone, > > I am new here, my name is Robert. I operate a small ISP in the US. I wanted > to post here to thank Dave Täht, as well as the dozens of contributors to > the fq_codel and cake projects. Thank you for reaching out! It's always fun to hear about

[Bloat] Fwd: [ncc-announce] [news] Apply now for the RIPE NCC Community Projects Fund

Figured this might be of interest to some people here :) -Toke --- Begin Message --- Hello, For the fifth year in a row, the RIPE NCC is committing to support activities and projects for 'the good of the Internet'. We are pleased to invite applications for funding from the RIPE NCC Community

Re: [Bloat] Fwd: Traffic shaping at 10~300mbps at a 10Gbps link

Jonathan Morton writes: >> On 7 Jun, 2021, at 8:28 pm, Rich Brown wrote: >> >> Saw this on the lartc mailing list... For my own information, does anyone >> have thoughts, esp. for this quote: >> >> "... when the speed comes to about 4.5Gbps download (upload is about >> 500mbps), chaos kicks

[Bloat] Freenode IRC kerfuffle

Hi everyone In case you haven't noticed, there's been quite a kerfuffle around the Freenode IRC network. As always, LWN has excellent coverage[0]. This has resulted in quite an exodus from Freenode, and since some people were hanging on the #bufferbloat channel there, I figured I'd mention it on

Re: [Bloat] Little's Law mea culpa, but not invalidating my main point

"Holland, Jake via Bloat" writes: > Hi David, > > That’s an interesting point, and I think you’re right that packet > arrival is poorly modeled as a Poisson process, because in practice > packet transmissions are very rarely unrelated to other packet > transmissions. > > But now you’ve got me

Re: [Bloat] UniFi Dream Machine Pro

Sebastian Moeller writes: > I am confident that this device will happily run CoDel and even > fq_codel close to line-rate, as codel/fq_codel have a relative modest > processing cost. Yeah, the overhead of CoDel itself (and even FQ-CoDel) is basically nil (as in, we have not been able to measure

Re: [Bloat] New OpenWrt release fixing several dnsmasq CVEs

Jonathan Foulkes writes: > I installed the updated package on a 19.07.4 box running cake, and QoS > performance went down the tubes. > Last night it locked up completely while attempting to stream. > > See the PingPlots others have posted to this forum thread, mine look similar, > went from

Re: [Bloat] New OpenWrt release fixing several dnsmasq CVEs

Daniel Sterling writes: > On Fri, Jan 22, 2021 at 4:25 PM Jonathan Foulkes > wrote: >> I did not install .6, I only performed an opkg update of the dnamasq package >> itself. So kernal is the same in my case. > > given you just updated the package -- that's extremely weird. > userspace update

[Bloat] Netperf re-licensed as MIT

Hopefully this means we can get it packaged for the distros that have thus far refused to because of the license - i.e., Debian and Fedora! -Toke ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] Netperf re-licensed as MIT

Dave Taht writes: > so glad to hear the license has been fixed. > > carl, iperf is only used in a few of flent's tests. We trusted netperf > - as did the linux kernel developers - a lot further than all the > iperf variants combined - at the time we started work on flent. And, more importantly,

Re: [Bloat] Netperf re-licensed as MIT

Aaron Wood writes: > One of my long concerns with the RRUL test is that the ICMP ping test > portion is not isochronous That would be the UDP_RR test, you mean (ICMP is isochronous)? Yeah, that is a bit annoying, but as Dave says if irtt is available, Flent will use that, and that *is*

Re: [Bloat] Netperf re-licensed as MIT

Aaron Wood writes: > iperf3 isn’t “academic”, but is more focused on scientific computing (ESNet > pushes a LOT of data CERN around, on 100Gbps backbones). > > But that also skews their usage/needs. Very high throughput bulk transfers > with long durations, over mixed systems. Not as many

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] [Cake] Fwd: [Galene] Dave on bufferbloat and jitter at 8pm CET Tuesday 23

Dave Taht writes: > 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. We have a PhD student working on a

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

Taraldsen Erik writes: > Disclamer: I'm working on the Fixed Wireless products for Telenor > (Zyxel NR7101 outdoor wall mounted unit). Not the Mobile Broadband > products. We are working with Zyxel and Qualcom to try and implement > an upstream queue which adapts to available radio resources. To

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

Nils Andreas Svee writes: > 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

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

Taraldsen Erik writes: > This is getting LTE/5G spesific. Not sure if it belongs on the list. > Let us know if we are generating noise. I for one think it's fascinating - carry on! :) -Toke ___ Bloat mailing list Bloat@lists.bufferbloat.net

Re: [Bloat] Trouble Installing PPing in MacOS

Jason Iannone writes: > Ideally, always on monitoring and export at the PE. An incremental first > step in an adhoc off box tester, maybe deployed with the perfsonar suite. Right. Are any of those boxes Linux-based? Otherwise the BPF implementation is not much use to you :) > Meaningfully

Re: [Bloat] Trouble Installing PPing in MacOS

Jason Iannone writes: > Beyond getting acquainted with a new dataset? I'm a transit network that > supports, among other traffic types, science flows. I think new monitoring > methods can help identify targets for intervention. Right, I meant more in terms of deployment: are you looking to run

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

On 24 February 2021 23:49:48 CET, Nils Andreas Svee wrote: >I'll look into pping. Admittedly I'm quite ignorant about BPF, so I'll >likely blunder about for a bit, but hey, got it to compile - *and* run, >but I didn't get any output other than the messages from clean_map. >Dunno if I did

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

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] Trouble Installing PPing in MacOS

TJason Iannone writes: > I ended up cloning the pping repo and running make locally. > > Installing was a few steps: > > 1. mkdir ~/src/libtins/build > 2. cd ~/src/libtins/build > 2. git clone https://github.com/mfontanini/libtins.git > 3. make > 4. sudo make install > 5. cd ~/src > 6. git clone

Re: [Bloat] HardenedBSD implementation of CAKE

"Mark D." writes: > Hello all, > I am wondering if anyone is working on implementing fq_codel or CAKE on the > HardenedBSD network stack? A few popular firewall and router distributions > use this OS, and I believe that it would be beneficial for it to have AQM. > If this work has already been

Re: [Bloat] Beyond Bufferbloat: End-to-End Congestion Control Cannot Avoid Latency Spikes

Bjørn Ivar Teigen writes: > Hi everyone, > > I've recently published a paper on Arxiv which is relevant to the > Bufferbloat problem. I hope it will be helpful in convincing AQM doubters. > Discussions at the recent IAB workshop inspired me to write a detailed > argument for why end-to-end

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

"Valdis Klētnieks" writes: > On Wed, 01 Dec 2021 13:09:46 -0800, David Lang said: > >> with wifi where you can transmit multiple packets in one airtime slot, you >> need >> enough buffer to handle the entire burst. > > OK, I'll bite... roughly how many min-sized or max-sized packets can you

Re: [Bloat] Up-to-date buffer sizes?

Michael Menth writes: > Hi all, > > are there up-to-date references giving evidence about typical buffer > sizes for various link speeds and technologies? Heh. There was a whole workshop on it a couple of years ago; not sure if it concluded anything:

Re: [Bloat] PhD thesis with results related to buffering needs on variable-capacity links

Bjørn Ivar Teigen via Bloat writes: > Hi everyone, > > I defended my PhD in December. I hope some of the results are interesting > to the bufferbloat community. > > The title is "Opportunities and Limitations in Network Quality > Optimization: Quality Attenuation Models of WiFi Network

Re: [Bloat] [bbr-dev] Aggregating without bloating - hard times for tcp and wifi

Bob McMahon writes: > Does the TSQ code honor no-aggregation per voice access class or > TCP_NODELAY where the app making the socket write calls knows that the WiFi > aggregation isn't likely helpful? Sorry, my Linux stack expertise is quite > limited. TSQ only influences the buffering in the

Re: [Bloat] [bbr-dev] Aggregating without bloating - hard times for tcp and wifi

Neal Cardwell via Bloat writes: > On Tue, Nov 22, 2022 at 2:43 PM 'Bob McMahon' via BBR Development < > bbr-...@googlegroups.com> wrote: > >> Thanks for sharing this. Curious about how the xTSQ value can be set? Can >> it be done with sysctl? >> >> *We continue our analysis by using the

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

"David P. Reed via Bloat" writes: > (One such nightmare can be seen in LKML... Search for > dpr...@deepplum.com patch emails. I tried hard, was worn down, then > gave up, since I found a way to avoid the bug, in virtualization code > on x86, and gave up on getting it fixed after a year. Life is

Re: [Bloat] The Confucius queue management scheme

Jonathan Morton writes: >> On 10 Feb, 2024, at 7:05 pm, Toke Høiland-Jørgensen via Bloat >> wrote: >> >> This looks interesting: https://arxiv.org/pdf/2310.18030.pdf >> >> They propose a scheme to gradually let new flows achieve their fair >> share o

[Bloat] The Confucius queue management scheme

This looks interesting: https://arxiv.org/pdf/2310.18030.pdf They propose a scheme to gradually let new flows achieve their fair share of the bandwidth, to avoid the sudden drops in the available capacity for existing flows that can happen with FQ if a lot of flows start up at the same time. No

Re: [Bloat] The sad state of MP-TCP

Juliusz Chroboczek writes: >>> There should be a knob in the kernel to transparently replace TCP with >>> MP-TCP, but I couldn't find one. > >> There is, sorta. Specifically, a BPF hook that can override the protocol >> (added in kernel 6.6): >> >>

Re: [Bloat] The sad state of MP-TCP

Juliusz Chroboczek via Bloat writes: > Unfortunately, MP-TCP does not replace TCP in Linux, it's implemented as > a separate transport protocol. That means that in order to use MP-TCP, > every application needs to be patched to use PROT_MPTCP instead of > PROT_TCP. Go applications need to call