Announcement

Collapse
No announcement yet.

PREEMPT-RT Locking Infrastructure Possibly Ready For Linux 5.15

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    Originally posted by oiaohm View Post
    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...

    Comment


    • #22
      Originally posted by Linuxxx View Post
      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.

      Comment


      • #23
        Originally posted by Linuxxx View Post
        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).

        Comment


        • #24
          Originally posted by MadeUpName View Post
          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

          Comment


          • #25
            Originally posted by MadeUpName View Post
            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.

            Comment

            Working...
            X