Re: [Xenomai-core] latencys drifting into negative (Xenomai 2.4.2/2.4.3)

[Jan Kiszka]

Jan Kiszka wrote:

Gilles Chanteperdrix wrote:

On Fri, Apr 4, 2008 at 12:45 PM, Jan Kiszka <[EMAIL PROTECTED]> wrote:

Sebastian Smolorz wrote:

Jan Kiszka wrote:

Sebastian Smolorz wrote:

Jan Kiszka wrote:

This patch may do the trick: it uses the inverted tsc-to-ns function

instead of the frequency-based one. Be warned, it is totally untested inside

Xenomai, I just ran it in a user space test program. But it may give an
idea.

Your patch needed two minor corrections (ns instead of ts in functions

xnarch_ns_to_tsc()) in order to compile. A short run (30 minutes) of latency

-t1 seems to prove your bug-fix: There seems to be no drift.

That's good to hear.

If I got your patch correctly, it doesn't make xnarch_tsc_to_ns more

precise but introduces a new function xnarch_ns_to_tsc() which is also less

precise than the generic xnarch_ns_to_tsc(), right?

Yes. It is now precisely the inverse imprecision, so to say. :)

So isn't there still the danger of getting wrong values when calling

xnarch_tsc_to_ns()  not in combination with xnarch_ns_to_tsc()?

Only if the user decides to implement his own conversion. Xenomai with

all its skins and both in kernel and user space should always run through

the xnarch_* path.

OK, would you commit the patch?

 Will do unless someone else has concerns. Gilles, Philippe? ARM and
Blackfin then need to be fixed similarly, full patch attached.

Well, I am sorry, but I do not like this solution;
- the aim of scaled math is to avoid divisions, and with this patch we
end up using divisions;

Please check again, no new division due to my patch, just different parameters for the existing one.

- with scaled math we do wrong calculations, and making a wrong
xnarch_ns_to_tsc only works for values which should be passed to
xnarch_tsc_to_ns.

IMHO, the error is within the range of the clock's precision, if not even below. So struggling for mathematically precise conversion of imprecise physical values makes no sense to me. Therefore I once proposed the scaled-math optimization.

Jan

But this does not mean that I'm opposing even faster division-less ns_to_tsc with scaled-math parameters, i.e. combining best of both worlds!

signature.asc
Description: OpenPGP digital signature

_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core