[Xenomai] Cyclictest in Xenomai-3

[Xenomai] Cyclictest in Xenomai-3

[Konstantinos Chalas]

Hello everyone,

Is there any plans to port cyclictest over at xenomai-3 for the Cobalt 
kernel? I compiled the original source file from the rt-tests repo my 
self for xenomai-3,. For reference i used to get around 70 us worst case 
with the Beaglebone black using Xenomai-2, but it goes up to 200 us 
immediatly with the one i compiled. By the way, i followed the 
xeno-config procedure. Is there anyone who cares to provide an explanation?

Thanks,
Konstantinos Chalas

Re: [Xenomai] Cyclictest in Xenomai-3

[Philippe Gerum]

On 08/27/2015 04:53 PM, Konstantinos Chalas wrote:
> Hello everyone,
> 
> Is there any plans to port cyclictest over at xenomai-3 for the Cobalt
> kernel? I compiled the original source file from the rt-tests repo my
> self for xenomai-3,. For reference i used to get around 70 us worst case
> with the Beaglebone black using Xenomai-2, but it goes up to 200 us
> immediatly with the one i compiled. By the way, i followed the
> xeno-config procedure. Is there anyone who cares to provide an explanation?
> 

Any information about the exact build command used, the clock
calibration from /proc/xenomai/clock/coreclk, and the options passed to
cyclictest?

Btw, the vanilla cyclictest code had to be adapted for running over
Xenomai 2.

-- 
Philippe.

Re: [Xenomai] Cyclictest in Xenomai-3

[Konstantinos Chalas]

The build command for cyclictest was

gcc -Wall -Wno-nonnull -I/usr/xenomai/include/cobalt 
-I/usr/xenomai/include -march=armv7-a -mfpu=vfp3 -D_GNU_SOURCE 
-D_REENTRANT -D__COBALT__ -O2 -Wl,@/usr/xenomai/lib/cobalt.wrappers 
/usr/xenomai/lib/xenomai/bootstrap.o -Wl,--wrap=main 
-Wl,--dynamic-list=/usr/xenomai/lib/dynlist.ld -L/usr/xenomai/lib 
-lcobalt -lpthread -lrt -march=armv7-a -mfpu=vfp3   -o cyclictest 
cyclictest.o -lrt -lpthread -lrttest -L

Also the clock calibration is (i already run the autotune utility),

root@beaglebone:~# cat /proc/xenomai/clock/coreclk
gravity: irq=499 kernel=1999 user=4999
devices: timer=timer2, clock=ipipe_tsc
  status: on
   setup: 999
   ticks: 350959191461

and finally i run cyclictest with Thanks for the interest!

cyclictest -n -p 99 -D 1000 -i 250 -m Thanks for the interest!**
On 08/27/2015 05:10 PM, Philippe Gerum wrote:
> On 08/27/2015 04:53 PM, Konstantinos Chalas wrote:
>> Hello everyone,
>>
>> Is there any plans to port cyclictest over at xenomai-3 for the Cobalt
>> kernel? I compiled the original source file from the rt-tests repo my
>> self for xenomai-3,. For reference i used to get around 70 us worst case
>> with the Beaglebone black using Xenomai-2, but it goes up to 200 us
>> immediatly with the one i compiled. By the way, i followed the
>> xeno-config procedure. Is there anyone who cares to provide an explanation?
>>
> Any information about the exact build command used, the clock
> calibration from /proc/xenomai/clock/coreclk, and the options passed to
> cyclictest?
>
> Btw, the vanilla cyclictest code had to be adapted for running over
> Xenomai 2.
>

Re: [Xenomai] Cyclictest in Xenomai-3

[Philippe Gerum]

