Chuck,
> originally I was running 2.2.14-2.2, I've now updated to
> 2.4.0.test1-3.0pre7. My guess is that you, Steve, are using
> the same (or a nearly related kernel).
I am using 2.4.0-test1-3.0pre7.
> You sent me the
> following output
>
> > Delay of 320ns near 0ms
>
> (Doesn't that maximum at 0ms look suspicious?)
I simply assumed that on a properly functioning system all of the
delays were the same. Now that I try it on my system, I see that the
periodic thread seems to be rather aperiodic. :-(
> With the new kernel, I get the same output, but due to a
> second bug. For some reason, with the new kernel, the
> periodic thread is only running through once. ie.
> after pthread_wait_np(), the thread never reactivates.
> Throw another printk in just after the while(1){, and observe.
Whatever you do, do not get into the habit of using printk in RTL
code. You may get away with it *sometimes*, but it WILL come back to bite
you later. Trust me on this, I know... printk is, of course, OK in the
init_module and cleanup_module routines.
I observed the problem you reported here by adding a rtl_printf just
after the while. :-)
> Does anyone know what might be going wrong? Did the details
> of periodicity changes from 2.2 to 2.4? Should I back
> down to 2.2.19-rt-3.0?
I can not provide you with many details of the issue right now, but
I am sure that Michael B. can. I can, however, tell you how to fix the
problem. Simply replace your use of "clock_gethrtime(CLOCK_REALTIME)" with
a simple call to
"gethrtime()" when calculating the value for "soon". The clock_gethrtime
call includes a delta offset that is set at {insert Michael Bs wisdom here}
time. Apparently that delta is not taken out, as would be necessary for
this to work as you expected, from the pthread_make_periodic_np routine (or
the scheduler... Michael?). This may or may not be a bug, we will have to
see what the guys at FSM labs have to say about it.
Please also note that you can use a simple call to gethrtime() in
your periodic thread. This will remove the spinlock checking on the
clock_gethrtime calls that is probably responsible for most of your delay.
On my machine, before I made the change to a simple gethrtime() call (in the
periodic task) I got:
Delay of 384ns near 0ms
Delay of 544ns near 27ms
Delay of 576ns near 3456ms
Delay of 608ns near 28972ms
Delay of 640ns near 43328ms
Delay of 704ns near 60545ms
Delay of 768ns near 200830ms
Delay of 960ns near 263810ms
After switching to the simple gethrtime() (and thus removing some
spinlock protection, which I believe is only needed for RTL kernel
internals), I got:
Delay of 160ns near 0ms
Delay of 192ns near 1133ms
You can decide which is better, but *I* know which *I* prefer. :-)
> -Chuck: who now has two problems where he once had one! :)
Hopefully that number will be down to zero soon.
Steve
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
