BOUNCE rtl@rtlinux.org: Approval required: Non-member submissionfrom [Erwin Rol <Erwin.Rol@q-soft-engineering.com>] (fwd)

[Der Herr Hofrat <der.herr@hofr.at>]

>From owner-rtl Tue May 15 08:40:59 2001
Received: from inc-mail.netline.de ([195.88.128.39])
	by hq.fsmlabs.com (8.11.2/8.11.2) with SMTP id f4FEew508345
	for <rtl@rtlinux.org>; Tue, 15 May 2001 08:40:59 -0600
Received: from pD95029C4.dip.t-dialin.net (pD95029C4.dip.t-dialin.net [217.80.41.196]) by inc-mail.q-soft-engineering.com (NTMail 3.03.0018/1.amj3) with ESMTP id ka400540 for <rtl@rtlinux.org>; Tue, 15 May 2001 16:36:05 +0100
Received: from q-soft-engineering.com (erwin [192.168.10.21])
	by Q-Soft-Engineering.com (8.9.3/8.9.3) with ESMTP id QAA05366;
	Tue, 15 May 2001 16:43:14 +0200
Message-ID: <3B013F86.5614A9C5@q-soft-engineering.com>
Date: Tue, 15 May 2001 16:39:02 +0200
From: Erwin Rol <Erwin.Rol@q-soft-engineering.com>
Reply-To: Erwin.Rol@q-soft-engineering.com
Organization: Q-SOFT Engineering GmbH
X-Mailer: Mozilla 4.74 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: =?iso-8859-2?Q?S=E9bastien?= GAUME <sgaume@b2i-toulouse.com>
CC: realtime@realtimelinux.org, rtl@rtlinux.org,
   Paolo Mantegazza <mantegazza@aero.polimi.it>
Subject: Re: [realtime] Wrong calibration ?
References: <3B0126B5.22832ADD@b2i-toulouse.com>
Content-Type: text/plain; charset=iso-8859-2
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by hq.fsmlabs.com id f4FEex508346

I had the same problem when i tried to convert the latency 
test example to C++. I thought to be smart and use nano seconds 
everywhere this resulted in increasing latency. As far as
i can tell is it due to rounding errors when converting from
ticks to nanoseconds and back. I advice you to try the original 
latency_calibration example and see if it happens there too.

- Erwin



Sebastien GAUME wrote:
> 
> Hello,
> 
> I'm doing basic tests with a periodic task : I'm measuring when the task
> really wakes up which enables me to know much more about the jitter.
> 
> I sometimes obtain excellent results (the jitter value is about 1 us)
> but  I sometimes come across quite surprising results. By surprising
> results, I mean that the jitter is increasing more and more ; for
> instance, after 30 s, the jitter is about 100 us !
> 
> These problems occure on the two PCs I am using : one is a P166 MMX with
> 96M Ram, the other is a PII 350 with 64M Ram. On both PC, I am using
> RTAI 1.6 with linux kernel 2.2.17.
> 
> I first thought the trouble was coming from the CPU frequency. That's
> why I used your CPU frequency calibration. Unfortunately, the results
> became as bad as the earlier were, and even worse sometimes.
> 
> The latency calibration was realized on both PC, but it did not change
> anything. I even tried to realize the latency calibration offered by
> RTAI 24.1.4. but the results go on being either excellent either bad.
> 
> I provide you the test code. So, if you have any idea of where the
> problem comes from, do not hesitate e-mailing me. Thank you.
> 
> Sebastien
> 
> #include <linux/module.h>
> #include <asm/io.h>
> 
> #include <rtai.h>
> #include <rtai_fifos.h>
> #include <rtai_sched.h>
> 
> #define TICK_PERIOD 1000000
> 
> #define STACK_SIZE 4000
> 
> #define LOAD 16550
> 
> RT_TASK tache_periodique[1];
> 
> RTIME now, tick_period;
> 
> struct donnees_
> {
> int tache;   // id tache
> int passage;  // nombre de passages
> long long temps; // temps entre 2 passages
> long long duree; // duree de la tache
> };
> 
> void periodic_task(int id_tache)
> {
> int compteur, cpt_load;
> long long time_cpu, intermediate_time_cpu, end_time, task_duration;
> struct donnees_ donnees;
> 
> // recopie id de la tache
> donnees.tache = id_tache;
> 
> // initialisation compteur nb de reveils de la tache
> compteur = 0;
> 
> while(1)
> {
> // recuperation date de reveil de la tache
> intermediate_time_cpu = rt_get_cpu_time_ns();
> 
> // calcul de la date de reveil en partant de la date de lancement de
> l'application
> time_cpu = intermediate_time_cpu - count2nano(now);
> 
>  // recopie des donnes concernant la tache dans la structure donnees
>  donnees.passage = compteur;
>  donnees.temps = time_cpu;
> 
>  // chargement du cpu
>  rt_busy_sleep(200000);
> 
>  // recuperation date de fin de la tache
>  end_time = rt_get_cpu_time_ns();
> 
>  // calcul de la duree de la tache
>  task_duration = end_time - intermediate_time_cpu;
> 
>  // recopie de la duree de la tache dans
>  donnees.duree = task_duration;
> 
>  // envoi de la structure donnees (par fifo) // tous les 500 passages
>  if (compteur % 500 == 0)
>   {
>   if (rtf_put(0, &donnees, sizeof(donnees)) < sizeof(donnees))
>    {
>    rt_printk("impossible d'ecrire dans la fifo \n");
>    rt_task_suspend(&tache_periodique[id_tache]);
>    }
>   }
> 
>  // on incremente le compteur nb de reveils de la tache
>  compteur++;
> 
>  //attente prochaine periode de reveil
>  rt_task_wait_period();
>  }
> }
> 
> int init_module(void)
> {
> //creation de la fifo
> rtf_create(0, 100000);
> 
> // initialisation des taches
> rt_task_init(&tache_periodique[0], periodic_task, 0, STACK_SIZE, 5, 0,
> 0);
> 
> // definition du mode (oneshot)
> rt_set_oneshot_mode();
> 
> // lancement du timer
> tick_period = start_rt_timer(nano2count(TICK_PERIOD));
> 
> // recuperation de la date actuelle
> now = rt_get_time();
> 
> rt_printk("now %d \n", count2nano(now));
> 
> // lancement de la tache periodique
> rt_task_make_periodic(&tache_periodique[0], now+nano2count(500000),
> nano2count(700000));
> 
> return 0;
> }
> 
> void cleanup_module(void)
> {
> // arret du timer
> stop_rt_timer();
> 
> // destruction de la fifo
> rtf_destroy(0);
> 
> // destruction des taches
> rt_task_delete(&tache_periodique[0]);
> 
> printk("Et c'est fini !!!!!!!!\n\n");
> }