John Kasunich wrote: > Disabling interrupts for X microseconds directly adds X microseconds to > the latency/jitter times for the machine. A PC with 25uS of latency is > not a very good realtime machine. One that occasionally spikes to 75uS > of latency is not good at all. > If the GPIO thread was an integral multiple of the servo thread, and was set to always run after the servo thread it shouldn't add jitter to the servo thread unless the GPIO thread runs overtime. (Maybe you can't do this, the faster thread needs to always dispatch first?) > What makes this situation subtly worse is that the user will have no > clue about this latency. When he runs the RTAI latency test, the driver > won't be loaded, so the latency that it causes won't be detected. The > user might run the latency test, get a 15uS for a result, determine his > max speeds accordingly, then start EMC. But every once in a while he > will get latencies twice as large as he did in the test. If he is doing > software stepping or software encoder counting, he'll either be losing > steps or skipping counts, and have no idea why. > Btm this is for a 7i43 system (I think) and so you would normally use the Mesa card's facilities to do this, and not have software step generation on the same system. > I have no doubt that this approach can be made to work reliably, IF > everything is carefully documented, and every user understands the > implications. I also have no doubt that even if somebody overlooks > something it will work 99.999% of the time. However, there is no way I > want to try to debug that remaining 0.001%. There is nothing worse than > the bugs that happen only when event A happens in a narrow window > between events B and C, and this seems like on of those situations. >
> > I'd rather be obsessively consistent - never disable interrupts and > never block in a realtime thread. The problem is OTHER drivers DO disable interrupts, and they aren't even real time threads! I doubt there are any drivers that shut off the interrupts for more than a us or two, certainly not 25 or so, or we'd know about them. One possible thought is to break up these big bursts of EPP traffic into smaller blocks, and enable the interrupts between them. So, instead of doing 16 data cycles in one block, do 4 at a time. This increases total traffic, of course, but allows higher priority threads to run with lower jitter. 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-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
