On Fri, 30 Mar 2012, Kent A. Reed wrote:
> Date: Fri, 30 Mar 2012 13:13:27 -0400
> From: Kent A. Reed <[email protected]>
> Reply-To: EMC developers <[email protected]>
> To: EMC developers <[email protected]>
> Subject: [Emc-developers] The preempt_RT vs RTAI question
>
> 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
>
I wonder for non software-step systems if a crude busywait from thread
invocation till hi-res timer count match could be used to sacrifice some CPU
for nS jitter times.
Another other possible remediation for jitter in the servo thread is basing
feedback calculations on actual time rather than assumed servo thread period
for velocity mode (analog, digital, step/dir hardware) drives this can make a
big improvement in apparent position noise.
Peter Wallace
Mesa Electronics
(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.
------------------------------------------------------------------------------
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
