PREEMPT-RT Locking Infrastructure Possibly Ready For Linux 5.15

[oiaohm]

You'll like it even less when you find out there is a bakers dozen which is 13. Though I have never known a baker that sold any thing in a bakers dozen.

https://sprinklepop.shop/products/ba...n-best-sellers

Its not common for stuff to be in the bakers/long dozen any more but its not totally uncommon in baking related stuff.

https://www.industry.gov.au/data-and...system-testing

There is a reason why a shop might have policy to provide a bakers dozen when you order a dozen and it to deal with law. Bottom of the above link explains why "AQS tests for number" explains why in most countries. You order 12(a dozen) and the shop 11 this is offensive under most countries laws. Now you order a 12(a dozen) and shop gives you 13 this is legal. So if you are going to error on count the error is safer one over than 1 under. Yes a lot of bakeries also do 13 instead of a dozen to counter weight issue as in your order a dozen they put the stuff on scale its light weight so they throw extra one in to put it over the expected weight.

Of course a shop selling a bakers/long dozen to deal with error is not normally going say they are selling a bakers/long dozen. Yes this does lead to some people living in some areas who buy stuff from a local bakery always working in bakers dozen to incorrect think a dozen is 13 not 12. Historic and legal reason why you get a bakers dozen 13 instead of a dozen 12 when you order a dozen is to make sure the shop provides you with at least what you legally ordered. Key words at least one extra is not legally a problem.

Yes items are sold in bakers dozens a lot more often than people would presume. This can be bolts, food.... all case where the counting system might be a little off so they go slightly high so a slight error does not mean breaking law just a little cut into the profit margin. Yes advertising material with a bakers dozen on it is lot rarer because the most common usage of bakers dozen is error management.

You also see a non dozen same thing where you order a lot of 100 and get between 100 to 110 Lot of those the machine is set to pack a 110 and packing process can goof up about 10% of the time so worse case packing 110 with 10 percent lost in the packing process still gives 100. This can also be to cover defective production as well. So you order 100 and they send you 100 with 10 defective they still sent you your 100.

Legal production and packing error management is oversupply.

[pal666]

I have never known a baker that sold any thing in a bakers dozen.

you live in a wrong century https://en.wikipedia.org/wiki/Dozen#Baker's_dozen

[mppix]

Oh, that sounds great:
I mean, what's better than having predictable latency?
Getting your safety-critical application randomly killed by a watchdog during operation, of course!
I'm sure both Boeing & Airbus are already eagerly looking forward to it...

Having a defined failure mode is always preferable than unpredictable behavior (at least in real-time systems) because you can better plan/mitigate them.
Safety critical systems are always redundant and you get at least two signals. It is better to have one correct signal than two or more competing ones (and no, quorum does not always work even if you have 3 or more signals).

[oiaohm]

Oh, that sounds great:
I mean, what's better than having predictable latency?
Getting your safety-critical application randomly killed by a watchdog during operation, of course!
I'm sure both Boeing & Airbus are already eagerly looking forward to it...

LOL. You don't know how wrong you are. The full glass cockpit systems(fly by wire) of boeing and airbus do have hard realtime do have watchdog on those hard real time that will kill the real-time processors if their behaviour comes abnormal to prevent system starvation. The idea for rtkit comes from the Airbus real-time policy system for their watchdog.

All the problems listed with hard real-time have to be addressed when you design a full glass cockpit. Yes these cockpit systems get to insane that the system has to be able to reboot in 1 second or less and System resource starvation caused by 1 process cannot be allowed and in normal operation hard real-time events must happen.

Linuxx think about this for one min of a system that is running more than 1 hard real-time process one of those process is allowed to go abnormal and lock up the cpu time the result could be all processors now not meet their hard real-time deadline. So what is more unsafe killing one miss behaving hard real-time process(that is using abnormal amount of time) or having all hard real-time processes fail because one real-time process used excessive time. There can be very good reason to split safety-critical things up into multi independent processors with a watchdog over the top so you are not putting all your safety eggs in one basket.

[Linuxxx]

As in you attempt to have a hard realtime application so something system destroying the rtkit watchdog will kill the application.

The ubuntu case against hard realtime also does not allow for items like rtkit that make hard realtime fairly safe.

Oh, that sounds great:
I mean, what's better than having predictable latency?
Getting your safety-critical application randomly killed by a watchdog during operation, of course!
I'm sure both Boeing & Airbus are already eagerly looking forward to it...

[wertigon]

Wow, are we still talking about Linux here? In my country's enterprise/industrial sector we're still largely dependent on either Microsoft's products or some obscure ancient proprietary software from before I was born; and most new recruits only know "PC" and "Mac".

Yeah, that's the legacy product stack; lots of different things there, a few dead RTOSes, a couple of homegrown ones and even I think a Windows Embedded product.

This latest iteration we kinda got a little nudge since our supplier either wanted $$$$$ to make the new SoC platform drivers work with the old driver system, or use Linux RT. Lesser of two evils here, and now management are super happy they went this route.

[timofonic]

In these cases a soft-realtime Linux kernel like Ubuntu's "lowlatency" flavor is more than adequate; plus it doesn't introduce security problems as described here:

Hello, our dear Ubuntu troll...


How many times will you paste that Ubuntu propaganda when someone talks about RT? Please stop your boring astroturfing, you're becoming boring and annoying.

Please use your own words, if you can. I think you're unable to understand the topics, so you just paste text and repeat terms like a parrot

You're not helping. Please stop NOW.

[tildearrow]

Did you try pipewire with preempt-rt?

No, because PipeWire still is kind of incomplete.
It's the Wayland of audio. Better, modern and secure; but several things are missing compared to its predecessor.

[Nocifer]

...we want to cut our costs by using Linux, since this OS is massively popular, often known by new recruits...

Wow, are we still talking about Linux here? In my country's enterprise/industrial sector we're still largely dependent on either Microsoft's products or some obscure ancient proprietary software from before I was born; and most new recruits only know "PC" and "Mac".

[oiaohm]

Did you try pipewire with preempt-rt?

This is a interesting one. A Linux kernel with the preempt-rt patch set applied but still built like a normal kernel still today has lower jitter than the mainline 5.14 kernel . It will be interesting to see if the merge of the preempt-rt locking in 5.15 changes this.

https://gitlab.freedesktop.org/pipew...ormance-tuning
Yes pipewire is designed to take advantage of hard realtime. It also is designed to use rtkit for setting up hard realtime that is a watchdog against the worst things a hard realtime process can do. As in you attempt to have a hard realtime application so something system destroying the rtkit watchdog will kill the application.

The ubuntu case against hard realtime also does not allow for items like rtkit that make hard realtime fairly safe.