> Could you try measuring the jitter in cpu cycles with rdtscll, in > kernel-space? If the inaccuracy persists, check that cpufreq is not > enabled, and that if running on a multicore system, tscs are > synchronized. Apart from that no, no idea. > > -- > Gilles.
Hi Gilles, I measured the interval between input pulses using rdtsc to grab the cpu cycles. The number of clock cycles between my 1 second input pulses was quite consistent varying by less than 10,000 cycles. On my 1600 MHz system that works out to less than 6 us. This value was consistent between reboots. This indicates to me that the tsc clock is very stable between reboots. Looking at /proc/cpuinfo showed that the "cpu MHz" value changes by a small amount during each reboot. It varies from 1600.131 MHz to 1599.628 MHz. The difference between 1600 and 1599.628 MHz accounts exactly for the unexpected latency I described in earlier emails. So it would seem that the frequency used for clock time stamps is reported incorrectly when using my Xenomai build. If I boot the system with regular Ubuntu, /proc/cpuinfo consistently reports the frequency as 1600 MHz. I do not have CPU scaling set. I am running an Atom dual CPU processor and /proc/cpuinfo shows both processors as having the same frequency. How can I ensure syncronization of the tscs? The Xenomai build seems to produce an incorrect cpufreq, any ideas as to why? Thanks for all your help. Philip Ha
_______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
