[Xenomai-help] RT timer help

[Xenomai-help] RT timer help

[Kim Chuan Lim]

Hi all,

I am a bit confuse with the rt timer clock tick.
printf("rt_timer_ns2tsc(1000000000) == %lld
\n",rt_timer_ns2tsc(1000000000));//1second
rt_timer_ns2tsc(1000000000) == 1193182;

rt_task_set_periodic(NULL, TM_NOW, 1193182LLu);
while (1) {
       rt_task_wait_period(NULL);
       /* real-time jobs */
	k_time = rt_timer_read();
	printf("Hello Jan!! count_%d k_time_%llu\n",++count,k_time);
   }

The printf appear very fast rather than 1ms.

May i know i have make what mistake?

Regards,
Kim Chuan.

Re: [Xenomai-help] RT timer help

[Gilles Chanteperdrix]

Kim Chuan Lim wrote:
 > Hi all,
 > 
 > I am a bit confuse with the rt timer clock tick.
 > printf("rt_timer_ns2tsc(1000000000) == %lld
 > \n",rt_timer_ns2tsc(1000000000));//1second
 > rt_timer_ns2tsc(1000000000) == 1193182;
 > 
 > rt_task_set_periodic(NULL, TM_NOW, 1193182LLu);

rt_task_set_periodic times are passed as count of system clock ticks,
not CPU clock ticks. So, you should be using rt_timer_ns2ticks.

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-help] RT timer help

[Kim Chuan Lim]

Hi Gilles,

Sorry for my stupid mistake.

i have changed my program to use rt_timer_ns2ticks(1000000000) but it
tooks approximate 10 seconds for each looping.

Console output:
Hello!! count_1 k_time_1152791787119305408
Hello!! count_2 k_time_1152791788119303732
Hello!! count_3 k_time_1152791789119302894
Hello!! count_4 k_time_1152791790119302894
Hello!! count_5 k_time_1152791791119302894
Hello!! count_6 k_time_1152791792119302894
Hello!! count_7 k_time_1152791793119303732
Hello!! count_8 k_time_1152791794119302894
Hello!! count_9 k_time_1152791795119302894

my program...
#include <signal.h>
#include <sys/mman.h>
#include <native/task.h>

int count=0;

void demo(void *arg)
{
   int err = rt_task_set_periodic(NULL, TM_NOW, rt_timer_ns2ticks(1000000000));
   RTIME k_time;
   while (count<10) {
       rt_task_wait_period(NULL);
       /* real-time jobs */
	k_time = rt_timer_read();
	printf("Hello!! count_%d k_time_%llu\n",++count,k_time);
   }
}

void catch_signal(int sig) {
	printf("In ::catch_signal(), sig == %d\n",sig);
}

int main(int argc, char* argv[])
{
   RT_TASK demo_task;
   signal(SIGINT, catch_signal);
   mlockall(MCL_CURRENT|MCL_FUTURE);
   rt_task_create(&demo_task, "mydemo", 0, 99, 0);
   rt_task_start(&demo_task, &demo, NULL);
   pause();
   rt_task_delete(&demo_task);
   return 0;
}

May i know is 1ns system clock time equal to 1ns real world time?

Regards,
Kim Chuan.

Re: [Xenomai-help] RT timer help

[Gilles Chanteperdrix]

Kim Chuan Lim wrote:
 > Hi Gilles,
 > 
 > Sorry for my stupid mistake.
 > 
 > i have changed my program to use rt_timer_ns2ticks(1000000000) but it
 > tooks approximate 10 seconds for each looping.

Does the latency test suffer from the same issue ?

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-help] RT timer help

[Kim Chuan Lim]

Hi Gilles,

> Does the latency test suffer from the same issue ?

I read the system time(rt_timer_read()) and the different is the same,
almost 1,000,000,000 different. But my program just took ~10seconds
for every update..

Regards,
Kim Chuan.

