Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The real realtime preemption end game

lwn.net

Post reply on HN
Print view View original

271–280 of 281 posts

Re: The real realtime preemption end game

#271

Post by shandor »

0xDEF wrote: post #63

What do embedded real-time Linux people use for bootloader, init system, utilities, and C standard library implementation? Even Android that does not have real-time constraints ended up using Toybox for utilities and rolling their own C standard library (Bionic).

I guess U-boot, uclibc, and busybox is quite common starting point.

Of course, this varies immensely between different use cases, as ”embedded Linux” spans such a huge swath of different kinds of systems from very cheap and simple to complex and powerful.

Re: The real realtime preemption end game

#272

Post by fnordpiglet »

cduzz wrote: post #250
lmm wrote: post #222

Earlier quoted context omitted.

CAP is irrelevant, consistency does not matter for logs.

Consistency is a synonym for "guaranteed", and means "written to 2 remote, reliable, append-only storage endpoints" (for any reasonable definition of reliability) So -- a single system collecting a log event -- it is not reliable (guaranteed) if written just to some device on that system. Instances can be de-provisioned (and logs lost), filesystems or databases can be scrambled, badguys can encrypt your data, etc. In…

I’m not sure I understand the way you’re using the vocabulary. Consistency is a read operation concept not write. There is no online reads for logs.

Availability is achieved if at least one writer acknowledges a write. In a partition, it means when you have multiple parts of the system disagreeing about the write contents due to a partition in the network. But because logs are immutable and write only, this doesn’t happen in any situation. The only situation this might occur is if you’re maintaining a distributed ratchet with in delivery order semantics rather than eventually consistent temporal semantics- in which case you will never have CAP. But that’s an insanely rare edge case.

Note CAP doesn’t ensure perfect durability. I feel like you’re confusing consistency with durability. Consistency means after I’ve durably written something all nodes agree on read it’s been written. Since logs don’t support read on the online data plane this is trivially not an issue. Any write acknowledgment is sufficient.

Re: The real realtime preemption end game

#273

Post by rsaxvc »

dataflow wrote: post #221
rsaxvc wrote: post #219

Earlier quoted context omitted.

I don't know for x86. But for things that really matter, I've tested by configuring the MMU to disable caching for the memory that the realtime code lives in and uses to emulate 0% hitrate. And there's usually still a fair amount of variance on top of that depending on if the memory controller has a small cache, and where the memory controller is in its refresh cycle.

