davecb

It's certainly killing companies, and multiple products that are open source. However, the community has the experience and knowledge to push back. Consider the Hashicorp license change in Terraform. A small community of businesses users forked it to create OpenTofu.

When an open source project starts to fail, it gets forked. If few use it, the new team will be small and mostly hobbyists. If multiple large companies are using the project, the new team will be larger, with more resources to help their sponsors and everyone else to move.

Broadcom is a rentier. That works if the program is closed-source. Less so with the Bitnami source code which is open-source and on GitHub.

Unconfirmed reports have Australia, Canada, New Zealand and the United Kingdom considering dropping the United States from the five eyes, and inviting the EU in its place.

The putative reason is that they are concerned about the shared information being used by Mr Trump in a manner harmful to the other countries.

In addition, Mr Trump has proposed that the five eyes expel Canada, because of their current economic disagreements. That doesn't sit well with anyone (:-))

That's just a comparison to Star Trek, which is set in an imaginary universe where things _do_ exceed the speed of light.

Yup, it was Rogers, which is what my building has, and which I'm stuck with for TV. Other, luckier, people can have Bell (sorta-maybe better) or TekSavvy (definitely better)

The terrible performance is spotty: that was a particularly glaring example I detected when everything was failing (:-))

On of my _evil hidden agendas_ is making end-users aware that their ISP (Rogers, anyone?) is doing a terrible job, and someone like TekSavvy can solve their problems for them (;-))

Hi, Dave here.

I recommend using a small box running LibreQoS adjacent to the big router. Large-scale routers based on Application-Specific ICs do a wonderful job, but are hard to change. Having a transparent fix in an inexpensive device now is way better than waiting and hoping that the router vendor can update their ASICs (:-))

I emphasised your problem in a video about the article, at https://vimeo.com/1017926413

I have another article in the "You Don't Know jack" series from the ACM, now in the November Communications of the ACM (the print magazine), and a 5-minute video about it at https://vimeo.com/1017926413

This is a follow-on from Dave Taht's "bufferbloat" work, now a project called LibreQoS, where QoS stands for Quality of Service.

If you are having trouble with unintelligible con-calls or gaming lag, have a peek.

Sorry, I think you are thinking of something else. Maybe a railroad crossing (:-))

Joking aside, the https://www.waveform.com/tools/bufferbloat test looks to see if the networking software is working correctly by putting a large load on the network, and then seeing if other streams are affectec by the overload.

The example on the https://libreqos.io/ home page is of * good software delivering 9 and 23 milliseconds down/up latency at full load * bad software delivering 106 and 517 milleseconds latency under load.

It is, in effect, a test for software failure under load

Oh goodness no, always measure latency under full load, in the middle of the bandwidth test. A convenient example is https://www.waveform.com/tools/bufferbloat which can easily tell crappy ISPs from good ones

> Latency to where? Greyface also asks "Latency is an end-to-end metric which will almost always involve path components beyond the control of your ISP - can and should they be held responsible for those paths?"

The latency you see is almost always from last-mile software, under the control of the ISP, and can be fixed locally. Before fixing, my local ISP gave me ping-time to the internet interconnect point in downtown Toronto that were typical of a link to Istanbul, Turkey (:-))

They weren't trying, and aren't to this day. Arguably they need a nice unfriendly regulator to require at least a good-faith attempt.

I often get spikes of delay showing up in https://test.vsee.com/network/index.html while on conference calls. Those correspond to periods in which speakers "sound like aliens", "have fallen down a well" or simply freeze up.

Having a standard that ignores that is less than useful. It's the standards body showing disrespect for the people it's supposedly creating the standard _for_.

The bottleneck device can change with every different destination, so CAKE and fq_codel find it the same way older TCP code did: increase the load until they get a timeout or a "slow down, you idiot" flag (:-))

The initial bandwidth setting is really to get it started at a good value for your usual bottleneck device, such as your local cable modem.

Always starting off as if you had fast ethernet to the ISP when you actually have a super-el-cheapo link is a waste of time and effort. Even if you have a good algorithm like CAKE.

--dave

ACM noticed a trend and created the "You Don't Know Jack" series to capture more of them.

I was attracted to my current employer when the ops director said almost exactly what you did in your last sentence. He wanted our dev/ops arm to be numerate and to work in dollars and TPS.

We actually do capacity planning in dollars to this day, and did do queuing models of both batch and multi-core, multi-machine transaction processing.

Some times the tag line is what needs to be used: I see HN quoted it, so we're doing something right...

I do exactly that plot, usually for CPU, occasionally for rotating-rust disks or for memory in non-GC languages. If a day's normal variation doesn't make a machine busy enough, I usually fiddle with the load-balancer to git it more work (;-))

I entirely agree: I used to run the performance team at Sun Canada, and 99% of the time, we were on a bottleneck-hunt. Annoyingly, the bottleneck was rarely in the first place we looked (;-))

Benchmarks are well-known, well-understood and popular. They aren't what capacity planners and performance engineers use, though.

Did the tag line "How capacity planners credibly estimate application performance (acm.org)" show up?

The ACM series is called "you don't know jack", but the tag line is supposed to distinguish it from all the other "jack" articles.

And yes, the series title is not want you want for something like HN.

Yes, every resource-exhaustion causes a bottleneck, and a queue builds up. My effort here is to try and tell people to look in the right place to spot the bottleneck. That's a lot easier than a measurement exercise.

I sort of lump the "do a benchmark" advice in with "look under the lightpost, it's much brighter there" when you've lost your car-keys in a dark garage (;-))

"Packet loss" is more interesting to nerds than consumers, who don't know what it means. Arguably it needs a better name.

"Delays due to retransmission" is short enough to fit the label, and is what a packet loss means _to the reader of the label_, rather than to me.

From thew point of view of a capacity planner and performance engineer, one goes for low latency first, because for many algorythms, the best throughput is seen when latency is lowest. Some cases will be different, but starting with removing time wasted sitting in a queue is A Universal Good (;-))

I keep seeing papers with the lede paragraph and sometimes the conclusions written in a different voice that the rest of the paper. I suspect "men of good faith but limited understanding" are contributing to the editing (;-))