Wolfgang Grandegger wrote: > roland Tollenaar wrote: >> Hi >> >>> Two conclusions: >>> >>> - You are running your kernel as i586 without TSC support - suboptimal, >>> costs you a few micros. >> I am aware of this. For the current machine I will stick to this. >> >> >>> - The reported latency perfectly matches the trace, nothing >>> pathological there. The trace looks like this: Timer fired, >>> measurement task woken up, two interrupts squeeze themselves between >>> wakeup and time stamp acquisition. All sane. >> Is it not a bit strange that a machine as fast as this one is supposed >> to be give worse latencies than much slower machines. Are the 2 >> interrupts causing the latency? > > Yes, what puzzels me is actually the high min latency of more than 24us: > > == Sampling period: 100 us > == Test mode: periodic user-mode task > == All results in microseconds > warming up... > RTT| 00:00:01 (periodic user-mode task, 100 us period, priority 99) > RTH|--lat min|---lat avg|-----lat max|-overrun|----lat best|---lat worst > RTD| 24.304| 35.199| 65.371| 0| 24.304| 65.371 > > Can the TSC cause such high delays? >
You mean TSC emulation? Definitely yes for the worst-case. Almost every rthal_get_8254_tsc() costs about 3 us, and I counted >15 in Roland's critical trace path. > And what is the output of "/proc/xenomai/latency"? Indeed interesting. Maybe the system is not well tuned. But the overhead of rthal_get_8254_tsc() will remain for the non-minimal case (e.g. host-tick hitting before or after task-wakeup tick). Jan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
