4 ms·

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 you

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.

nl 6y ago
> 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.
- neltnerb 6y ago
  I'm confused, aren't "don't fall below your spec" and "hit your metric" synonyms? In what field are they not?
  - nl 6y ago
    "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.
    - neltnerb 6y ago
      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).
      - SonOfLilit 6y ago
        Firmware engineers would probably think in the same terms as you about sampling frequency.
spenczar5 6y ago
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.

nl 6y ago

> 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.

neltnerb 6y ago
I'm confused, aren't "don't fall below your spec" and "hit your metric" synonyms? In what field are they not?
- nl 6y ago
  "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.
  - neltnerb 6y ago
    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).
    - SonOfLilit 6y ago
      Firmware engineers would probably think in the same terms as you about sampling frequency.

spenczar5 6y ago

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.