rtems_clock_tick execution time

[Joel Sherrill]

Manuel Pedro Coutinho wrote:
> Hi
>
> I've been studying RTEMS, in particular the clock manager and I have a 
> question relating to the amount of time that the rtems_clock_tick function 
> takes.(I hope this question isn't already placed but I couldn't find it)
>
> In the processor family (i386, SPARC, etc) RTEMS supplement manuals it is 
> refered that this function takes at maximum a given time.
>
>   
I hope it doesn't actually say that. The times reported by the tmtests 
and reported
in those documents are for specific cases -- some are worst case, some 
are specific
examples of O(n) services.  For example, broadcasting a message is O(n) 
dependent
on the number of blocked threads.  Check out the last paragraph at this 
link:

http://www.rtems.com/onlinedocs/releases/rtemsdocs-4.6.6/share/rtems/html/supplements/sparc/sparc00054.html

I think it is pretty clear in saying servicing a clock tick is O(n).

FWIW the times and sizes in the supplements were hard to keep up to date 
and
in 4.7 have been removed.  If you want to know sizes, compile it.  If 
you want to
know times, check the BSP's times file, run the tests yourself, or ask 
on the list for
someone's results (which should be added to the BSP's times file :).  In 
addition,
all supplements were merged into a single manual since they were largely 
boilerplate
text.  Eventually the duplication between CPUs will be removed.
> But when I see the code for this particular function, some questions arise 
> in the _watchdog_tickle function... it does a do-while cicle for all nodes 
> on the chain that migth have became "active" during that clock tick.
>
> My question is: in the worst case scenario, all the application tasks can 
> became active in a clock tick so, how can the complexity of this algorithm 
> not be dependent on the number of application tasks (or another object)? And 
> since the number of application tasks is variable, I think there is no way 
> to say that this function takes a maximum of XXX useconds...
>
>   
You are correct.  It is O(n) dependent on the number of timers firing.
> I don't claim to be right about this, it is just a question. I might have 
> wrongly interpreted the code.
> Anyway, I have thought about this and if I am right, I can't think of a 
> solution to make the complexity object independent (if one makes this easier 
> in this step, it makes it harder on another)
>
>   
You interpreted the code correctly but may have missed something in the 
documentation.
> Hope I made myself understand (my english is rubish) ;)
>
>   
Not the worst ever seen on this list. It isn't bad. :-)
> Best regards
> Manuel Coutinho
>
> _________________________________________________________________
> MSN Busca: fácil, rápido, direto ao ponto.  http://search.msn.com.br
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.com
> http://rtems.rtems.org/mailman/listinfo/rtems-users
>