On Fri, 30 Mar 2012 13:13:27 -0400, Kent A. Reed wrote: > ... > > 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.
I do not think that it "prevents" its use, but limits the speed and/or accuracy at which various hardware/software combinations can be set up. If you are running step generators with a maximum of few thousand steps per minute then 4us or 40us probably is not going to make that big of difference. When you start the signal to noise (or jitter) will kill you. Maybe I am thinking about this wrong, or maybe I just have not caught up with enough sleep, but for slow work the complexity is not necessary. > 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 thought it was now much better than 10x, but RTAI might have polished things up enough to maintain a 10x lead. I would be interested in the current numbers. > 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:-) Well, why not start one on a wiki and let people start hacking it... > 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. You probably do not know it, but at one time that comment would have started a religious holy war... IIRC, the patent on RT-Linux might have expired by now, but RT-Linux and RTAI abstractly use directly comparible approaches. One advantage with RT-Linux is, if you go with the professional version, it has professional support. On the other hand, I am not sure how much of the fully open source patched has been kept up with public release. WHen I worked with RT-Linux Pro years ago, it was significantly faster that RTAI and worked out of the box. I am not sure what the current numbers are... > 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? I completely agree. I think there are some numbers around but have not kept up with it... ------------------------------------------------------------------------------ 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
