Re: [Xenomai-core] Testing LTTng: first insights

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 3030 bytes --]

Philippe Gerum wrote:
> Jan Kiszka wrote:
>> 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.
>>
> 
> Oops. Once again, this proves that having a permanent trace facility in
> place is key to uncover bugs.
> 
>> 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.
>>
> 
> You may want to have a look at ipipe_get_sysinfo() first, and track the
> use of the tmfreq field in Xenomai. This may be what you want to fix,

Nope tmfreq is not involved. The problem is:

	rthal_timerfreq_arg = apic_read(APIC_TMICT) * HZ;

> IIUC. This would keep the older patches usable with the next Xenomai
> version, which is very desirable.

We could extend the information ipipe_get_sysinfo returns by the timer
frequency. But to play cleanly, we would have to critical_enter first,
look up the currently used clock_event_device, maybe even validate that
it was hijacked, and then return its frequency. The problem with this
API is, that it is by nature unsynchronised with ipipe_request_tickdev,
thus would not always be able to return a valid frequency.

Actually, we would only exclude a few patches when going the
ipipe_request_tickdev way: those few that were clockevent-aware up to
today. For all others (namely 2.6.20 on i386 and up to 2.6.23 on
x86_64), we would simply fall back to our current inaccurate approach. I
think this is more acceptable than an ipipe_get_sysinfo extension.

Hmm, maybe we could install a temporary API for x86_64 so that users
don't have to wait for 2.6.24 to get an accurate APIC. This would be
removed again with the first unified x86-ipipe patch.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]