Re: [Xenomai-help] RT timer help

[Gilles Chanteperdrix]

Kim Chuan Lim wrote:
 > Hi Gilles,
 > 
 > > Does the latency test suffer from the same issue ?
 > 
 > I read the system time(rt_timer_read()) and the different is the same,
 > almost 1,000,000,000 different. But my program just took ~10seconds
 > for every update..

If latency suffers from the same issue, then your problem is in the
setup and I advise you once more to read the TROUBLESHOOTING
file. If latency does not suffer from the same issue, then you have made
a mistake in the code.

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-help] RT timer help

[Kim Chuan Lim]

Hi Gilles,

I am a bit confused with the defination of "latency suffer".
The following is the output of example program at /xenomai/testuites/latency.
Is 38.5ms average latency consider good?


== Sampling period: 100 us
== Test mode: periodic user-mode task
== All results in microseconds
warming up...
RTT|  00:00:01  (periodic user-mode task, 100 us period, priority 99)
RTH|-----lat min|-----lat avg|-----lat max|-overrun|----lat best|---lat worst
RTD|      37.714|      38.552|      41.066|       0|      37.714|      41.066
RTD|      37.714|      38.552|      48.609|       0|      37.714|      48.609
RTD|      37.714|      38.552|      47.771|       0|      37.714|      48.609
RTD|      37.714|      38.552|      47.771|       0|      37.714|      48.609
RTD|      37.714|      38.552|      72.076|       0|      37.714|      72.076
RTD|      37.714|      38.552|      46.933|       0|      37.714|      72.076
RTD|      37.714|      38.552|      46.933|       0|      37.714|      72.076
RTD|      37.714|      38.552|      47.771|       0|      37.714|      72.076
RTD|      37.714|      38.552|      47.771|       0|      37.714|      72.076
RTD|      37.714|      38.552|      47.771|       0|      37.714|      72.076
---|------------|------------|------------|--------|-------------------------
RTS|      37.714|      38.552|      72.076|       0|    00:00:10/00:00:10

Regards,
Kim Chuan.

On 7/13/06, Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> wrote:
> Kim Chuan Lim wrote:
>  > Hi Gilles,
>  >
>  > > Does the latency test suffer from the same issue ?
>  >
>  > I read the system time(rt_timer_read()) and the different is the same,
>  > almost 1,000,000,000 different. But my program just took ~10seconds
>  > for every update..
>
> If latency suffers from the same issue, then your problem is in the
> setup and I advise you once more to read the TROUBLESHOOTING
> file. If latency does not suffer from the same issue, then you have made
> a mistake in the code.
>
> --
>
>
>                                             Gilles Chanteperdrix.
>

Re: [Xenomai-help] RT timer help

[Gilles Chanteperdrix]

Kim Chuan Lim wrote:
 > Hi Gilles,
 > 
 > I am a bit confused with the defination of "latency suffer".

Do you see one line displayed every second, or one line every ten
seconds ?

 > The following is the output of example program at /xenomai/testuites/latency.
 > Is 38.5ms average latency consider good?

These are microseconds, not milliseconds. Whether it is good or not
depends on the platform.

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-help] RT timer help

[Gilles Chanteperdrix]

Kim Chuan Lim wrote:
 > Hi Gilles,
 > 
 > I print the result of rt_timer_read() for every output...
 > > Do you see one line displayed every second, or one line every ten
 > > seconds ?
 > 
 > The latency program...
 > display the line every second.
 > different between each rt_timer_read() is roughly the same(~1000000000).
 > 
 > my program...
 > display the line every 10 second.
 > different between each rt_timer_read() is roughly the same(~1000000000).
 > 
 > May i know if the different of time maintained by the system timer are
 > the same, why the output text displayed at different rate?

Your example runs fine here. Could you tell us more about your setup ?
What processor ? What configuration (are CONFIG_CPU_FREQ and
CONFIG_ACPI_PROCESSOR disabled and is hyper-threading enabled) ? Could
you send us your .config ? Is there any error message in the kernel logs
? 

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-help] RT timer help

