ROSSIER Daniel wrote: >> -----Original Message----- >> From: Gilles Chanteperdrix [mailto:[EMAIL PROTECTED] >> Sent: mercredi 31 octobre 2007 20:22 >> To: ROSSIER Daniel >> Cc: MEYLAN Jean-philippe; [email protected] >> Subject: Re: [Xenomai-help] task rate control with alarm and semaphore >> >> ROSSIER Daniel wrote: >>>> -----Original Message----- >>>> From: [EMAIL PROTECTED] >>> [mailto:[EMAIL PROTECTED] >>>> On Behalf Of MEYLAN Jean-philippe >>>> Sent: mercredi 31 octobre 2007 11:46 >>>> To: [email protected] >>>> Subject: [Xenomai-help] task rate control with alarm and semaphore >>>> >>>> Hello, >>>> >>>> I'm working on the creation of a Xenomai target for Mathwork's >>>> Real Time Workshop. In order to achieve this, I would like to >>>> control the execution rate of a task with a semaphore periodically >>>> released by an alarm handler. The tasks does nothing else but >> waiting >>>> (in a loop) on the semaphore. If the task can immediately take >>>> the sempahore, it means that the rate is too fast for it because >>>> the semaphore has been released before the end of its current >>> iteration. >>>> My problem is that I cannot decrease the alarm period under 40us >>>> without facing this situation. I cannot figure what is the cause of >>>> all that overhead (maybe it comes from the rt_alarm_wait call ?). I >>>> have tried to use event flags instead of semaphores but I get the >>>> same results. >>>> >>>> Do you have any idea ? >>>> >>>> Here is the code of the main task and the alarm handler: >>>> >>>> void tBaseRate(void * cookie) >>>> { >>>> while (1) { >>>> if (rt_sem_p(&rtClockSem, TM_NONBLOCK) == 0) { >>>> printf("Rate for BaseRate task too fast.\n"); >>>> } else { >>>> rt_sem_p(&rtClockSem, TM_INFINITE); >>>> } >>>> } >>>> >>>> void clockHandler(void * cookie) >>>> { >>>> int status; >>>> while (1) { >>>> status = rt_alarm_wait(&clockDesc); >>>> if (!status) { >>>> status = rt_sem_v(&rtClockSem); >>>> if (status) >>>> printf ("Semaphore error : %d\n", status); >>>> } else >>>> printf ("Alarm error: %d\n", status); >>>> } >>>> } >>> This example is very interesting. To make sense, the semaphore must >> be >>> initialized to 0 so that >>> the first invokation to rt_sem_p() in tBaseRate will suspend the >> task. >>> But if the message >>> "Rate for BaseRate task too fast" is displayed the next loop, it >> means >>> that the time elapsed between >>> the alarm and the next rt_sem_p() is more than 40us. Weird. Having a >> IRQ >>> latency of about 5us, it means >>> that the nucleus spend 35us to handle the switch between the alarm >> and >>> the task itself. >> The interrupt latency is one thing, here you have two context switches >> after the interrupt, which basically means that the latency is at least >> twice the _scheduling_ latency. >> > > Thanks Gilles; for You, does the scheduling latency seem to be honest > (something like 17-18us) ? > (I know that this scheme could be simpler with a periodic task, but the > goal here is to perform > a comparison between Xenomai and RTOS-32, therefore we try to keep the > same conditions; so far, > RTOS-32 supports an alarm rated at 10us). >
Well, adding useless overhead to the Xenomai testcase just because RTOS-32 has no rt_wait_period()-alike feature, gets fairness out of the picture. i.e. from userland, a native alarm object involves one task more, the related task switches and additional syscalls at each tick. The fact that RTOS-32 does not implement a straightforward way to schedule tasks on a precise periodic timeline should not be charged to Xenomai when benchmarking. If I'm right, maybe you should try to find another benchmark scenario, which would allow to use common features from those two kernels, rather than sub-optimally emulating those for one of them. If the point is to compare the accuracy of two cyclic tasks scheduled by the timer interrupt, then the RTOS-32 demo below shows a pattern which is easy to emulate properly using the native API (i.e. rt_timer_tsc + rt_task_sleep_until): http://www.on-time.com/rtos-32-docs/rtkernel-32/programming-manual/advanced-topics/cyclic-task.htm This said, this pattern would still be sub-optimal compared to rt_task_set_periodic/rt_task_wait_period. -- Philippe. _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
