Dear Jan, thank you for taking time to answer my questions and sorry for the delayed response, but I have been busy with some other work. Please find my follow-up questions inserted in the text.
> > > > 1.) > > Essentially the question deals with the problem, how long a > Xenomai task in secondary mode can be delayed by normal Linux tasks. > > In detail : we plan to to have a lot of "near realtime" > ethernet communication from within Xenomai using the normal > Linux network stack (calling the normal socket API). The > question now is, how our network communication is influenced > by other Linux tasks performing also network communication, > let´s say an FTP transfer ? > > Depending on the "normal" networking load, you will suffer > from more or less frequent (indeterministic) packet delays. Do you have an idea about the dimension weare talking about : less than a millisecond, few milliseconds, seconds, or is the delay complete indeterministic ? > Xenomai will not improve this in any way. If your task in > secondary mode tries to send some data and requires to take a > networking lock currently held by another Linux task, it can > take a real long time until this request is completed. But at least, after a (linux-)systemcall (from what task ever) finished, Xenomai gets controll back before any other linux task, isn´t it ? This means : between systemcalls a rescheduling back to Xenomai is performed or isn´t it ?? Sorry for the next stupid question, but what is a network lock. With what kind of action a task can lock the complete stack ? And how long could it block the stack ? Could you give me an example for better understanding ? > This > gets better with PREEMPT_RT but still remains non-RT because > the Linux networking stack is not designed for hard real-time. > Next stupid question : what is PREEMPT_RT ? Is this kernel 2.6 or is it the Monta Vista approach for real time (making the kernel more preemtable) ? > > If you communication can be soft-RT, you could indeed avoid > the separation - but you will then have to live with the side > effects. All you can do then is try to lower the number of > deadline misses by keeping the standard network traffic low > and managing the bandwidth of the participants (the Linux > network stack has some support for QoS, at least > 2.6 I think). > > BTW, as long as your network is not separated or you have no > control over the traffic arriving at your system, picking the > Linux stack in favour of RTnet (which is compatible with > non-RT networks) is indeed generally recommended. This way > you keep indeterministic load away from the real-time subsystem. > Unfortunatelly we don´t want to limit non realtime traffic, we just want to make shure, that deterministic traffic has a higher priority than non RT traffic (like in other RTOS like vxWorks). Indeterministic traffic should get just the leftover bandwith. What do you mean with : "Rtnet is compatible with non-RT networks" ? I thought RTnet uses a time slice mechanism and therefore could not be mixed with systems transmitting when ever they want. Do you refer to VNICs ? > > > > I have created a scheduling scenario and I would ask you to > have a look on it and to tell me whether it is correct or > not. Thank you ! > > An corresponding question about this scheduling is : are there > > differences between a 2.4 and 2.6 Linux kernel ? (for our PowerPC > > plattform we intend to use the 2.4 kernel for performance reasons) > > > > Scheduling scenario : > > (I hope formating is not destroyed by email transfer) > > > > Time moves downwards > > > > v-Xenomai > > v-Linux kernel > > v-Linux processes > > > > l1 Linux task1 running > > s1 < l1 Linux task1 makes systemcall > > s1 Linux task1 systemcall processed > > ------------- Linux scheduling > > l2 Linux task2 starts to run > > s2 < l2 Linux task2 makes systemcall > > s2 Linux task2 systemcall processed > > +++++++++++++ Xenomai scheduling > > x3 Xenomai task3 starts to run => primary mode > > x3 > s3 Xenomai task3 makes systemcall => secondary mode > > s3 Xenomai task3 systemcall processed > > ------------- Linux scheduling => Xenomai task preemted > > This preemption will only happen if the target Linux task has > a higher priority or the Xenomai task on secondary mode has > to block on some resource to be become free. As I sketched > above, this can actually happen in the network stack. What do you mean with "higher priority" ? I thought Xenomai has a higher priority than anything else in the linux system. Could you give mean example about the resource (related to network communication) s3 could wait for ? > > > s1 Linux task1 systemcall processed > > s1 > l1 Linux task1 systemcall ready => Linux task1 > continues > > l1 Linux task1 continues > > ------------- Linux scheduling > > s2 Linux task2 systemcall processed > > s2 > l2 Linux task2 systemcall ready => Linux task2 > continues > > l2 Linux task2 continues > > ------------- Linux scheduling => Xenomai Task3 systemcall > continued > > s3 Xenomai Task3 systemcall continued > > x3 < s3 Xenomai Task3 systemcall ready => Xenomai > Task contiunes > > x3 but has been delayed by normal Linux tasks > > > > > > 2.) > > This question is not so crucial, but nevertheless interesting : > > Who are the people behind Xenomai (I did not find anything > about this on the Xenomai webpage), what is their background > (University, Company)and who impels /sponsors the Xenomai > development (University, Company, Community)? > > I think I "identified" at least 2 core developers : > Philippe Gerum and Gilles Chanteperdrix, but I don´t know > very much more. > > I can add my/our own profile here: working at the university > of Hannover (Real-Time Systems Group) with and on Xenomai to > use it on mobile service robots and to do research on > real-time security and industrial automation. Our institute > is currently developing a larger robotic software framework > on top of it. Primarily, we see Xenomai as a mature platform > for doing real-time with Linux, i.e. as a very useful tool. > > > The background for this question is, to get a feeling, how > future-proof the xenomai development is. As far as I can see > open source projects often die or stall when the initiators > decide that "growing flowers" is a much more pleasant job ;-). > > > > We had to decide last year which way to go for our future > platforms, also with potential industrial/commercial usage in > mind (e.g. > proprietary real-time algorithms as user-space applications). > Based on our experience with the RTAI (> 4 years), my own > insight into RTAI/fusion (Xenomai predecessor), and the > status of PREEMPT_RT, we selected fusion (now Xenomai) as the > most matured and future-proven one. > > Xenomai is enjoying an increasing acceptance in industry. Our > industry partners e.g. are either planning to start new with > Xenomai or port over from other RT-extensions - of course > encouraged by our own good experience. I talked to a lot of > smaller and real large companies over the last months, > specifically here in Germany, that started new > automation/embedded projects on top of Linux/Xenomai (as > usual, most of their activities remain non-public - > unfortunately). They are convinced of the future of this project. > > Moreover, I believe that Xenomai has a very healthy > community. We have a quite active crowd of contributors and > "plain" users. There is definitely more than one person > knowing the internals of the system (as in many projects, > there is still one person knowing them best...). And the code > is also well documented (exceptions apart). > > No one can safely predict what will happen to a project when > one of the main contributors stops working on it. But given > the number of "advanced" Xenomai users already at this > comparably early project stage, I'm convinced it would even > survive such an exceptional scenario, i.e. > it has reached a critical mass. But I have no indications > that Philippe or Gilles will become gardeners. ;) > > This said, the best thing one can do as a long-term user of > an open source project is to support its development actively by > > o promoting it (yes, it can already be that simple) o > reporting problems o fixing minor bugs and posting the fixes > o contributing new features and enhancements (drivers, board support, > API extensions, ...) > o or directly funding the development of such enhancements > > > > > Thank you for taking time to answer these questions, which > are interesting to others too, I think !? > > > > Hope I was able to provide you some helpful details and arguments. > Yes, you did ! Thank you very much ! Things you said about the interest of larger companies, the widespread knowledgement and code maturity sounds quite good to me. Form your mentioning of "industrial partners" I conclude you are working with or for companies also, not just for your universty. So i would like to know whether you also offer external consultations ? Just in case, we want to make shure that things, we plan to do are possible with Xenomai. Best Regards Roderik _______________________________________________ Xenomai-core mailing list Xenomaiemail@example.com https://mail.gna.org/listinfo/xenomai-core