In talking to Andy Pugh on IRC, we looked into the implementations of these functions, as well as past advice on their use.
(except as noted, all these notes are about the x86 implementations in recent (1-2 years old or less) rtai and linux, and about current emc2 master) rtapi_get_time ~~~~~~~~~~~~~~ A very long time ago, possibly before emc2.0.0, we discvered that on certain systems, calling rtapi_get_time took a very long time; this experience was so painful that a warning exists to this day against using the function. rtapi_get_time is presently implemented in terms of rtai's rt_get_cpu_time_ns, which is implemented in terms of rdtsc and llimd. it looks like it should work just fine and efficiently. Thus, I believe that we should test whether it's OK to remove the caveat against rtapi_get_time from the documentation. At the moment, rtapi_get_time is used in classicladder, motion, 7i43, and sserial. Therefore, there's some evidence that the current implementation is not actually broken beyond use, and maybe it's just fine. It looks like very long ago, rtapi_get_time actually called kernel sys_gettimeofday, which would break realtime, and consequently cause real trouble. (this code dates from an age when support for non-TSC processors was desirable, meaning 486 or a few pentium-era third-tier cpus like 6x86; rtai's rtapi_get_time implementation may have been badly busted or very low-resolution on those systems) rtapi_delay ~~~~~~~~~~~ rtapi_delay, on the other hand, looks to be potentially broken at the present time. It calls kernel udelay, which turns into a call to one of delay_loop or delay_tsc. In either case, the code refers to raw_smp_processor_id(), which is probably (but not 100% sure) a no-no for keeping realtime. If tsc is considered an appropriate timesource, though, it gets worse: delay_tsc does some things with preempt, which are almost certain to break realtime. The only current use of rtapi_delay in emc2 is hm2_7i43_reset in setup code, where these caveats about breaking realtime do not apply. However, rtai provides a function rt_busy_sleep(int nanosecs) as a busy-loop on rdtsc, which is precisely what rtapi_delay needs for its implementation. I believe that we should investigate whether changing rtai_rtapi to call rt_busy_sleep instead of udelay leaves the 7i43 driver working (it should!) and if so, change its for good. Otherwise, we should change the documentation to call rt_busy_sleep unsafe except for setup/cleanup code. Jeff ------------------------------------------------------------------------------ AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
