Time

A: It is a long long. You will not need to worry about it in your lifetime.

Q: Using the following code I get all sorts of wrap around... what am I doing wrong?

 now = rt_get_time_time();
 printk("reporting %ld\n",count2nano(now));

A: You need a "%lld" format string becayse rt_get_time and count2nano operate on long long's, and printk is operating on a long, so you are casting into a variable that is about 4 billions times smaller.

Q: I still get wrap around even though I use the "%lld" format string?

A:

void printTime(){
  unsigned long nanoSeconds,seconds,minutes,hours;
  unsigned long long ll;
  ll = ulldiv(ulldiv(ulldiv(ulldiv(rt_get_time_ns(),1000000000,&nanoSeconds),60,&seconds),60,&minutes),60,&hours);
  printk("HRS:MIN:SEC.nanos %ld:%02ld:%02ld.%ld\n",hours,minutes,seconds,nanoSeconds);
}

Q: When I create a periodic task with period nano2count(100000) and then have the task print the times it runs in nanos I find I'm getting a 99733 nano interval(give or take a couple of nanos) pretty consistently.

What is the cause of this difference between requested and actual period and how can I calculate it before hand?

Each time I insmod rtai_sched_up it gives a slightly calibrated cpu frequency, will this affect the above?

A:

A: init_module() runs in a plain LINUX context. Calling rt_sleep() on behalf of the Linux context will not suspend the caller but will (spuriously) attempt to register the alarm then return immediately. This is all due to the fact that blocking RT services cannot be used on behalf of the Linux pseudo-task, since the Linux context is some kind of idle task for the RTAI sched (i.e. is considered to be always ready to run).

Use schedule_timeout() for plain Linux alarms. rt_sleep() must be called on behalf of a RT task only.