for rt-preempt there is ftrace and you can get a top-list of latencies , perhaps a top 100 list with stack traces would be a better indicator of the problem area ?
like the ones on osadl's site. does xenomai have a latency trigger ? something like ftrace would be nice. / Lars Segerlund 2012/12/5 Kent A. Reed <[email protected]>: > On 12/5/2012 2:38 PM, Gene Heskett wrote: >> On Wednesday 05 December 2012 14:33:01 EBo did opine: >> >>> On Dec 5 2012 9:03 AM, Kent A. Reed wrote: >>>> On 12/5/2012 4:16 AM, EBo wrote: >>>>> On Dec 4 2012 9:06 AM, Kent A. Reed wrote: >>>>>> <...> If one is satisfied that the internal, latency-test approach >>>>>> provides a reasonable metric, then it would be dead-simple to take >>>>>> latency-test/latencyplot a step further, bin the results, and >>>>>> derive >>>>>> interesting measures from it. Like latency-test, one could provide >>>>>> a >>>>>> running tally of key measures or like the OSADL does for its >>>>>> RT-Preempt, >>>>>> one could draw histograms and analyze exhaustively on demand. >>>>> I'm not a statistician, but have been involved with some wicked cool >>>>> statistical analysis projects in the distant past. I wonder if >>>>> <...> >>>>> >>>>> EBo -- >>>> I love exploratory data analysis. Over the years it proved invaluable >>>> first in my degree work (I owe my degree to it) and later in my >>>> professional research. Fancy analysis---and R would be a great >>>> tool---can come later, but always start with plots to get a feel for >>>> the >>>> problem at hand. >>>> >>>> I'm shooting for a histogram plot by this weekend. >> That data would be easier to collect if latencyloop could keep a log, hint >> hint. My b.max is now at 18 microseconds, s.max is about 15, but the >> averages are in the 5 range. 31xxx runtime now. >> > > I'm already on it, Gene. There's surprisingly little to be done. As a > side benefit (I hope), I decided the Wiki could do with a discussion of > How LatencyTest works. Its mixture of shell script, dynamically created > temp files, hal configuration, and pyvcp, not to mention hal itself, may > be opaque to some folk. Stay tuned for a page branched off from the > existing LatencyTest page. > > While I'm at it, let me say out loud what some of us have been > whispering. There's no reason for us to get so fixated on these jitter > numbers (and it's really the jitter we're interested in). They make > interesting reading---like Consumer Reports rating numbers---but once > they are good enough to run a particular machine it makes no sense to > wrap one's self around the axle over them. It seems sometimes we just > want to get into a typical playground argument...mine's better than > yours, nyah, nyah, nyah :-) > > The techniques we're discussing here are intended more for understanding > better what's going on in the bowels of the various cpu/bios/rt kernel > combinations and figuring out what, if anything, can be done about it. > My problem is I can never know enough (used to drive my bosses crazy) so > new diagnostic tools always get my attention. > > Of course, a 25us base thread will generate nearly 14GB of data in a > 24-hour period just capturing the current period-to-period difference in > nanoseconds as a 32-bit integer, and a 1ms servo thread another 350MB. > These aren't huge files by today's multimedia standards, but one has to > be aware. I'm talking latencytest defaults here. Everything is already > adjustable in the current latencytest script and one could reduce the > file sizes dramatically by reducing the precision. > > Regards, > Kent > > > ------------------------------------------------------------------------------ > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > Remotely access PCs and mobile devices and provide instant support > Improve your efficiency, and focus on delivering more value-add services > Discover what IT Professionals Know. Rescue delivers > http://p.sf.net/sfu/logmein_12329d2d > _______________________________________________ > Emc-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-developers ------------------------------------------------------------------------------ LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