On 08/27/2015 05:55 PM, Konstantinos Chalas wrote:
> The build command for cyclictest was
> 
> gcc -Wall -Wno-nonnull -I/usr/xenomai/include/cobalt
> -I/usr/xenomai/include -march=armv7-a -mfpu=vfp3 -D_GNU_SOURCE
> -D_REENTRANT -D__COBALT__ -O2 -Wl,@/usr/xenomai/lib/cobalt.wrappers  
> /usr/xenomai/lib/xenomai/bootstrap.o -Wl,--wrap=main
> -Wl,--dynamic-list=/usr/xenomai/lib/dynlist.ld -L/usr/xenomai/lib
> -lcobalt -lpthread -lrt -march=armv7-a -mfpu=vfp3   -o cyclictest
> cyclictest.o -lrt -lpthread -lrttest -L
> 
> Also the clock calibration is (i already run the autotune utility),
> 
> root@beaglebone:~# cat /proc/xenomai/clock/coreclk
> gravity: irq=499 kernel=1999 user=4999
> devices: timer=timer2, clock=ipipe_tsc
>  status: on
>   setup: 999
>   ticks: 350959191461
> 
> and finally i run cyclictest with Thanks for the interest!
> 
> cyclictest -n -p 99 -D 1000 -i 250 -m

No wonder why you get weird results, the cyclictest thread does not run
with a real-time priority since it uses sched_setscheduler() which is
not wrapped by cobalt (pthread_setschedparam() is). You can check this
by looking at /proc/xenomai/sched/threads.

The quick and dirty hack below fixes it, and amends the Makefile to
switch to the Xenomai libs from a cross-compilation root, when the
COBALT variable is mentioned on the make command line. You may need to
do some fixup there if you don't install under $crossroot/usr/xenomai
though.

diff --git a/Makefile b/Makefile
index a48e759..49301b6 100644
--- a/Makefile
+++ b/Makefile
@@ -28,7 +28,7 @@ CPPFLAGS += -D_GNU_SOURCE -Isrc/include
 LDFLAGS ?=

 ifneq ($(filter x86_64 i386 ia64 mips powerpc,$(machinetype)),)
-NUMA 	:= 1
+NUMA 	:= 0
 ifdef HAVE_PARSE_CPUSTRING_ALL
 	CFLAGS += -DHAVE_PARSE_CPUSTRING_ALL
 endif
@@ -47,6 +47,11 @@ ifeq ($(NUMA),1)
 	NUMA_LIBS = -lnuma
 endif

+ifneq ($(COBALT),)
+	CFLAGS += $(shell DESTDIR=$(COBALT) $(COBALT)/usr/bin/xeno-config
--posix --cflags)
+	LDFLAGS += $(shell DESTDIR=$(COBALT) $(COBALT)/usr/bin/xeno-config
--posix --ldflags)
+endif
+
 VPATH	= src/cyclictest:
 VPATH	+= src/signaltest:
 VPATH	+= src/pi_tests:
diff --git a/src/cyclictest/cyclictest.c b/src/cyclictest/cyclictest.c
index 34053c5..92c7043 100644
--- a/src/cyclictest/cyclictest.c
+++ b/src/cyclictest/cyclictest.c
@@ -795,7 +795,7 @@ void *timerthread(void *param)

 	memset(&schedp, 0, sizeof(schedp));
 	schedp.sched_priority = par->prio;
-	if (setscheduler(0, par->policy, &schedp))
+	if (pthread_setschedparam(pthread_self(), par->policy, &schedp))
 		fatal("timerthread%d: failed to set priority to %d\n", par->cpu,
par->prio);

 	/* Get current time */
-- 
Philippe.

Re: [Xenomai] Cyclictest in Xenomai-3

[Konstantinos Chalas]

Great! Now, it is much better! Thanks for the interest.

I have noticed something else, when using clock_nanosleep, there is 
something wrong going on. Example output with clock_nanosleep:

root@beaglebone:~# cyclictest    -p 99  -i 250 -n
# /dev/cpu_dma_latency set to 0us
policy: fifo: loadavg: 1.13 1.18 1.15 1/243 2385

T: 0 ( 2384) P:99 I:250 C: 122168 Min:      0 Act:    9 *Avg:2147483647* 
Max:      -1

