On Mon, Aug 12, 2013, at 11:12 AM, Kirk Wallace wrote: > On 08/12/2013 05:51 AM, GP Orcullo wrote: > > > >> * Can anyone else running a BeagleBone system try using the mini > >> GUI and enabling the backplot while a program is running? I'd like > >> to know I'm not the only one seeing this issue. > > > > I have noticed this issue on RPi as well, the motors would slowdown > > or pause whenever the graphics load is too high. Axis is prone to > > this problem and is not easily reproduced. For mini, performing a > > refresh on a complex backplot or manipulating the zoom slider will > > trigger this problem. > > > > Note that I'm using the rtos-integration-preview3 version and there > > are no realtime errors whenever this happens. > > > > Cheers > > ... snip > > I haven't followed this thread very closely, but ... am I missing > something? I thought the whole idea behind a real-time system is to > provide and reserve enough resources for the real-time tasks to complete > them on-time. All other tasks get what's left over. This has been my > experience in the past. When resources get sparse, the display gets > jumpy, but motion is not affected. If motion does get affected, you > don't have a real-time system. If motion gets affected and there are no > real-time errors, that seems worse. > > I mention this because, from my perspective, there seems to be a > disconnect between the stated problem and the areas being looked at to > find the problem. The problem may be with my perspective? > > > -- > Kirk Wallace
I think Kirk's prespective is right on target. A real-time system that misses timing targets is not a very good real time system. A real-time system that misses timing targets and doesn't even know it isn't a real-time system at all. I wonder how all these new RTOSes and new platforms measure the passage of real time? Back in the simple days, the RTAPI "get real time" call used the RDTSC instruction to read the time stamp counter, which was a 64 bit counter, constantly incrementing at the CPU clock rate. (Even a multi-gHz clock wouldn't overflow the counter for a few decades.) As multi-CPU, multi-core, and other SMP stuff came into the picture it got more complicated - each CPU might have a different counter, and as tasks get swapped from one to another they might get non-monotonic readings. And then you have power-conservation - clocks get slowed or even stopped to save power when the OS thinks there is nothing to do. I'm not sure how well the RTAPI get-real-time call has kept up with all this complexity. If the clock is being stopped, the realtime code could stop for a long time, and when it wakes up it would have no idea that any time had actually passed. That is an inherent risk of using an internal measure of time to evaluate "real-time" performance. I'm not sure I have anything constructive to offer, but I have to say this trend is very disturbing. -- John Kasunich [email protected] ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
