John is correct. My logging could be more clear. The "time between" is the since the last rising edge of the input pulse as detected by the update function of the encoder running in the base thread. The "counts between" is the number of base thread runs since the last rising edge input pulse. The time goes with the count of runs directly below it. For the sample Jon referenced, I believe the the two data points are:
40 runs in 796760 ns = 19919 ns/run 60 runs in 1195140 ns = 19919 ns/run The 1035788 ns time is actually from 52 runs, also = 19919 ns/run Granted, this is the time passed into the update function as the period, not an actual system time, but I think that shows there is very little (if any) thread timing jitter. There is absolutely variance there, but the data I have would seem to point toward an unstable input signal (or somehow a significant amount of random variance being introduced somewhere between, which would be very odd), but it would also be odd for my input signal to vary based on the way I am generating the signal. I can confirm all that once I get back in a week or so. Thanks much! Scott ------------------------------------------------------------------------------ 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