The Avg value jumps to this insane number.
I didn't find any differences between the vanilla cyclictest and the 
xenomai-2.6 upstream cyclictest regarding the use of clock_nanosleep. 
Any ideas of where this behaviour would come from?

Thanks,
Konstantinos

On 08/28/2015 10:04 AM, Philippe Gerum wrote:
> On 08/27/2015 05:55 PM, Konstantinos Chalas wrote:
>> The build command for cyclictest was
>>
>> gcc -Wall -Wno-nonnull -I/usr/xenomai/include/cobalt
>> -I/usr/xenomai/include -march=armv7-a -mfpu=vfp3 -D_GNU_SOURCE
>> -D_REENTRANT -D__COBALT__ -O2 -Wl,@/usr/xenomai/lib/cobalt.wrappers
>> /usr/xenomai/lib/xenomai/bootstrap.o -Wl,--wrap=main
>> -Wl,--dynamic-list=/usr/xenomai/lib/dynlist.ld -L/usr/xenomai/lib
>> -lcobalt -lpthread -lrt -march=armv7-a -mfpu=vfp3   -o cyclictest
>> cyclictest.o -lrt -lpthread -lrttest -L
>>
>> Also the clock calibration is (i already run the autotune utility),
>>
>> root@beaglebone:~# cat /proc/xenomai/clock/coreclk
>> gravity: irq=499 kernel=1999 user=4999
>> devices: timer=timer2, clock=ipipe_tsc
>>   status: on
>>    setup: 999
>>    ticks: 350959191461
>>
>> and finally i run cyclictest with Thanks for the interest!
>>
>> cyclictest -n -p 99 -D 1000 -i 250 -m
> No wonder why you get weird results, the cyclictest thread does not run
> with a real-time priority since it uses sched_setscheduler() which is
> not wrapped by cobalt (pthread_setschedparam() is). You can check this
> by looking at /proc/xenomai/sched/threads.
>
> The quick and dirty hack below fixes it, and amends the Makefile to
> switch to the Xenomai libs from a cross-compilation root, when the
> COBALT variable is mentioned on the make command line. You may need to
> do some fixup there if you don't install under $crossroot/usr/xenomai
> though.
>
> diff --git a/Makefile b/Makefile
> index a48e759..49301b6 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -28,7 +28,7 @@ CPPFLAGS += -D_GNU_SOURCE -Isrc/include
>   LDFLAGS ?=
>
>   ifneq ($(filter x86_64 i386 ia64 mips powerpc,$(machinetype)),)
> -NUMA 	:= 1
> +NUMA 	:= 0
>   ifdef HAVE_PARSE_CPUSTRING_ALL
>   	CFLAGS += -DHAVE_PARSE_CPUSTRING_ALL
>   endif
> @@ -47,6 +47,11 @@ ifeq ($(NUMA),1)
>   	NUMA_LIBS = -lnuma
>   endif
>
> +ifneq ($(COBALT),)
> +	CFLAGS += $(shell DESTDIR=$(COBALT) $(COBALT)/usr/bin/xeno-config
> --posix --cflags)
> +	LDFLAGS += $(shell DESTDIR=$(COBALT) $(COBALT)/usr/bin/xeno-config
> --posix --ldflags)
> +endif
> +
>   VPATH	= src/cyclictest:
>   VPATH	+= src/signaltest:
>   VPATH	+= src/pi_tests:
> diff --git a/src/cyclictest/cyclictest.c b/src/cyclictest/cyclictest.c
> index 34053c5..92c7043 100644
> --- a/src/cyclictest/cyclictest.c
> +++ b/src/cyclictest/cyclictest.c
> @@ -795,7 +795,7 @@ void *timerthread(void *param)
>
>   	memset(&schedp, 0, sizeof(schedp));
>   	schedp.sched_priority = par->prio;
> -	if (setscheduler(0, par->policy, &schedp))
> +	if (pthread_setschedparam(pthread_self(), par->policy, &schedp))
>   		fatal("timerthread%d: failed to set priority to %d\n", par->cpu,
> par->prio);
>
>   	/* Get current time */

