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 p
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
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 sti
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 sti
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 prob
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 microseco
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,
Konstanti
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 innocuo
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, Konstantino
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.
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! Th
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
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:
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
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=
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
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
17 matches
Mail list logo
