EBo,
Am 06.05.2013 um 19:44 schrieb EBo <[email protected]>: > 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) from a user perspective I think measures like latency or perceived maximum pulse rates are useless as guidance, for the simple reason that they do not express what a user might be interested in, but happen to be some low-level number which happens to be measurable easily what _I_ would be interested in isnt what happens to be easily measurable, but what a given setup can do for me for example: given a configuration, what is the quality of tracking the commanded path, and the speed/speed deviation at which that can be done tracking quality (I just made that term up) might translate into either a maximum path deviation (hard limit), or a distribution with percentiles plus a boundary this probably has both a spatial and a temporal dimension example for spacial accuracy: for test path X, results are within A uM 95% of the time with a maximum deviation of B uM I admit this probably cant be expressed as easily - I'm lacking theory and literature know how here but I would bet there is actually work in the area (or in related weapons or rocket research ;) maybe even there is a way to compute such values on the fly and mirror them in (a) pin(s); again that is blue sky and pure speculation from that perspective, messages like 'unexpected realtime delay' are about as useful as dashboard message in my car saying 'cylinder #3 took 0.7mS too long to fire': very interesting detail, now what bearing has that on my goals - do I need to stop, can I continue driving or will I bump into another car? --- at times it might be useful to lean back and ask yourself: does this make sense or can we do better than that - Michael > > 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 ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
