Philippe Gerum wrote:
> On Tue, 2009-04-28 at 14:21 +0200, Gilles Chanteperdrix wrote:
>> Philippe Gerum wrote:
>>> On Tue, 2009-04-28 at 07:50 +0200, Gilles Chanteperdrix wrote:
>>>> Hi,
>>>> currently, the situation is this:
>>>> - the timing core uses an approximate value of the cpu frequency (using
>>>> xnarch_llmulshft) to do conversions between tsc and ns;
>>>> - the APIC timer reprogrammation still uses imuldiv, that is a more
>>>> exact cpu frequency, coupled with an approximate APIC frequency
>>>> (obtained from ipipe_request_tickdev), to do the conversion between tsc
>>>> delays and APIC delays;
>>>> - the posix skin uses llimd to do conversions between timespec and
>>>> timeval structures and tsc values
>>>> - the posix and native skins in user-space still use llimd to do
>>>> conversions between ns and tsc (only if using tsc in user-space).
>>>> These are causes of unprecisions, I think we should fix this, though it
>>>> is unlikely to be the cause of the high jitters observed by Vikesh with
>>>> 2.5-rc1.
>>> Ack, we definitely should. Working on allowing userland to use
>>> llmulshift for timing computations for the native skin here, as a first
>>> step. For that purpose, xnsysinfo_t has just been extended to carry the
>>> pre-scaled values needed for llmulshft. I just don't want to have to
>>> issue a syscall for those conversions to take place.
>> Actually, the pre-scaled values could be re-computed in user-space
>> without changing the ABI.
> We don't care that much about changing the ABI between -rc1 and -rc2
> actually, so it mostly depends whether we want to backport the fix to
> 2.4 regarding the tsc->ns conversion, since we do not have any nodiv
> implementation for the ns->tsc one there yet.

But we have llmulshft, do we ? which means that we do have the problem
of approximate cpu frequency.


Xenomai-core mailing list

Reply via email to