Hacker News Reader

Comment by neltnerb | Hacker News Reader

Maybe you can clear this up for me.

To me, realtime means "responds faster than the fastest it needs to in order to control a feedback loop" which is super subjective since different system dynamics are so different.

When I tried to use RTOS it appeared to be that better than 1ms resolution was not remotely possible. Just hardcoding the interrupts resulted in 1us resolution easily.

I grant that the RTOS provides a scheduler, but when this chip says that it is intended for "realtime" does it mean that it's microsecond fast even when running RTOS, that it's capable of running fast with handwritten interrupts and code (which to me seems to be most things), or just that it has a spec for an upper bound on op timing?

I guess the last is important for correctness proofs but the prior two are how I interpret it as a confused person reading marketing materials put out by conflicting sources.

View on HN

Actually realtime doesn't mean "responds faster than the fastest it needs to" but rather it means always responds faster than some predetermined threshold. A lot of the easier ways to make things fast (like caches, or even branch prediction) are inherently probabilistic; if the thing is in the cache you get wonderfully fast performance; if not performance falls off a cliff. A realtime system avoids that, making the average case much slower but the slowest case much faster. It basically flattens the latency distribution.

Does this mean realtime doesn't use caches and branch prediction a all? Or worst case of miss for cache or prediction miss is lower than realtime threshold?

A lot of hardware designed to support realtime applications will let you opt in or out of some of those features. So you have some ranges of memory that go through the usual cache hierarchy to off-chip DRAM, but you also have some memory that is directly mapped to on-chip SRAM that isn't a cache and therefore cannot suffer the latency penalty of a cache miss.

Stuff like branch prediction probably isn't too useful to implement as a switchable feature. Instead, the core is designed so that mispredict latency is still reasonably short (short pipeline, in-order execution or OoO with a short reorder window). This means you won't get as much benefit from speculative work as you would on a desktop-class core, but you're probably not going to be as vulnerable to Spectre-style attacks, either.

In one application I worked on, the caches were turned off completely. Slower, but more predictable latencies, and most importantly, without the huge latency spikes we would occasionally get with caches enabled. (Because of large cache misses.)

Its perfectly possible to have realtime requirements and still have variable latency as long as all the variability is bounded. Think video playback or gaming, both of which run on traditional OS's because they tend to be fast enough to meet the frame deadlines. Of course as we all know, the requirements aren't "hard" so dropping a frame/etc is a non critical failure.

So, there is a spectrum of realtime and how "hard" it needs to be. There are a lot of cases where simply having a real time OS on a traditional processor is fine as long as everything can be sufficiently bounded.

> When I tried to use RTOS it appeared to be that better than 1ms resolution was not remotely possible.

I've only worked with one RTOS, and a lightweight one at that.

The scheduler would run every time an interrupt handler finished running.

One such interrupt was the 'systick' - you can choose if you want it to run every 1ms, or 100us, or a different rate (depending on how fast your CPU is)

The systick was how you timed anything you didn't want to use a dedicated hardware timer for. If you want to wait 10ms and your systick happened every 1ms, you waited until the 10th systick.

If you want to time something with finer resolution than 1ms, you either made your systick faster, or used a hardware timer with the interrupt triggering the scheduler.

> Just hardcoding the interrupts resulted in 1us resolution easily.

If your CPU runs at 180MHz, 1us is enough time for 180 clock cycles. Plenty of time to run one reasonably carefully coded interrupt handler, not much time to run 10 interrupt handlers.

As you can imagine, running your systick at 1us with that clock rate would be challenging!

You can also have a 'tick less' scheduler for the systick style timer that won't have a regular period, but instead will dynamically reset the timer in each expiry ISR for the next scheduled event.

Realtime is a fluid (AFAIK) definition. In general, realtime concerns reaction time to inputs - how much (sic) of inputs are processed "in time". On one hand, you may want the system to react "quickly" to 99% of inputs on a pin. On the other hand, you may not care (within reason) when the system responds to UDP packet. To recap, realtimeness concerns amount of events on the same input processed "in time" and number of inputs subject to timeliness. Hence general confusion and multiple definitions.

I would say there are two (2) sets of realtime definitions.

1) concerning amount of events