Re: [Xenomai] Cyclictest in Xenomai-3

[Philippe Gerum]

On 08/28/2015 02:37 PM, Konstantinos Chalas wrote:
> Great! Now, it is much better! Thanks for the interest.
> 
> I have noticed something else, when using clock_nanosleep, there is
> something wrong going on. Example output with clock_nanosleep:
> 
> root@beaglebone:~# cyclictest    -p 99  -i 250 -n
> # /dev/cpu_dma_latency set to 0us
> policy: fifo: loadavg: 1.13 1.18 1.15 1/243 2385         
> 
> T: 0 ( 2384) P:99 I:250 C: 122168 Min:      0 Act:    9 *Avg:2147483647*
> Max:      -1
> 
> The Avg value jumps to this insane number.
> I didn't find any differences between the vanilla cyclictest and the
> xenomai-2.6 upstream cyclictest regarding the use of clock_nanosleep.
> Any ideas of where this behaviour would come from?

Which kernel and I-pipe release are you running?

-- 
Philippe.

Re: [Xenomai] Cyclictest in Xenomai-3

[Konstantinos Chalas]

Hello,

root@beaglebone:~# uname -a
Linux beaglebone 3.14.44+ #1 SMP PREEMPT Wed Aug 26 23:41:20 CEST 2015 
armv7l GNU/Linux

and ipipe-core-3.14.44-arm-12

Thanks

On 08/28/2015 02:46 PM, Philippe Gerum wrote:
> On 08/28/2015 02:37 PM, Konstantinos Chalas wrote:
>> Great! Now, it is much better! Thanks for the interest.
>>
>> I have noticed something else, when using clock_nanosleep, there is
>> something wrong going on. Example output with clock_nanosleep:
>>
>> root@beaglebone:~# cyclictest    -p 99  -i 250 -n
>> # /dev/cpu_dma_latency set to 0us
>> policy: fifo: loadavg: 1.13 1.18 1.15 1/243 2385
>>
>> T: 0 ( 2384) P:99 I:250 C: 122168 Min:      0 Act:    9 *Avg:2147483647*
>> Max:      -1
>>
>> The Avg value jumps to this insane number.
>> I didn't find any differences between the vanilla cyclictest and the
>> xenomai-2.6 upstream cyclictest regarding the use of clock_nanosleep.
>> Any ideas of where this behaviour would come from?
> Which kernel and I-pipe release are you running?
>

Re: [Xenomai] Cyclictest in Xenomai-3

[Philippe Gerum]

On 08/28/2015 02:51 PM, Konstantinos Chalas wrote:
> Hello,
> 
> root@beaglebone:~# uname -a
> Linux beaglebone 3.14.44+ #1 SMP PREEMPT Wed Aug 26 23:41:20 CEST 2015
> armv7l GNU/Linux
> 
> and ipipe-core-3.14.44-arm-12
> 

Do you have any weird values appearing during a standard latency test? e.g.

# latency [-t0]

> Thanks
> 
> On 08/28/2015 02:46 PM, Philippe Gerum wrote:
>> On 08/28/2015 02:37 PM, Konstantinos Chalas wrote:
>>> Great! Now, it is much better! Thanks for the interest.
>>>
>>> I have noticed something else, when using clock_nanosleep, there is
>>> something wrong going on. Example output with clock_nanosleep:
>>>
>>> root@beaglebone:~# cyclictest    -p 99  -i 250 -n
>>> # /dev/cpu_dma_latency set to 0us
>>> policy: fifo: loadavg: 1.13 1.18 1.15 1/243 2385         
>>>
>>> T: 0 ( 2384) P:99 I:250 C: 122168 Min:      0 Act:    9 *Avg:2147483647*
>>> Max:      -1
>>>
>>> The Avg value jumps to this insane number.
>>> I didn't find any differences between the vanilla cyclictest and the
>>> xenomai-2.6 upstream cyclictest regarding the use of clock_nanosleep.
>>> Any ideas of where this behaviour would come from?
>> Which kernel and I-pipe release are you running?
>>
> 


