| |||||||||||||
Scenes from the Real Time Linux WorkshopScenes from the Real Time Linux WorkshopPosted Oct 8, 2009 16:34 UTC (Thu) by Tara_Li (subscriber, #26706)Parent article: Scenes from the Real Time Linux Workshop
What effect does the indeterminancy of instruction timings have on the ability to debug a program? All of a sudden, it seems to me that some of the heisenbugs out there aren't actually software bugs, or bugs from improper inputs, but actually a result of the hardware not doing what it's supposed to!
At some level, this certainly seems like it makes a RT Kernel (or anything RT) absolutely impossible. If all of the bad things that *could* happen to slow down a code path, happen at the same time, you're just boned.
(Log in to post comments)
Absolutely not. Posted Oct 8, 2009 20:39 UTC (Thu) by khim (subscriber, #9252) [Link] At some level, this certainly seems like it makes a RT Kernel (or anything RT) absolutely impossible. If all of the bad things that *could* happen to slow down a code path, happen at the same time, you're just boned. Not really. All timings have upper limit. But for the contemporary system "highest possible" response time is far, far away from "typical time". By the factor 100 or so. If need hard realtime then you need to pay HUGE sums and can reduce it to 10 or so. Beyond that... you are stuck.
Absolutely not. Posted Oct 9, 2009 3:51 UTC (Fri) by magnus (subscriber, #34778) [Link] If need hard realtime then you need to pay HUGE sums and can reduce it to 10 or so. Beyond that... you are stuck.In some cases you can add a dedicated FPGA or microcontroller to handle the realtime stuff and leave the computer to do less timing-critical (but more complex) work. If the problem can be split this way it's usually the simplest solution (IMO).
|
|||||||||||||