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
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Reply via email to