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. >
Then don't complain. :) > >> - 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? Those two increase the latency of code in timed tasks, for sure. The question is if your measurement on the slower machine also included this scenario (timer event + 2 IRQs in a row). This definitely doesn't happen often, and maybe timing on the slower box makes it less likely. Or there is one potential IRQ source more on your fast box (e.g. due to IRQ sharing on the slower one). You see, RT system design on the edge (ie. when hunting a few 10 us) is tricky and not easily portable from box X to box Y. Jan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
