Ebo - Am 06.05.2013 um 20:33 schrieb EBo <[email protected]>:
> Michael, > > I just tried to give you what was asked for. You can reexpress it > however seems most clear to you or your users. What I was getting at is > that the answer depends on your give setup, but if you give me a couple > of specs of your hardware then I can give you some guidance. I picked > the g540 because it is a give piece of equiptment that some people use. > You could just as well write up the same ting for the Mesa hardware, > etc. Expressing it in terms of % or raw numbers is fundamentally the > same -- for a given spec and use you need a jitter no worse than JERR. > You can generate such a table give the original specs. I wasnt critisizing your proposal - sorry if I was unclear: I notice there is some preponderance in this community with meandering over certain concepts which are not necessarily helpful while lots of opining & musing on said concepts might suggest they are meaningful, it might also suggest we just face a serious case of groupthink which fails to address the questions which are actually relevant in the case of latency, I am rather sure this is the case, which is why I suggested to think outside the box - Michael > > On May 6 2013 12:24 PM, Michael Haberler wrote: >> 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 > > > ------------------------------------------------------------------------------ > 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 ------------------------------------------------------------------------------ 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
