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