-- 
Philippe.

Re: [Xenomai] Cyclictest in Xenomai-3

[Konstantinos Chalas]

No, besides a negative lat best value, like this:

RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat 
best|--lat worst
RTD|      1.080|      3.013|     40.080|            0| 0|     
-1.275|     43.961

On 08/28/2015 02:59 PM, Philippe Gerum wrote:
> On 08/28/2015 02:51 PM, Konstantinos Chalas wrote:
>> Hello,
>>
>> root@beaglebone:~# uname -a
>> Linux beaglebone 3.14.44+ #1 SMP PREEMPT Wed Aug 26 23:41:20 CEST 2015
>> armv7l GNU/Linux
>>
>> and ipipe-core-3.14.44-arm-12
>>
> Do you have any weird values appearing during a standard latency test? e.g.
>
> # latency [-t0]
>
>> Thanks
>>
>> On 08/28/2015 02:46 PM, Philippe Gerum wrote:
>>> On 08/28/2015 02:37 PM, Konstantinos Chalas wrote:
>>>> Great! Now, it is much better! Thanks for the interest.
>>>>
>>>> I have noticed something else, when using clock_nanosleep, there is
>>>> something wrong going on. Example output with clock_nanosleep:
>>>>
>>>> root@beaglebone:~# cyclictest    -p 99  -i 250 -n
>>>> # /dev/cpu_dma_latency set to 0us
>>>> policy: fifo: loadavg: 1.13 1.18 1.15 1/243 2385
>>>>
>>>> T: 0 ( 2384) P:99 I:250 C: 122168 Min:      0 Act:    9 *Avg:2147483647*
>>>> Max:      -1
>>>>
>>>> The Avg value jumps to this insane number.
>>>> I didn't find any differences between the vanilla cyclictest and the
>>>> xenomai-2.6 upstream cyclictest regarding the use of clock_nanosleep.
>>>> Any ideas of where this behaviour would come from?
>>> Which kernel and I-pipe release are you running?
>>>
>

Re: [Xenomai] Cyclictest in Xenomai-3

[Philippe Gerum]

On 08/28/2015 03:13 PM, Konstantinos Chalas wrote:
> No, besides a negative lat best value, like this:
> 
> RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat
> best|--lat worst
> RTD|      1.080|      3.013|     40.080|            0| 0|    
> -1.275|     43.961

Ok, that one is innocuous, this is only a timer calibration issue. The
strange average value may be an issue in cyclictest since 2147483647 is
2^31-1, which is INT32_MAX. A bit like no sample had been recorded
during such run.

> 
> On 08/28/2015 02:59 PM, Philippe Gerum wrote:
>> On 08/28/2015 02:51 PM, Konstantinos Chalas wrote:
>>> Hello,
>>>
>>> root@beaglebone:~# uname -a
>>> Linux beaglebone 3.14.44+ #1 SMP PREEMPT Wed Aug 26 23:41:20 CEST 2015
>>> armv7l GNU/Linux
>>>
>>> and ipipe-core-3.14.44-arm-12
>>>
>> Do you have any weird values appearing during a standard latency test?
>> e.g.
>>
>> # latency [-t0]
>>
>>> Thanks
>>>
>>> On 08/28/2015 02:46 PM, Philippe Gerum wrote:
>>>> On 08/28/2015 02:37 PM, Konstantinos Chalas wrote:
>>>>> Great! Now, it is much better! Thanks for the interest.
>>>>>
>>>>> I have noticed something else, when using clock_nanosleep, there is
>>>>> something wrong going on. Example output with clock_nanosleep:
>>>>>
>>>>> root@beaglebone:~# cyclictest    -p 99  -i 250 -n
>>>>> # /dev/cpu_dma_latency set to 0us
>>>>> policy: fifo: loadavg: 1.13 1.18 1.15 1/243 2385
>>>>>
>>>>> T: 0 ( 2384) P:99 I:250 C: 122168 Min:      0 Act:    9
>>>>> *Avg:2147483647*
>>>>> Max:      -1
>>>>>
>>>>> The Avg value jumps to this insane number.
>>>>> I didn't find any differences between the vanilla cyclictest and the
>>>>> xenomai-2.6 upstream cyclictest regarding the use of clock_nanosleep.
>>>>> Any ideas of where this behaviour would come from?
>>>> Which kernel and I-pipe release are you running?
>>>>
>>
> 
> 


