Scott Hasse wrote: > Are you perhaps associating the wrong run count and run times log entries? > In the four-line log snippet you show I believe the middle two entries would > be associated with each other. I see the times between divided by runs > between to be quite stable. I have run the latency tests and get about 8000 > ns on this 525mw with hyper threading disabled and the other recommended > tweaks. > No, I'm comparing 40 vs 60, and 796760 vs. 1035788, both of these are pretty large variations. The last two numbers are 796 us and 1035 us, so that is a difference of 239 us!!!!! YOW! I'm not sure exactly what this "time between" measurement is, I was assuming it was the time difference between your executions of the encoder.n.capture-position HAL function. If that is so, then this particular hal config is NOT performing the way your latency test indicates it SHOULD be. This wild latency variation sure corresponds with the large fluctuation in velocity you are getting from the encoder component, so I tend to believe the numbers bear out that something is really killing your latency. Note that rtapi also collects run time info on all rt components, possibly one of your components is malfunctioning and burning large and variable amounts of time, causing all later components in the thread to suffer a lot of jitter. This data can be seen with halscope, for instance.
Jon ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
