Hello, I've asked a lot of questions here and gotten very prompt and helpful
responses, so I summarized them in a FAQ since I figure others may have
similar questions. See http://ericrebates.zzl.org/xen_faq.txt . If this
seems useful maybe someone can append them to the end of the wiki FAQ.
On another note, I have been comparing Xenomai's context switch latency to
GHS Integrity. I found that on average Xenomai seems to take three times as
long to context switch versus Integrity (12uS vs. 4uS) running almost
identical test code. Does anyone know why this may be or how to reduce this
latency in Xenomai? Since it appears Gilles helped implement the fast
context switching extension for the Linux kernel, I'm assuming Xenomai is
also taking advantage of this extension.
Below is the code I used in Xenomai to do the kernel context switch test.
This function is the entry point for two threads, one serving as the
producer and the other the consumer. I am using FIFO scheduling and the
consumer thread has higher priority than the sender. The Integrity code is
almost identical.
static void *ksemQTaskFcn(void *arg)
{
int ct;
kthreadctx_t *myCtx = (kthreadctx_t *)arg;
init_times(&myCtx->times);
/* Wait for real-time ioctl to broadcast start */
TM_CHECK_CALL(rt_sem_p(&mySem, TM_INFINITE));
for(ct = 0; ct < myCtx->loops; ct++) {
if (myCtx->mode) { // Sender...
globalStartTime = rtdm_clock_read_monotonic();
TM_CHECK_CALL(rt_sem_v(&mySem));
} else { // Receiver...
RTIME end_time;
TM_CHECK_CALL(rt_sem_p(&mySem, TM_INFINITE));
end_time = rtdm_clock_read_monotonic();
update_times(&myCtx->times, end_time - globalStartTime);
}
}
if (!myCtx->mode) {
myCtx->times.ave_time = slldiv(myCtx->times.ave_time, myCtx->loops);
pthread_exit(&myCtx->times); // Safe, myCtx is global
}
pthread_exit(NULL);
return(NULL); // Not reached.
}
As usual, thanks for any assistance.
- Eric
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