-- 
Philippe.

Re: [Xenomai] Cyclictest in Xenomai-3

[Konstantinos Chalas]

It wasn't innocuous... The variable uint64_t diff was used to store the 
latency, which in turn took the value -1 because of the timer 
calibration issue , therefore when casted as unsigned produced 2^64-1. 
It works as it should after running autotune.

Thank you very much for the help,
Konstantinos

On 08/28/2015 03:22 PM, Philippe Gerum wrote:
> On 08/28/2015 03:13 PM, Konstantinos Chalas wrote:
>> No, besides a negative lat best value, like this:
>>
>> RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat
>> best|--lat worst
>> RTD|      1.080|      3.013|     40.080|            0| 0|
>> -1.275|     43.961
> Ok, that one is innocuous, this is only a timer calibration issue. The
> strange average value may be an issue in cyclictest since 2147483647 is
> 2^31-1, which is INT32_MAX. A bit like no sample had been recorded
> during such run.
>
>> On 08/28/2015 02:59 PM, Philippe Gerum wrote:
>>> On 08/28/2015 02:51 PM, Konstantinos Chalas wrote:
>>>> Hello,
>>>>
>>>> root@beaglebone:~# uname -a
>>>> Linux beaglebone 3.14.44+ #1 SMP PREEMPT Wed Aug 26 23:41:20 CEST 2015
>>>> armv7l GNU/Linux
>>>>
>>>> and ipipe-core-3.14.44-arm-12
>>>>
>>> Do you have any weird values appearing during a standard latency test?
>>> e.g.
>>>
>>> # latency [-t0]
>>>
>>>> Thanks
>>>>
>>>> On 08/28/2015 02:46 PM, Philippe Gerum wrote:
>>>>> On 08/28/2015 02:37 PM, Konstantinos Chalas wrote:
>>>>>> Great! Now, it is much better! Thanks for the interest.
>>>>>>
>>>>>> I have noticed something else, when using clock_nanosleep, there is
>>>>>> something wrong going on. Example output with clock_nanosleep:
>>>>>>
>>>>>> root@beaglebone:~# cyclictest    -p 99  -i 250 -n
>>>>>> # /dev/cpu_dma_latency set to 0us
>>>>>> policy: fifo: loadavg: 1.13 1.18 1.15 1/243 2385
>>>>>>
>>>>>> T: 0 ( 2384) P:99 I:250 C: 122168 Min:      0 Act:    9
>>>>>> *Avg:2147483647*
>>>>>> Max:      -1
>>>>>>
>>>>>> The Avg value jumps to this insane number.
>>>>>> I didn't find any differences between the vanilla cyclictest and the
>>>>>> xenomai-2.6 upstream cyclictest regarding the use of clock_nanosleep.
>>>>>> Any ideas of where this behaviour would come from?
>>>>> Which kernel and I-pipe release are you running?
>>>>>
>>
>

Re: [Xenomai] Cyclictest in Xenomai-3

[Philippe Gerum]

On 08/30/2015 10:33 PM, Konstantinos Chalas wrote:
> It wasn't innocuous... The variable uint64_t diff was used to store the
> latency, which in turn took the value -1 because of the timer
> calibration issue ,

Which is innocuous. It only means that you got a task rescheduling early
by a microsecond once due to the incorrect calibration. This does not
reveal any malfunction.

 therefore when casted as unsigned produced 2^64-1.
