FW: Accuracy of rtems_timer_server_fire_after

[Mogens Dybæk Christensen]

Hello Sebastian

At first I set the timer server priority to 5. I then tried to give it priority 1 (apparently the highest possible, 0 is not allowed). It changes nothing. 

At least the first shot with rtems_timer_server_fire_after is very slow. - Have no measurements yet for the following ones, but I can add more test code.

As mentioned before, delays made with rtems_task_wake_after are more accurate. 

It seems that the main loop in the timer server itself uses a timer to wait before next check/action, but I did not understand it all at first glance.  :-)
 The server code is in  rtems/cpukit/rtems/src/timerserver.c. How fast (and accurate) is the timer server intended to be, and can the prescaling from clock tick to server invocation be changed?

Kind regards
Mogens


> -----Original Message-----
> From: rtems-users-bounces at rtems.org [mailto:rtems-users-
> bounces at rtems.org] On Behalf Of Sebastian Huber
> Sent: 4. juli 2012 13:39
> To: rtems-users at rtems.org
> Subject: Re: FW: Accuracy of rtems_timer_server_fire_after
> 
> Hello Mogens,
> 
> On 07/04/2012 11:38 AM, Mogens Dybæk Christensen wrote:
> > Hi
> >
> > Does the server task behind these delays run at clock tick speed, or
> is the
> > timing scaled down?
> 
> the timer server task is triggered by the system clock interrupt.
> 
> [...]
> 
> 
> > The system tick is 1 mS, but if (as an extreme test)
> > rtems_timer_server_fire_after is fed with a 1 tick delay, the
> callback routine
> > is called after approx. 29 mS!
> 
> This should not happen provided the timer server task execution is not
> delayed.
>   Is it really the highest priority task at this moment?  Are some
> running
> tasks non-preemptible?
> 
> [...]
> 
> --
> Sebastian Huber, embedded brains GmbH
> 
> Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
> Phone   : +49 89 18 90 80 79-6
> Fax     : +49 89 18 90 80 79-9
> E-Mail  : sebastian.huber at embedded-brains.de
> PGP     : Public key available on request.
> 
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users