Hi, I find the results interesting.
running your program under a MPC5200B, 396 MHz yields slightly better results: 3847 ns ~ 3,8 us. For the rt_sem_v() operation alone that is 1778 ns ~1,7 us ==> rt_sem_p(): 2069 ns ~2,1 us. Indeed for a ctx switch less operation this is a _very_ long time. It would be interesting to know how the figures are for kernel based operations. I have not measured mutexes so far, but it is probable that the figures are similar. If so, this is really something one should try to improve, because one has to "pay" a lot for the relatively unlikely event of a reschedule. And mutexes are and will/should be used a lot. I have to support Mathias here: it is not so easy as blaming bad design of the application or the used tooling. One often has dependencies on legacy code / tools / external libraries. Especially so in industrial environment, where standard protocols and interfaces are used, just think about a full featured CanOpen protocol stack for typically a couple of 1000 €. One simply cannot create a software "master plan" and fix all possible design flaws in those external dependent components. Especially not so in external binary only libraries. We are at the moment underway to find out the specifications of our Xenomai platform, i.e. max. ctx switch times, performance of the POSIX skin, etc. I will post the results and the source code if we are finished. Best regards, -- Daniel Schnell | [EMAIL PROTECTED] Hugbúnaðargerð | www.marel.com -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of M. Koehrer Sent: 10. maí 2007 08:31 To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [email protected] Subject: Re: [Xenomai-help] Xenomai and futexes - Native API optimized Hi Philippe, > > I'm not sure the cost is as much as 2 us, unless you don't use the > sysenter/sysexit protocol for syscalls Xenomai manages properly > (--enable-x86-sep). It seems you are going through the ancient 0x80 > exception vector, but still, I agree that the point remains: no > contention should mean no transition to kernel. > I did some measurements to get precise values here. For this I used the following Xenomai program that accesses a semaphore twice within a loop (p followed by v). --------------------------------- #include <native/task.h> #include <native/sem.h> RT_TASK taska_desc; RT_SEM sem; void mytaska(void *cookie) { int i; RTIME tim1, tim2; #define LOOPS 100000 tim1 = rt_timer_read(); for (i=0; i < LOOPS; i++) { rt_sem_p(&sem, TM_INFINITE); rt_sem_v(&sem); } tim2 = rt_timer_read(); printf("delta is %llu per step: %llu\n", tim2-tim1, (tim2-tim1)/ LOOPS); } int main(void) { mlockall(MCL_CURRENT|MCL_FUTURE); rt_sem_create(&sem, "mysem", 1 ,0); rt_task_create(&taska_desc, "mytaska", 0, 81, T_JOINABLE); rt_task_start(&taska_desc, &mytaska, NULL); rt_task_join(&taska_desc); rt_sem_delete(&sem); return 0; } ----------------------------- I measured the following runtime: For configuring Xenomai without any option: 4.8us per step Configuring Xenomai with --enable-x86-sep: 4.5us per step. I ran this experiment on a 3.2 GHz Pentium D on a server main board with E7230 chipset. Xenomai 2.3.1, kernel 2.6.20.4, SMP Thus the performance here is not really excellent (as there is no need to do a task switch. I agree with all the comments that recommended to improve the design first before trying to improve the OS performance. However, if there is (RT)OS, I expect it to be as fast as possible. Because, even if I have a "perfect" design, I need the OS - otherwise I would just live without the OS. A better design could help to reduce OS calls but it can not avoid it completely. Also, a lock less designs might lead to additional data copies which is also a known performance killer. So I think this is a decision that has to be made on base of the concrete project. General rules do not help here. Thanks for all comments! Regards Mathias -- Mathias Koehrer [EMAIL PROTECTED] Viel oder wenig? Schnell oder langsam? Unbegrenzt surfen + telefonieren ohne Zeit- und Volumenbegrenzung? DAS TOP ANGEBOT JETZT bei Arcor: günstig und schnell mit DSL - das All-Inclusive-Paket für clevere Doppel-Sparer, nur 39,85 € inkl. DSL- und ISDN-Grundgebühr! http://www.arcor.de/rd/emf-dsl-2 _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
