On Fri, 10 Aug 2012 08:12:19 +0100, Dave Caroline wrote:
> I had a look at the source of the comp that latency-test uses
>
> and I feel it is buggy
>
> It measures the difference in time delay one tick to the next
> not actual jitter from the system time
>
> __s64 now = rtapi_get_time();
> 18 __s64 del = (now - last); //only check period of last tick
> 19 out = del;
> 20
> 21
> 22 if(last != 0) { //not first time through
> 23 err = err + del - period;
> 24 if(first) {
> 25 first = 0;
> 26 min_ = max_ = del;
> 27 jitter = 0;
> 28 } else {
> 29 if(del < min_) min_ = del;
> 30 if(del > max_) max_ = del;
> 31 jitter = max(max_ - period, period - min_); //
> not checking this ticks time diff from where it should be
> 32 }
> 33 count++;
> 34 avg_err = err / (double)count;
> 35 }
>
> I suggest keeping track of the correct ticktime with a
> correct_time=period_counter*tick_period
> and then something like
> del=now-correct_time
>
> actually do this and keep the current code so one can see short and
> long term jitter
You might need to be careful here... I forget the gotya, but racking
based on system time might call system routines that trigger context
switches, etc. I remember building some time stamp code in a test
harness on one of the supercomputers and got weird results -- only to
find that I my time stamper was triggering a context switch and yielding
the process one time out of whatever. I forget the details now...
------------------------------------------------------------------------------
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-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