> It works as it should after running autotune.
> 
> Thank you very much for the help,
> Konstantinos
> 
> On 08/28/2015 03:22 PM, Philippe Gerum wrote:
>> On 08/28/2015 03:13 PM, Konstantinos Chalas wrote:
>>> No, besides a negative lat best value, like this:
>>>
>>> RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat
>>> best|--lat worst
>>> RTD|      1.080|      3.013|     40.080|            0| 0|
>>> -1.275|     43.961
>> Ok, that one is innocuous, this is only a timer calibration issue. The
>> strange average value may be an issue in cyclictest since 2147483647 is
>> 2^31-1, which is INT32_MAX. A bit like no sample had been recorded
>> during such run.
>>
>>> On 08/28/2015 02:59 PM, Philippe Gerum wrote:
>>>> On 08/28/2015 02:51 PM, Konstantinos Chalas wrote:
>>>>> Hello,
>>>>>
>>>>> root@beaglebone:~# uname -a
>>>>> Linux beaglebone 3.14.44+ #1 SMP PREEMPT Wed Aug 26 23:41:20 CEST 2015
>>>>> armv7l GNU/Linux
>>>>>
>>>>> and ipipe-core-3.14.44-arm-12
>>>>>
>>>> Do you have any weird values appearing during a standard latency test?
>>>> e.g.
>>>>
>>>> # latency [-t0]
>>>>
>>>>> Thanks
>>>>>
>>>>> On 08/28/2015 02:46 PM, Philippe Gerum wrote:
>>>>>> On 08/28/2015 02:37 PM, Konstantinos Chalas wrote:
>>>>>>> Great! Now, it is much better! Thanks for the interest.
>>>>>>>
>>>>>>> I have noticed something else, when using clock_nanosleep, there is
>>>>>>> something wrong going on. Example output with clock_nanosleep:
>>>>>>>
>>>>>>> root@beaglebone:~# cyclictest    -p 99  -i 250 -n
>>>>>>> # /dev/cpu_dma_latency set to 0us
>>>>>>> policy: fifo: loadavg: 1.13 1.18 1.15 1/243 2385
>>>>>>>
>>>>>>> T: 0 ( 2384) P:99 I:250 C: 122168 Min:      0 Act:    9
>>>>>>> *Avg:2147483647*
>>>>>>> Max:      -1
>>>>>>>
>>>>>>> The Avg value jumps to this insane number.
>>>>>>> I didn't find any differences between the vanilla cyclictest and the
>>>>>>> xenomai-2.6 upstream cyclictest regarding the use of
>>>>>>> clock_nanosleep.
>>>>>>> Any ideas of where this behaviour would come from?
>>>>>> Which kernel and I-pipe release are you running?
>>>>>>
>>>
>>
> 
> 


-- 
Philippe.

[Xenomai] Cyclictest in Xenomai-3

[林展翔]

Hello,

I've cloned the code from Konstantinos's github page and amended the
Makefile and cyclictest.c like Philippe had suggested.

But when I ran cyclictest(after compilation) with the command './cyclictest
-p 99 -i 250 -n', the MAX latency was still over 200us.

Can anyone tell me where the problem might be?

Thanks!
Chan-Hsiang Lin

Re: [Xenomai] Cyclictest in Xenomai-3

[Philippe Gerum]

On 10/03/2015 11:35 AM, 林展翔 wrote:
> Hello,
> 
> I've cloned the code from Konstantinos's github page and amended the
> Makefile and cyclictest.c like Philippe had suggested.
> 
> But when I ran cyclictest(after compilation) with the command './cyclictest
> -p 99 -i 250 -n', the MAX latency was still over 200us.
> 
> Can anyone tell me where the problem might be?

Are you running the Cobalt core? Did you check the kernel log for its
signature.

Also, you may want to pull from the -next branch, where the original
cyclictest from the rt-tests is now available. There is no need for
patching that test anymore with the latest Cobalt code.

-- 
Philippe.

Re: [Xenomai] Cyclictest in Xenomai-3

