4 ms·

I wonder how they arrive at the X microsecond worst-case number for the software-based solutions. Does it take into account a perfect storm of APIC interprocess

by zurn 9y ago

I wonder how they arrive at the X microsecond worst-case number for the software-based solutions. Does it take into account a perfect storm of APIC interprocessor events, interrupts, SMP cache coherency protocol worst-case behaviour and cross-CPU TLB shootdowns, misses on all levels of instruction/data TLBs and caches and DRAM, CPU trace cache behaviour, ECC machine check events, worst case OoO core behaviour wrt branch prediction and speculative execution, worst case interference from other SMT threads, other SoC functions accessing DRAM, etc? It would seem to me that a worst case scenario could easily cause slowdowns of many orders of magnitude. You could mitigate some of them by careful manual memory layout and hardware specific tricks like hardwired TLB entries, but still be left with a lot of uncovered stuff.

ridiculous_fish 9y ago
Interrupt-based designs are bad for real time, for the reasons you give. Instead you want to use techniques like polling and static scheduling, where every process gets a fixed time slice. This reduces the variability and improves fidelity to your model, since you know at every point what processes are running.
- occultist_throw 9y ago
  Easy to say that interrupts are bad.. But when you need to know of a pin change, rising or falling IRQ, interrupts are the only game here. And not only that, but if we were to do the timeslice strategy, then we need that slice to be at least 2x more than the fastest input for that pin. I would think with that strategy, you'd be servicing "slice-interrupts" more than anything else. I'll stick with writing ISR's that are only a few commands and do my work outside the ISR's, as standard in industry now. Now, on a related topic, if they're discussing getting the system to a 10us timing, that would be useful in using Linux as a 3d printer controller directly, rather than an Atmel or STM32 chip. But those requirements of what needs turned off seems pretty onerous, unfortunately.
- Too 9y ago
  Interrupt analysis is a core element for designing a real time system. High speed data interfaces don't always work good with polling. In theory it's actually quite easy, from the data sheets you can find out or configure the max frequency an interrupt can occur, then you just multiply that frequency with the WCET of your interrupt routine, assume it will always happen and deduct that time from your main loop time budget.
- zurn 9y ago
  IO interrupts and scheduling based surprises were a pretty small part of the list, though.
- jacquesm 9y ago
  The trick to this is to do the absolute minimum required in the interrupt routine and to push the rest of the work to a regular piece of software that gets scheduled at the right priority due to the interrupt having been processed. Doing actual work in an interrupt routine is a non-starter in a real time environment.

by zurn 9y ago

ridiculous_fish 9y ago

Interrupt-based designs are bad for real time, for the reasons you give. Instead you want to use techniques like polling and static scheduling, where every process gets a fixed time slice. This reduces the variability and improves fidelity to your model, since you know at every point what processes are running.

occultist_throw 9y ago
Easy to say that interrupts are bad.. But when you need to know of a pin change, rising or falling IRQ, interrupts are the only game here. And not only that, but if we were to do the timeslice strategy, then we need that slice to be at least 2x more than the fastest input for that pin. I would think with that strategy, you'd be servicing "slice-interrupts" more than anything else. I'll stick with writing ISR's that are only a few commands and do my work outside the ISR's, as standard in industry now. Now, on a related topic, if they're discussing getting the system to a 10us timing, that would be useful in using Linux as a 3d printer controller directly, rather than an Atmel or STM32 chip. But those requirements of what needs turned off seems pretty onerous, unfortunately.
Too 9y ago
Interrupt analysis is a core element for designing a real time system. High speed data interfaces don't always work good with polling. In theory it's actually quite easy, from the data sheets you can find out or configure the max frequency an interrupt can occur, then you just multiply that frequency with the WCET of your interrupt routine, assume it will always happen and deduct that time from your main loop time budget.
zurn 9y ago
IO interrupts and scheduling based surprises were a pretty small part of the list, though.
jacquesm 9y ago
The trick to this is to do the absolute minimum required in the interrupt routine and to push the rest of the work to a regular piece of software that gets scheduled at the right priority due to the interrupt having been processed. Doing actual work in an interrupt routine is a non-starter in a real time environment.