Hard realtime system always produces output to an input in predefined time (subject to clocking). This time can vary between different inputs, but is fixed for a given input.

Soft realtime systems are bound - output time is bounded to some number.

2) concerning number of inputs

Hard realtime system has bound reaction time to every possible input

Soft realtime system has bound reaction time to "critical" inputs.

---

Definitions used in practice mix the two in some ways. The most prevalent definition I happen to come across in the general internet is something like "realtime system has bounded, low-variation reaction time to critical inputs".

I don't get the impression that in this case "realtime" means anything surprising – that is, it means "responds within a well-known and deterministic time." As you point out, that time is usually slower than a non-realtime system would offer.

Specifically with the R-family ARM chips, there is support for things like tightly-coupled memory (https://developer.arm.com/documentation/ddi0338/g/level-one-...) to provide latency guarantees for real-time code, deterministic interrupts, that kind of thing.

I see, thanks. I can see an advantage to being able to say that your average performance isn't as good but your variation is small, you can prove you'll hit your metric. I guess I usually over-engineer by 10x but maybe a better coder would do a better job of running up against the limits.

> average performance isn't as good but your variation is small, you can prove you'll hit your metric

I think you are missing something here.

Real Time systems aren't designed for high performance at all and instead they are designed for predictability.

You aren't aiming to "hit your metric", you are aiming to never, even go below it.

This is useful for something like old-style spinning hard drives where you had to calculate where to move the head of the disk within the time of the rotation. You have a instructions/second budget, and you know it will execute that.

On non-realtime hardware (and software) you know how many instructions/second it can do, but things like speculative execution of caching strategies or non-RTOS mean those instructions are not guaranteed at all.

I'm confused, aren't "don't fall below your spec" and "hit your metric" synonyms? In what field are they not?

"Hit your metric" commonly refers to average (or some percentage of average) performance being within bounds.

It's pretty rare in software for it to define minimum performance. There's good reasons for this - software is interacting with intrinsicly messy things (like humans) and so performance outliers are a big factor.

It's pretty common in software for the worse case to be 10x the "hit your metric" case, and this isn't viewed as bad: the worst case happens rarely enough for the trade off to be worth it.

Ah, thanks for the clarification.

I am coming from the hardware world, through raw assembly, to C so my path is very much the assumption that if the microcontroller is going to control a feedback loop that stabilizes at 10MHz it will be guaranteed to do so.

But I suppose that I actually do that by overspecifying things nowadays since it's much too unpredictable as you say to predict how long things will take.

To me if you say you sample at 100kHz you sample at a minimum of 100kHz. Very very good to know that if I work with a firmware engineer that they won't hear the same thing as I mean if I say that it needs to hit a 100kHz sampling rate.

It would be very disappointing if they wrote a loop designed to average a 100kHz sampling rate with random jitter... (kidding mostly, I'd assume they would at least not do that).

Firmware engineers would probably think in the same terms as you about sampling frequency.

As others said, the difference is very significant.

Real-time systems show up especially in industrial control and safety systems. For example, take a logging harvester, which cuts down trees and strips their branches and bark. It has a control panel for moving incredibly violent, dangerous machinery. It is truly critical that you can guarantee that, for example, sensors which detect a problem can abort something within a very tight latency budget.

"realtime" means "latency is bounded to some documented value". "Hard realtime" means it never exceeds that value, and has the same latency every time. "Soft realtime" means it never exceeds that value but the actual latency varies.

That value doesn't have to be anything in particular. Could be 1ms. Could be 100ms. Could be a year. It just has to exist and be documented, and never, ever be exceeded by whatever operations are covered by its guarantee.

Your description of hard vs soft realtime doesn't match any that I've previously encountered.

Generally, hard realtime means missing a deadline in unacceptable, but does not necessarily imply that latency is exactly fixed—just bounded. Soft realtime means that the consequences of missing a deadline are less severe, so the system may allow for some missed deadlines: eg. dropped packets for a video conference or delayed frames for a video game are noticeable especially if they become common, but they don't crash the whole system and the system remains useful even after missing a deadline.

>and has the same latency every time.

There's no such requirement.

All hard realtime needs is the guarantee that the value will never be exceeded.

Right. Should have written "same maximum every time". Went stupid for a minute.

Reply on news.ycombinator.com