5 ms·

I'm also interested -- What's the hardware difference required to support real time? Is it some dedicated parts of compute to support the queueing / prioriti

I'm also interested -- What's the hardware difference required to support real time? Is it some dedicated parts of compute to support the queueing / prioritization of jobs? And some additional ability to have the "master" must-always-work part be able to interrupt or reset "optional" processes?

akiselev 6y ago
Deterministic latency. That usually means no cache, speculative execution, or anything else that can't guarantee it will complete in a reasonable time. Specifically, in many architectures interrupt handling code must be able to yield _very_ quickly in order to continue receiving interrupts (or use reentrant interrupts which are a whole other mess) and even a cache look up, which might fail and have to wait for DDR ram for hundreds or thousands of cycles, makes the system unable to guarantee that it will do what it needs to do in time, like respond to some safety shutoff switch. I think one of the things ARM did here is make a way for interrupt handling code to stay in cache permanently along with some other determinism guarantees.
- brundolf 6y ago
  It sounds analogous to the question of deterministic memory usage (vs GC), but at a hardware level and for runtime instead of memory
- supernova87a 6y ago
  Thanks! I guess in the designing of the accompanying software then, the people writing it probably spend equal (or more) time in writing what happens if the expected/desired behavior fails, than if it succeeds?
dragontamer 6y ago
Realtime is both software and hardware. A realtime OS won't do much preemption, probably would rather stick to cooperative scheduling. On the hardware side, explicit cache controls are big in realtime chips. Your programmers know exactly which data is in cache and what isn't, and therefore can accurately plan how long tasks take. The MMU traditionally wasn't realtime. I wonder how they managed to get realtime controls with virtual memory. (They must have some kind of guarantee on TLB lookups or something)
- AnimalMuppet 6y ago
  > realtime OS won't do much preemption, probably would rather stick to cooperative scheduling. I've seen realtime OSes that were very preemptive, at least between priorities. Tasks/processes had priorities, and a higher-priority task that became active would preempt anything lower-priority that was running. vxWorks ran this way, IIRC, and it wasn't alone.

akiselev 6y ago

Deterministic latency. That usually means no cache, speculative execution, or anything else that can't guarantee it will complete in a reasonable time. Specifically, in many architectures interrupt handling code must be able to yield _very_ quickly in order to continue receiving interrupts (or use reentrant interrupts which are a whole other mess) and even a cache look up, which might fail and have to wait for DDR ram for hundreds or thousands of cycles, makes the system unable to guarantee that it will do what it needs to do in time, like respond to some safety shutoff switch. I think one of the things ARM did here is make a way for interrupt handling code to stay in cache permanently along with some other determinism guarantees.

brundolf 6y ago
It sounds analogous to the question of deterministic memory usage (vs GC), but at a hardware level and for runtime instead of memory
supernova87a 6y ago
Thanks! I guess in the designing of the accompanying software then, the people writing it probably spend equal (or more) time in writing what happens if the expected/desired behavior fails, than if it succeeds?

dragontamer 6y ago

Realtime is both software and hardware. A realtime OS won't do much preemption, probably would rather stick to cooperative scheduling. On the hardware side, explicit cache controls are big in realtime chips. Your programmers know exactly which data is in cache and what isn't, and therefore can accurately plan how long tasks take. The MMU traditionally wasn't realtime. I wonder how they managed to get realtime controls with virtual memory. (They must have some kind of guarantee on TLB lookups or something)

AnimalMuppet 6y ago
> realtime OS won't do much preemption, probably would rather stick to cooperative scheduling. I've seen realtime OSes that were very preemptive, at least between priorities. Tasks/processes had priorities, and a higher-priority task that became active would preempt anything lower-priority that was running. vxWorks ran this way, IIRC, and it wasn't alone.