Jan Kiszka wrote: > ... > Xenomai is loaded at this time but not yet used. Linux runs in tickless > highres mode and obviously had programmed the host timer to fire here. > But instead of one timer IRQ (233) + its handling, we see an additional > early shot (about 3 µs too early here - the longer the timer is > programmed in advance, the larger the error gets) before the xntimer > finally expires. But at the same time, /proc/xenomai/latency reports > 1000 (1 µs). So there must be more discrepancy between TSC and APIC > timebases, no? Well, nothing critical, but at least suboptimal, maybe > pointing at some hidden minor bug. Once time permits, I will check the > APIC frequency and the delay calculation on my box and compare it to > what Linux uses.
Looks like Xenomai is using an inaccurate APIC frequency (probably since ages): 10.383 MHz on one of my boxes vs. 10.39591 MHz according to Linux' calibration ( (1,000,000,000 ns * clock_event_device.mult) >> clock_event_device.shift ), which is based on the PM-timer. As the real frequency is higher, the APIC fires earlier than we want to. Consider, e.g., the 4 ms host tick period => 5 µs too early! This correlates with my LTTng traces. I will try to fix this issue by extending the ipipe_request_tickdev interface so that it returns also the frequency of the requested tick device - as long as Xenomai 2.4 is not released, such an API breakage should not cause any hassle IMHO. (At this chance, I will also try to kill clock_event_device.delta. I think I have a nicer approach...) Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux _______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
