tomp wrote: > > yes, thanks John, > i never read an acceptable magnitude for latency in a servo system > > Well, assuming you are running the servo thread at 1 KHz (1 ms interval) and the servo code itself takes, say, 100 us on the average, then you have a 9:1 margin. So, a sudden interruption by something else that steals another 250 us would be no problem, the servo loop would still be completed with plenty of time to spare. Now, in some old rt-Linux systems, if the periodically scheduled RT thread was still running when the next inteval time came up, the system would just lock completely, and you;d have to push the hardware reset. I think now, that it requires many overruns of the interval to flood the stack with uncompleted stack frames before it hangs.
Now, one complication is if the problem is not due simply to a higher priority routine that takes X time to run, but is some external contention for some resource like memory. Depending on the exact code sequence running, how well the cache supports it, etc., the effect on stretching the run time of the servo code may not be predictable. Some tight loops running on limited amounts of data may run almost entirely in cache, and the CPU will not be impacted much. Widely spread code affecting many data structures may only be able to run a couple instructions before having a cache miss and having to wait microseconds for main memory to respond. Suddenly, the CPU is slowed by a factor of several thousand! The only way to really know what is going to happen there is to actually test it. Leaving the CPU with lots of margin is a good idea. Jon ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
