On May 6 2013 8:06 AM, Kent A. Reed wrote: > On 5/6/2013 9:16 AM, Lars Segerlund wrote: >> check the data on osadl.org ... with RT-Preempt you should be able >> to >> get worstcase jitters of less than 50 us ... or you have a 'bad' >> system / bad drivers. >> >> With a 'good' RT-Preempt system you get < 20 us as worstcase. >> >> osadl is good since they are really hammering the systems while >> measuring. >> >> / regards, Lars Segerlund. >> > > Lars: > > I'm not looking to open a discussion about the definition of jitter > and > the appropriate methodology for measuring it (we've had some of those > in > the past on this list, and some of us are quite familiar with OSADL). > > What I'm looking for is better guidance to our CNC users, most of > whom > find the details about latency as understandable as details about the > fuel-injection algorithm used in their car's computer. What we have > seen > in the time I've been reading the emc2- lists amounts to constant > schoolyard taunting, "my latency is better than your latency." Look > how > excited we get when the latest Atom board yields 1us lower or higher > jitter results than another. If the better guidance includes pointing > to > the OSADL as another source of data (along with suggestions on how to > interpret those data) so much the better for the folks who wish to > use > RT-PREEMPT enabled kernels (and my thanks to those on this list who > have > been making it possible for the average user to even consider using > them).
Kent, What I would like to see, and will help generate as my limited time allows, generate some basic formulas to help guide people. This is off the top of my head, and is likely wrong given that I am spacey as hell with allergies... max_pulse_rate (in Hz) = 1.0 /(maxjitter * Const) where Const is probably something from 3 to 10 and denotes some fraction of base time period that you can put up with the jitter. Knowing how fast you can run the stepgen thread (assuming stepgen) will then allow you to calculate your max speed using a given piece of mechanics/electronics/etc. For example, if you are using something like the Gecko G540, and motors that can do just over 300RPM, and typically have 200 steps/rev. We know that the G540 is hard-wired to 10 microsteps/step. So, we have 300*200*10 maximum steps/rev that the motors can do, and 10KHz for the step/sec. So if we back calculate that, we are talking 100us for the max step rate, and you want your jitter to be a very small portion of that (for argument lets say 1/5 or <20%). So, if we have a latency of <20us we can easily keep up with the G540. If I am not mistaken, the latest RT_PREEMPT is able to do that on all my hardware. Not sure about yours. Sometime back I remember reading a paper that looked at the %jitter to duty-cycle and the overall effect on power loss. I do not have an intuitive feel for that or what implies for the current discussion but this is a start. I am sure that others will tare this apart but so be it. This is intended to start a reasoned discussion on spec'ing the max speed of a setup given the jitter and other considerations. EBo -- ------------------------------------------------------------------------------ Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