[Kim Chuan Lim]

[-- Attachment #1: Type: text/plain, Size: 1476 bytes --]

dmesg..

I-pipe: Domain Xenomai registered.
Xenomai: hal/x86 started.
Xenomai: real-time nucleus v2.2-rc3 (Engines Of Creation) loaded.
Xenomai: SMI-enabled chipset found but SMI workaround not enabled (check
         CONFIG_XENO_HW_SMI_WORKAROUND). You may encounter high
         interrupt latencies!
Xenomai: starting native API services.
Xenomai: starting POSIX services.
Xenomai: starting RTDM services.

Pentium 4 3.2GHz with HT.
My current configuration only able to detect one CPU. :(
cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 15
model           : 2
model name      : Intel(R) Pentium(R) 4 CPU 3.20GHz
stepping        : 9
cpu MHz         : 3216.093
cache size      : 512 KB
physical id     : 0
siblings        : 1
core id         : 0
cpu cores       : 1
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe up
cid xtpr
bogomips        : 6440.74


zcat /proc/config.gz
I have disabled Power Management.

#
# Power management options (ACPI, APM)
#
# CONFIG_PM is not set

#
# ACPI (Advanced Configuration and Power Interface) Support
#
# CONFIG_ACPI is not set

#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set

Please find the attachment for my /proc/config.gz

[-- Attachment #2: config.gz --]
[-- Type: application/x-gzip, Size: 17950 bytes --]

Re: [Xenomai-help] RT timer help

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 2652 bytes --]

Kim Chuan Lim wrote:
> dmesg..
> 
> I-pipe: Domain Xenomai registered.
> Xenomai: hal/x86 started.
> Xenomai: real-time nucleus v2.2-rc3 (Engines Of Creation) loaded.
> Xenomai: SMI-enabled chipset found but SMI workaround not enabled (check
>         CONFIG_XENO_HW_SMI_WORKAROUND). You may encounter high
>         interrupt latencies!

Check the related configuration under Real-time sub-system -> Machine ->
SMI workaround. Switching it on is recommended (but shouldn't be the
reason for the strange timing - but who knows...).

> Xenomai: starting native API services.
> Xenomai: starting POSIX services.
> Xenomai: starting RTDM services.
> 
> Pentium 4 3.2GHz with HT.
> My current configuration only able to detect one CPU. :(

Again, HT is EVIL for real-time because it's only pseudo SMP. You cannot
reliably predict when central CPU resources are blocked by any of the
virtual CPUs. Thus, you may suffer from ugly priority inversions between
Linux running on one HT sub-core and Xenomai running on the other, but
both competing for shared resources.

> cat /proc/cpuinfo
> processor       : 0
> vendor_id       : GenuineIntel
> cpu family      : 15
> model           : 2
> model name      : Intel(R) Pentium(R) 4 CPU 3.20GHz
> stepping        : 9
> cpu MHz         : 3216.093
> cache size      : 512 KB
> physical id     : 0
> siblings        : 1
> core id         : 0
> cpu cores       : 1
> fdiv_bug        : no
> hlt_bug         : no
> f00f_bug        : no
> coma_bug        : no
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 2
> wp              : yes
> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
> mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe up
> cid xtpr
> bogomips        : 6440.74
> 
> 
> zcat /proc/config.gz
> I have disabled Power Management.
> 
> #
> # Power management options (ACPI, APM)
> #
> # CONFIG_PM is not set
> 
> #
> # ACPI (Advanced Configuration and Power Interface) Support
> #
> # CONFIG_ACPI is not set
> 
> #
> # CPU Frequency scaling
> #
> # CONFIG_CPU_FREQ is not set
> 
> Please find the attachment for my /proc/config.gz
> 

Some suggestions for tests:

 o switch on SMI workaround
 o switch off SMP, if that helps, re-enable but leave SCHED_SMT
   (hyperthreading) disabled
 o switch on ACPI, but leave ACPI_PROCESSOR off

Jan


PS: CONFIG_XENO_OPT_TIMING_PERIODIC is not required unless you really
base your timing on a periodically ticking timer instead of the default
one-shot high-resolution mode. Otherwise this switch only adds overhead.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-help] RT timer help

[Kim Chuan Lim]

Hi All,

Thanks Jan.
Looks like i have solved my problem by enabling ACPI(ACPI_PROCESSOR
off), switch on SMI workaround and switch off SMP.

I am too lazy to re-enabled SMP now. Maybe will try it out during this weekend.

The result of the latency testsuite has improved(~0.1us).

Regards,
Kim Chuan.



On 7/14/06, Jan Kiszka <jan.kiszka@domain.hid> wrote:
> Kim Chuan Lim wrote:
> > dmesg..
> >
> > I-pipe: Domain Xenomai registered.
> > Xenomai: hal/x86 started.
> > Xenomai: real-time nucleus v2.2-rc3 (Engines Of Creation) loaded.
> > Xenomai: SMI-enabled chipset found but SMI workaround not enabled (check
> >         CONFIG_XENO_HW_SMI_WORKAROUND). You may encounter high
> >         interrupt latencies!
>
> Check the related configuration under Real-time sub-system -> Machine ->
> SMI workaround. Switching it on is recommended (but shouldn't be the
> reason for the strange timing - but who knows...).
>
> > Xenomai: starting native API services.
> > Xenomai: starting POSIX services.
> > Xenomai: starting RTDM services.
> >
> > Pentium 4 3.2GHz with HT.
> > My current configuration only able to detect one CPU. :(
>
> Again, HT is EVIL for real-time because it's only pseudo SMP. You cannot
> reliably predict when central CPU resources are blocked by any of the
> virtual CPUs. Thus, you may suffer from ugly priority inversions between
> Linux running on one HT sub-core and Xenomai running on the other, but
> both competing for shared resources.
>
> > cat /proc/cpuinfo
> > processor       : 0
> > vendor_id       : GenuineIntel
> > cpu family      : 15
> > model           : 2
> > model name      : Intel(R) Pentium(R) 4 CPU 3.20GHz
> > stepping        : 9
> > cpu MHz         : 3216.093
> > cache size      : 512 KB
> > physical id     : 0
> > siblings        : 1
> > core id         : 0
> > cpu cores       : 1
> > fdiv_bug        : no
> > hlt_bug         : no
> > f00f_bug        : no
> > coma_bug        : no
> > fpu             : yes
> > fpu_exception   : yes
> > cpuid level     : 2
> > wp              : yes
> > flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
> > mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe up
> > cid xtpr
> > bogomips        : 6440.74
> >
> >
> > zcat /proc/config.gz
> > I have disabled Power Management.
> >
> > #
> > # Power management options (ACPI, APM)
> > #
> > # CONFIG_PM is not set
> >
> > #
> > # ACPI (Advanced Configuration and Power Interface) Support
> > #
> > # CONFIG_ACPI is not set
> >
> > #
> > # CPU Frequency scaling
> > #
> > # CONFIG_CPU_FREQ is not set
> >
> > Please find the attachment for my /proc/config.gz
> >
>
> Some suggestions for tests:
>
>  o switch on SMI workaround
>  o switch off SMP, if that helps, re-enable but leave SCHED_SMT
>    (hyperthreading) disabled
>  o switch on ACPI, but leave ACPI_PROCESSOR off
>
> Jan
>
>
> PS: CONFIG_XENO_OPT_TIMING_PERIODIC is not required unless you really
> base your timing on a periodically ticking timer instead of the default
> one-shot high-resolution mode. Otherwise this switch only adds overhead.
>
>
>
>
>