3 ms·

If that is true you should call in to question the integrity of a company that would run life-critical software on a non-RTOS.

by mike_d 7y ago

TaylorAlexander 7y ago
Nobody said anything about whether or not there is an RTOS involved.
eru 7y ago
Realtime has nothing to do with absolute performance. It's about meeting your deadlines. And, of course, often real-time systems have much worse throughput performance than a non-real-time system on the same hardware. After all, latency guarantees are not free.
- Dylan16807 7y ago
  Yeah, until we're above 500Hz I'd rather have a significantly faster non-realtime main system, with a small realtime watchdog/backup.
  - eru 7y ago
    Even a guaranteed 10Hz, ie 100ms reaction time, is better than what humans routinely do. And yes, in practice you will probably combine a small real-time core with most of the code (by volume) running non-real time. Lots of one-time setup at the beginning of the right, or longer-range route replanning doesn't need to finish within tight deadlines. The human analogue is your co-pilot reading the map; or when you are fiddling with the aircon or radio dial.
- mike_d 7y ago
  Yup. I think we agree on that. It doesn't matter if you have a highly performant pipeline for detecting other cars if you have a random 200 ms VM pause as another car blows a stop sign in front of you.
  - Dylan16807 7y ago
    ...but if it starts braking hard in 250ms that's still a very superhuman reaction time.
    - RugnirViking 7y ago
      As humans we know our reaction times - you naturally slow down as you get to a junction or navigate crowded or tricky traffic conditions to give yourself as much of a chance as possible to react. This is the thinking behind many types of speed control street layouts. You should also know where to look to anticipate where danger is most likely to come from, and be ready with some kind of action. This is why we do hazard identification tests as part of the driving test - looking in the right directions at the right times is crucial for operating a vehicle safely. 250ms is a fairly average reaction time for something visual that you are ready for - but you should really be giving yourself as much time as possible - if somebody bombs past a traffic light at 70mph, even if it is green, most people would agree that it was an unsafe move. This goes doubly for an autonomous car, that is unable to play the positioning negotiation game that humans are masters of as a result of being social creatures.
      - Dylan16807 7y ago
        It's very easy to configure a program to slow down before intersections. Also if we want to be realistic here, you're going to be able to see that the other car isn't slowing properly for much longer than 200ms. You'd either already be braking when you hit that pause, or you'd be so early on that the delay doesn't make a real difference. And if you're not hovering your foot over the brake pedal, you're not getting 250ms.
  - eru 7y ago
    I get your point. But to nitpick: I think you could make 200ms pauses work, even if they are random. Just adjust your deadlines, and drive like a defensive human driver. Humans have worse reaction times. The bigger problem is that what you might actually be getting is (almost) arbitrarily long pauses with a long tailed distribution. So sometimes 200ms, rarely a second, and every once in a while perhaps two seconds, etc; and no guarantees on the longest pause.

If that is true you should call in to question the integrity of a company that would run life-critical software on a non-RTOS.

by mike_d 7y ago

If that is true you should call in to question the integrity of a company that would run life-critical software on a non-RTOS.

TaylorAlexander 7y ago

Nobody said anything about whether or not there is an RTOS involved.

eru 7y ago

Realtime has nothing to do with absolute performance. It's about meeting your deadlines. And, of course, often real-time systems have much worse throughput performance than a non-real-time system on the same hardware. After all, latency guarantees are not free.

Dylan16807 7y ago
Yeah, until we're above 500Hz I'd rather have a significantly faster non-realtime main system, with a small realtime watchdog/backup.
- eru 7y ago
  Even a guaranteed 10Hz, ie 100ms reaction time, is better than what humans routinely do. And yes, in practice you will probably combine a small real-time core with most of the code (by volume) running non-real time. Lots of one-time setup at the beginning of the right, or longer-range route replanning doesn't need to finish within tight deadlines. The human analogue is your co-pilot reading the map; or when you are fiddling with the aircon or radio dial.
mike_d 7y ago
Yup. I think we agree on that. It doesn't matter if you have a highly performant pipeline for detecting other cars if you have a random 200 ms VM pause as another car blows a stop sign in front of you.
- Dylan16807 7y ago
  ...but if it starts braking hard in 250ms that's still a very superhuman reaction time.
  - RugnirViking 7y ago
    As humans we know our reaction times - you naturally slow down as you get to a junction or navigate crowded or tricky traffic conditions to give yourself as much of a chance as possible to react. This is the thinking behind many types of speed control street layouts. You should also know where to look to anticipate where danger is most likely to come from, and be ready with some kind of action. This is why we do hazard identification tests as part of the driving test - looking in the right directions at the right times is crucial for operating a vehicle safely. 250ms is a fairly average reaction time for something visual that you are ready for - but you should really be giving yourself as much time as possible - if somebody bombs past a traffic light at 70mph, even if it is green, most people would agree that it was an unsafe move. This goes doubly for an autonomous car, that is unable to play the positioning negotiation game that humans are masters of as a result of being social creatures.
    - Dylan16807 7y ago
      It's very easy to configure a program to slow down before intersections. Also if we want to be realistic here, you're going to be able to see that the other car isn't slowing properly for much longer than 200ms. You'd either already be braking when you hit that pause, or you'd be so early on that the delay doesn't make a real difference. And if you're not hovering your foot over the brake pedal, you're not getting 250ms.
- eru 7y ago
  I get your point. But to nitpick: I think you could make 200ms pauses work, even if they are random. Just adjust your deadlines, and drive like a defensive human driver. Humans have worse reaction times. The bigger problem is that what you might actually be getting is (almost) arbitrarily long pauses with a long tailed distribution. So sometimes 200ms, rarely a second, and every once in a while perhaps two seconds, etc; and no guarantees on the longest pause.