Re: [Xenomai-core] rt timer jitter
Krzysztof Błaszkowski wrote: Do you have any idea about reducing rt timer jitter ? I experience annoyingly big jitter in a thread which is supposed to run at 400us (i reckon this is nothing extra demanding from atom @1.6G) thread_task:2651 peak rt jitter -18470[ns], tsc delta 697450 I must say it is 4 - 5 times worse if compared to rtai 3.7 / 2.6.27.19 UP. I use now xenomai 2.5.4 with adeos 2.2-06 patch for same 2.6.27 kernel to make these comparisons more reliable. Can i do something with this ? Ok. I had read that you had 400us jitter, this would have been pathological. But 10us or 20us jitter on an ATOM is not. The jitter on an idle system is not really significant, only the worst case under several hours of heavy load is really significant. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] rt timer jitter
Do you have any idea about reducing rt timer jitter ?
I experience annoyingly big jitter in a thread which is supposed to run
at 400us (i reckon this is nothing extra demanding from atom @1.6G)
the thread's loop looks like:
{
function1()
..2()
..3()
..4()
rt_task_wait_period()
}
(^yet another simplified model^)
task is periodic while native skin works in aperiodic timer mode.
(periodic timer has horrible timings - it is apparently not rt timer).
rt_task_wait_period() always exists with 0 (no overruns) and also these
functions take no longer than 120usec (average is: 80 .. 90)
after task_wait_period() i read tsc (on atom it is constant and also any
frq adjusting is disabled)
and if compared to previous readout and converted to ns i got jitter in
range of 10usec .. -18usec. 10 usec means that wait_period exited
before given time point and -18usec means that it did it with 18usec
delay.
I noticed that UP configuration has sligthly less jitter.
a part of dmesg:
SGEN-lpc 0x148f: division factor 20 (700), tcks: 2, 15
sgen_fpga_init:736 [0]: acc (before rst ) test
sgen_fpga_init:742 c000
sgen_fpga_init:742 c000
sgen_fpga_init:742 c000
sgen_fpga_init:752 8000
thread_task:2651 peak rt jitter -710[ns], tsc delta 667850
SGEN-lpc :detected inputs failure. Mask 0x000c
MOTION: setting Traj cycle time to 40 nsecs
MOTION: setting Servo cycle time to 400 nsecs
thread_task:2651 peak rt jitter -3512[ns], tsc delta 672520
thread_task:2651 peak rt jitter 3694[ns], tsc delta 660510
thread_task:2651 peak rt jitter -4382[ns], tsc delta 673970
thread_task:2651 peak rt jitter 5146[ns], tsc delta 658090
thread_task:2651 peak rt jitter -5558[ns], tsc delta 675930
thread_task:2651 peak rt jitter 5626[ns], tsc delta 657290
thread_task:2651 peak rt jitter -5828[ns], tsc delta 676380
thread_task:2651 peak rt jitter 7264[ns], tsc delta 654560
thread_task:2651 peak rt jitter -7742[ns], tsc delta 679570
thread_task:2651 peak rt jitter -9626[ns], tsc delta 682710
thread_task:2651 peak rt jitter 10156[ns], tsc delta 649740
thread_task:2651 peak rt jitter -16262[ns], tsc delta 693770
SGEN-lpc [0] Fmax set to 285714Hz (18)
SGEN-lpc [1] Fmax set to 285714Hz (18)
SGEN-lpc [2] Fmax set to 285714Hz (15)
thread_task:2651 peak rt jitter -18470[ns], tsc delta 697450
I must say it is 4 - 5 times worse if compared to rtai 3.7 / 2.6.27.19
UP.
I use now xenomai 2.5.4 with adeos 2.2-06 patch for same 2.6.27 kernel
to make these comparisons more reliable.
Can i do something with this ?
Regards,
--
Krzysztof Blaszkowski
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] rt timer jitter
On Fri, 2010-08-20 at 18:01 +0200, Gilles Chanteperdrix wrote: Krzysztof Błaszkowski wrote: Can i do something with this ? Do you observe the same latencies with the latency test? this test does not produce reliable results except some hints. e.g. min. latency shifts about 1.5usec when i run on 2nd console dd if=/dev/urandom of=/dev/null bs=16k. as i recall max latency was more than 10 usec. -- Krzysztof Blaszkowski ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] rt timer jitter
On Fri, 2010-08-20 at 18:20 +0200, Krzysztof Błaszkowski wrote:
On Fri, 2010-08-20 at 18:06 +0200, Philippe Gerum wrote:
On Fri, 2010-08-20 at 17:55 +0200, Krzysztof Błaszkowski wrote:
Do you have any idea about reducing rt timer jitter ?
I experience annoyingly big jitter in a thread which is supposed to run
at 400us (i reckon this is nothing extra demanding from atom @1.6G)
the thread's loop looks like:
{
function1()
..2()
..3()
..4()
rt_task_wait_period()
}
(^yet another simplified model^)
This is the typical pattern of the latency test. What figures do you get
with:
# /usr/xenomai/bin/latency -t0
...
# /usr/xenomai/bin/latency -t1
t0:
RTS| -1.337| -0.039| 13.285| 0| 0|
00:02:13/00:02:13
Those are common figures for user-space latency on the kind of hw you
run this test on.
i can't run t1 because of missing seno_timerbench.ko (i have no idea how
to find a config option which would build it)
Did you consider using the Search feature from
xconfig/gconfig/whatever, looking for timerbench?
config XENO_DRIVERS_TIMERBENCH
depends on XENO_SKIN_RTDM
tristate Timer benchmark driver
default y
help
Kernel-based benchmark driver for timer latency evaluation.
See testsuite/latency for a possible front-end.
If you run your app in kernel space, then -t1 is what you want to run.
--
Philippe.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] rt timer jitter
On Fri, 2010-08-20 at 18:14 +0200, Krzysztof Błaszkowski wrote: On Fri, 2010-08-20 at 18:01 +0200, Gilles Chanteperdrix wrote: Krzysztof Błaszkowski wrote: Can i do something with this ? Do you observe the same latencies with the latency test? this test does not produce reliable results except some hints. e.g. min. latency shifts about 1.5usec when i run on 2nd console dd if=/dev/urandom of=/dev/null bs=16k. and? as i recall max latency was more than 10 usec. which is correct on your platform. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
