Hello,
I'm currently working on my diploma thesis which will finish in December
2006. The first goal of my project is to integrate Xenomai events to
LTTng, a task quite simple since creating new events in LTTng is not
very difficult. The second goal is to create a new module in the viewer,
Jean-Olivier Villemure wrote:
Hello,
I'm currently working on my diploma thesis which will finish in December
2006. The first goal of my project is to integrate Xenomai events to
LTTng, a task quite simple since creating new events in LTTng is not
very difficult.
Does this mean we will see
Jan Kiszka wrote:
Hi,
between some football half-times of the last days ;), I played a bit
with a hand-optimised xnarch_tsc_to_ns() for x86. Using scaled math, I
achieved between 3 (P-I 133 MHz) to 4 times (P-M 1.3 GHz) faster
conversions than with the current variant. While this optimisation
Philippe Gerum wrote:
Jan Kiszka wrote:
Hi,
between some football half-times of the last days ;), I played a bit
with a hand-optimised xnarch_tsc_to_ns() for x86. Using scaled math, I
achieved between 3 (P-I 133 MHz) to 4 times (P-M 1.3 GHz) faster
conversions than with the current variant.
Jan Kiszka wrote:
Hi,
To avoid loosing the optimisation again in ns_to_tsc, I thought about
basing the whole internal timer arithmetics on nanoseconds instead of
TSCs as it is now.
Good idea, makes it simpler to adopt to laptop frequency scaling and deep ACPI
sleep, i.e. sync Xenomai time to
Jan Kiszka wrote:
Hi,
between some football half-times of the last days ;), I played a bit
with a hand-optimised xnarch_tsc_to_ns() for x86. Using scaled math, I
achieved between 3 (P-I 133 MHz) to 4 times (P-M 1.3 GHz) faster
conversions than with the current variant. While this
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Hi,
between some football half-times of the last days ;), I played a bit
with a hand-optimised xnarch_tsc_to_ns() for x86. Using scaled math, I
achieved between 3 (P-I 133 MHz) to 4 times (P-M 1.3 GHz) faster
conversions than with
Jean-Olivier Villemure wrote:
Hello,
I'm currently working on my diploma thesis which will finish in December
2006. The first goal of my project is to integrate Xenomai events to
LTTng, a task quite simple since creating new events in LTTng is not
very difficult. The second goal is to create
Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
static inline unsigned long long ns_2_cycles(unsigned long long ns)
{
return ns * ns2cyc_scale NS2CYC_SCALE_FACTOR;
This multiplication is 64 bits * 32 bits, the intermediate result may
need more than 64 bits, so you should compute
Philippe Gerum wrote:
Jan Kiszka wrote:
Philippe Gerum wrote:
from i386/kernel/timers/timer_tsc.c. And indeed, I had x 20 performance
improvements in some cases.
Oops, that sounds like a bit too extreme optimisations. Is the original
version varying that much? I didn't observe this.
Here
Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
static inline unsigned long long ns_2_cycles(unsigned long long ns)
{
return ns * ns2cyc_scale NS2CYC_SCALE_FACTOR;
This multiplication is 64 bits * 32 bits, the intermediate result may
need
Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
static inline unsigned long long ns_2_cycles(unsigned long long ns)
{
return ns * ns2cyc_scale NS2CYC_SCALE_FACTOR;
This multiplication is 64 bits * 32 bits, the
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Philippe Gerum wrote:
from i386/kernel/timers/timer_tsc.c. And indeed, I had x 20 performance
improvements in some cases.
Oops, that sounds like a bit too extreme optimisations. Is the original
version varying that much? I didn't
Philippe Gerum wrote:
Jan Kiszka wrote:
:) We should coordinate better.
The answer is published roadmap + todo list, but this requires some
organisation we have not been able to setup yet.
Indeed.
I think this is first of all a technical issue: lowering the convenience
barrier for
Jan Kiszka wrote:
Philippe Gerum wrote:
Here is likely why we have different levels of accuracy and performance,
firstly my version is bluntly based on the khz freq, secondly it
calculates the other way around, i.e. ns2tsc, so that tsc are keep in
the inner code, but more
Hi,
__rthal_generic_div96by32 from asm-generic/hal.h looks similar to
__rthal_div96by32 from asm-i386/hal.h. Shouldn't this get cleaned up?
Jan
signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
Jan Kiszka wrote:
Philippe Gerum wrote:
Here is likely why we have different levels of accuracy and performance,
firstly my version is bluntly based on the khz freq, secondly it
calculates the other way around, i.e. ns2tsc, so that tsc are keep in
the inner code, but more efficiently converted
Philippe Gerum wrote:
Redone the check here on a Centrino 1.6Mhz, and still have roughly x20
improvement (a bit better actually). I'm using Debian/sarge gcc 3.3.5.
I think I remember that Pentium M has a much shorter mull instruction
than other processors of the family.
--
Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
Redone the check here on a Centrino 1.6Mhz, and still have roughly x20
improvement (a bit better actually). I'm using Debian/sarge gcc 3.3.5.
I think I remember that Pentium M has a much shorter mull instruction
than other processors of
Hi
I noticed that, eg.
http://ngiger.dyndns.org/buildbot/hcu3/builds/80/step-mk_xeno/0
there are build failures. It tells me
Making install in vrtx
make[4]: Entering directory
`/mnt/data.ng/buildslave/buildbot/quick-hcu3/build/hcu/src/skins/vrtx'
make[4]: *** No rule to make target `event.c',
Niklaus Giger wrote:
Hi
I noticed that, eg.
http://ngiger.dyndns.org/buildbot/hcu3/builds/80/step-mk_xeno/0
there are build failures. It tells me
Making install in vrtx
make[4]: Entering directory
`/mnt/data.ng/buildslave/buildbot/quick-hcu3/build/hcu/src/skins/vrtx'
make[4]: *** No rule to
21 matches
Mail list logo