[Philippe Gerum]

On 10/03/2015 11:35 AM, 林展翔 wrote:
> Hello,
> 
> I've cloned the code from Konstantinos's github page and amended the
> Makefile and cyclictest.c like Philippe had suggested.
> 
> But when I ran cyclictest(after compilation) with the command './cyclictest
> -p 99 -i 250 -n', the MAX latency was still over 200us.
> 
> Can anyone tell me where the problem might be?

A good way to check whether you actually fixed up the original code
properly with the earlier, out of tree cyclictest, is to run Xenomai's
latency test. Not seeing any latency issues with that one would give you
some hint about where the problem might be.

-- 
Philippe.

Re: [Xenomai] Cyclictest in Xenomai-3

[林展翔]

Thanks Philippe.

I've switched to the 'next' branch and tried to run cyclictest on
Beaglebone Black
(Also ran latency, the numbers were OK.)
The first time I ran cyclictest, there was a message saying that
non-SMP libraries was running on SMP kernel
But after recompiling xenomai with the '--enable-smp' option,
when I executed cyclictest (and latency), there were no messages printed
out (even errors)

Could this be the problem of the compiling process on Xenomai or the Linux
kernel ?
(My kernel version is 3.14.39)


Chan-Hsiang Lin


2015-10-03 17:46 GMT+08:00 Philippe Gerum <rpm@xenomai.org>:

> On 10/03/2015 11:35 AM, 林展翔 wrote:
> > Hello,
> >
> > I've cloned the code from Konstantinos's github page and amended the
> > Makefile and cyclictest.c like Philippe had suggested.
> >
> > But when I ran cyclictest(after compilation) with the command
> './cyclictest
> > -p 99 -i 250 -n', the MAX latency was still over 200us.
> >
> > Can anyone tell me where the problem might be?
>
> A good way to check whether you actually fixed up the original code
> properly with the earlier, out of tree cyclictest, is to run Xenomai's
> latency test. Not seeing any latency issues with that one would give you
> some hint about where the problem might be.
>
> --
> Philippe.
>

Re: [Xenomai] Cyclictest in Xenomai-3

[林展翔]

Sorry I forgot to mention that the successfully-executed latency was ran on
kernel 3.18,
before switching to the 'next' branch.

I also ran latency and cyclictest on Xenomai2, with my current linux kernel
version.
The numbers seemed to be fine.
(Max value around 30 us for both program, in a short period of time)

Chan-Hsiang Lin


2015-10-04 20:43 GMT+08:00 林展翔 <chlin6016@gmail.com>:

> Thanks Philippe.
>
> I've switched to the 'next' branch and tried to run cyclictest on
> Beaglebone Black
> (Also ran latency, the numbers were OK.)
> The first time I ran cyclictest, there was a message saying that
> non-SMP libraries was running on SMP kernel
> But after recompiling xenomai with the '--enable-smp' option,
> when I executed cyclictest (and latency), there were no messages printed
> out (even errors)
>
> Could this be the problem of the compiling process on Xenomai or the Linux
> kernel ?
> (My kernel version is 3.14.39)
>
>
> Chan-Hsiang Lin
>
>
> 2015-10-03 17:46 GMT+08:00 Philippe Gerum <rpm@xenomai.org>:
>
>> On 10/03/2015 11:35 AM, 林展翔 wrote:
>> > Hello,
>> >
>> > I've cloned the code from Konstantinos's github page and amended the
>> > Makefile and cyclictest.c like Philippe had suggested.
>> >
>> > But when I ran cyclictest(after compilation) with the command
>> './cyclictest
>> > -p 99 -i 250 -n', the MAX latency was still over 200us.
>> >
>> > Can anyone tell me where the problem might be?
>>
>> A good way to check whether you actually fixed up the original code
>> properly with the earlier, out of tree cyclictest, is to run Xenomai's
>> latency test. Not seeing any latency issues with that one would give you
>> some hint about where the problem might be.
>>
>> --
>> Philippe.
>>
>
>