Yeah. And I'm not sure that even that would give you the worst case as far as the cache is concerned. Of course I don't know how these implementations work, but it seems plausible that code that directly uses memory could run faster than code that encounters a cache miss beforehand (or contention, if you're using multiple cores). Moreover there's also the instruction cache, and I'm not sure if you can disable caching…

You're right! I can think of two cases I've run into where bypassing the cache can be faster compared to a miss.

On some caches the line must be filled before allowing a write(ignoring any write buffer at the interface above the cache) - those basically halve the memory bandwidth when writing to a lot of cache lines. Some systems now have instructions for filling a cache line directly to avoid this. And some CPUs have bit-per-byte validity tracking to avoid this too.

Even on caches with hit-during-fill, a direct read from an address near the last-to-be-filled end of a cacheline can sometimes be a little faster than a cache miss, since the miss will fill the rest of the line first.

Re: The real realtime preemption end game

#274

Post by rsaxvc »

dataflow wrote: post #221
rsaxvc wrote: post #219

Earlier quoted context omitted.

I don't know for x86. But for things that really matter, I've tested by configuring the MMU to disable caching for the memory that the realtime code lives in and uses to emulate 0% hitrate. And there's usually still a fair amount of variance on top of that depending on if the memory controller has a small cache, and where the memory controller is in its refresh cycle.

Yeah. And I'm not sure that even that would give you the worst case as far as the cache is concerned. Of course I don't know how these implementations work, but it seems plausible that code that directly uses memory could run faster than code that encounters a cache miss beforehand (or contention, if you're using multiple cores). Moreover there's also the instruction cache, and I'm not sure if you can disable caching…

> Moreover there's also the instruction cache, and I'm not sure if you can disable caching for that in a meaningful way?

Intels used to boot with their caches disabled, but I haven't worked with them in forever, and never multicore.

I worked with a lot of microcontrollers, and it's not uncommon to be able to disable the instruction cache there.

There are a few things that require the data caches too, like atomic accesses on ARM. Usually we were doing something fairly short though in our realtime code, so it was easy enough to map just the memory it needed as uncacheable.

Re: The real realtime preemption end game

#275

Post by mlsu »

vlovich123 wrote: post #153
mlsu wrote: post #53

Earlier quoted context omitted.

That is true, but generally not acceptable to a regulating body for these critical applications. You would need to design and implement a validation test to prove timing in your system. Much easier to just use an RTOS and save the expensive testing.

But you still need to implement the validation test to prove that the RTOS has these requirements…

You do not, if you use an RTOS that is already certified by the vendor. This saves not only a lot of time and effort for verification and validation, but also a lot of risk, since validation is unpredictable and extremely expensive.

Therefore it'd be remarkable not to see a certified RTOS in such industries and applications where that validation is required, like aerospace or medical.

Re: The real realtime preemption end game

#276

Post by lmm »

cduzz wrote: post #250
lmm wrote: post #222

Earlier quoted context omitted.

CAP is irrelevant, consistency does not matter for logs.

Consistency is a synonym for "guaranteed", and means "written to 2 remote, reliable, append-only storage endpoints" (for any reasonable definition of reliability) So -- a single system collecting a log event -- it is not reliable (guaranteed) if written just to some device on that system. Instances can be de-provisioned (and logs lost), filesystems or databases can be scrambled, badguys can encrypt your data, etc. In…

> Consistency is a synonym for "guaranteed", and means "written to 2 remote, reliable, append-only storage endpoints" (for any reasonable definition of reliability)

No it doesn't. Read your own wiki link.

> In this context, a "network partition" prevents consistency (data not written to reliable media) or prevents availability (won't accept new requests until their activity can be logged reliably).

A network partition doesn't matter for a log system because there is no way to have consistency issues with logs. Even a single partitioned-off instance can accept writes without causing any problem.

Of course if you cannot connect to any instance of your log service then you cannot write logs. But that's got nothing to do with the CAP theorem.

Re: The real realtime preemption end game

#277

Post by rsaxvc »

HankB99 wrote: post #225
rsaxvc wrote: post #215

Earlier quoted context omitted.

>That's particularly interesting because at one time years ago, I saw suggestions that Linux could run as a task on an RTOS. I've worked with systems that ran Linux as a task of uITRON as well as threadX, both on somewhat obscure ARM hardware. Linux managed the MMU but had a large carveout for the RTOS code. They had some strange interrupt management so that Linux could 'disable interrupts' but while Linux IRQs were…

Interesting to know that it was more than just an idea - thanks!

You could probably do something simpler now since the new ARMs have good hardware virtualization support.

Re: The real realtime preemption end game

#278

Post by gigatexal »

spookie wrote: post #189
blackth0rn wrote: post #183

Earlier quoted context omitted.

ECS systems for the gaming world are somewhat like this. There is the core ECS framework and then the systems and entity's integrate with each other

ECS is incredible. Other areas should take notice

ECS?

Re: The real realtime preemption end game

#279

Post by vacuity »

gigatexal wrote: post #278
spookie wrote: post #189

Earlier quoted context omitted.

ECS is incredible. Other areas should take notice

ECS?

Entity-component-system paradigm. Compared to OOP, ECS is more "data-first". It's like a database of components (attributes such as Position, Velocity, Player) with entities (simple integer identifiers) as keys. Systems are functions that query for components and perform actions on them. See Shipyard, enTT, Bevy, flecs, etc. The design space is still evolving.

Re: The real realtime preemption end game

#280

Post by gigatexal »

vacuity wrote: post #279
gigatexal wrote: post #278

Earlier quoted context omitted.

ECS?

Entity-component-system paradigm. Compared to OOP, ECS is more "data-first". It's like a database of components (attributes such as Position, Velocity, Player) with entities (simple integer identifiers) as keys. Systems are functions that query for components and perform actions on them. See Shipyard, enTT, Bevy, flecs, etc. The design space is still evolving.

As a database guy I really can get around this. OOP hurts my head sometimes when the hierarchies get too deep.
Post reply on HN