[Xenomai-core] xenomai 2.5 rc1 timing computations.

[Xenomai-core] xenomai 2.5 rc1 timing computations.

[Gilles Chanteperdrix]

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.

Regards.

-- 
					    Gilles.

Re: [Xenomai-core] xenomai 2.5 rc1 timing computations.

[Gilles Chanteperdrix]

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

imprecisions.


-- 
					    Gilles.

Re: [Xenomai-core] xenomai 2.5 rc1 timing computations.

[Philippe Gerum]

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.

> Regards.
> 
-- 
Philippe.

Re: [Xenomai-core] xenomai 2.5 rc1 timing computations.

[Gilles Chanteperdrix]

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. BTW, I wonder why this computations starts
with a shift value of 31 and not 32. Using 32 when possible would
improve the precision.

-- 
                                                 Gilles.

Re: [Xenomai-core] xenomai 2.5 rc1 timing computations.

[Philippe Gerum]

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.

-- 
Philippe.

Re: [Xenomai-core] xenomai 2.5 rc1 timing computations.

[Gilles Chanteperdrix]

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.

-- 
                                                 Gilles.

Re: [Xenomai-core] xenomai 2.5 rc1 timing computations.

[Philippe Gerum]

On Tue, 2009-04-28 at 15:45 +0200, Gilles Chanteperdrix wrote:
> 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.
> 
 
So I guess your answer to the "should backport" question is yes, we
should. Ok, so we do have to run xnarch_init_u32frac and friends from
userland. I will try to find a better excuse for procrastinating then...

-- 
Philippe.

Re: [Xenomai-core] xenomai 2.5 rc1 timing computations.

[Vikesh Rambaran]

Hi

On Tue, 2009-04-28 at 16:00 +0200, Philippe Gerum wrote:
> On Tue, 2009-04-28 at 15:45 +0200, Gilles Chanteperdrix wrote:
> > > 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.
> > 
>  
> So I guess your answer to the "should backport" question is yes, we
> should. Ok, so we do have to run xnarch_init_u32frac and friends from
> userland. I will try to find a better excuse for procrastinating then...
> 

Thanx for the effort 

Just for info, i tested adeos patch 2.6.28.9-x86-2.2-07 with Xenomai
2.4.7 with regards the timing (as described in the thread "adeos patch
2.6.28.9-x86-2.2-07 feedback" on the xenomai-help mailing list)

I compared those results with the ones i obtained from
adeos-ipipe-2.6.24-x86-2.0-07.patch with Xenomai 2.4.5.

My testing with Xenomai 2.5 rc1 was just to boot and see if the lockup
problem was still present. Would you would like me to do the latency
tests with Xenomai 2.5 rc1 ?

Keep well
Vicki