Gentle persons: The question of alternatives to the RTAI approach seems to resurface roughly once a year. A timely example is Jan's response to "Max Jitter" on the emc-users list. Jan cited the OASDL, whose work is based on preempt_RT.
I don't have a dog in this fight---I'm quite happy with the performance and useability of today's LinuxCNC---but I see several long-term institutional benefits to considering preempt_RT. 1) The level of development support for preempt_RT that comes with real industrial interest from, e.g., the OASDL members. (nB. This kind of support means more to me than claims that it's going "mainline.") By comparison, I worry about the very existence of the RTAI effort in the long term. It would be comforting to know RTAI has similar support. 2) the OASDL commitment to a wide range of architectures. I am convinced this increases the support for them in preempt_RT development. In contrast, the RTAI commitment to alternative architectures seems very shallow. NOTE TO JON: two of the OASDL systems-under-test are ARM-based and show very credible latency numbers considering they're running preempt_RT. I know the devil lies in the details, but I gather from the email and IRC archives that a principal argument against preempt_RT is its higher latency, which prevents its use in software-pulse generation systems. While comparison* of OASDL's long-term tests (billions of measures over a year) with our tests (thousands of measures over hours) using different tools is perilous, their posted results suggest a ten-fold increase in max latency using preempt_RT vs. RTAI, which certainly supports this argument, but their results also seems to indicate preempt_RT is comfortably good enough for servo and hardware-pulse generation stepper systems. Past IRC discussions appear to agree but also point out practical problems that could arise if we tried to support both RTAI and preempt_RT. I wish I were competent to compose a page for the Wiki on this subject, outlining pros, cons, things that would need to be done to the LinuxCNC codebase, and what would be different as a result. Unfortunately, I'm a dilettante at best; at worst, I'm a...well let's just say I've been called worse:-) Still, I think it would be a great service for someone who really understands the issues to create such a page. It would be something we can point to whenever the subject surfaces and also a place to gather more thoughts. It might even be a springboard to action. As an aside, is RTLinux a consideration any longer? The Wiki page entitled RealTime makes it sound like RTLinux is the primary and RTAI the secondary choice. Inquiring minds want to know... Regards, Kent *It would be nice to have more detailed statistic measures for both, perhaps even spectral analyses. I seem to remember that at some point in time someone (Jeff, maybe?) was gathering and plotting LinuxCNC latency data. If that isn't a fantasy, did it ever progress to analysis? ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
