In light of the desire for support below, would the Xenomai team consider listing companies capable of commercial support on their website, or create another mailing list for us to announce commercial offerings around Xenomai. I am prepared to contribute to Xenomai in order to receive this privilege.  
Sorry for discussing commercial issues on your mailing list. If it makes it any better, we are a very small company, just trying to make a living, not a big corporate conglomerate.
As a final point, I believe Xenomai is very well positioned to become very popular and "future proof". I believe the next frontier for Linux is industrial grade Linux, or Linux on the factory floor and Xenomai will end up the technology of choice to make that happen. Contrary to many opinions I have heard, I beleve the rt-preempt work done by Ingo Molnar will enhance Xenomai and not replace it. I also think the break from RTAI was very smart as it has given you the flexibility to move Xenomai in the direction it needs to go. The recent releases have made Xenomai ready for the commercial world. So, kudos to the Xenomai team. You guys are proving to be great leaders with the right technology at the right time.
    Chris Stone.

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

Xenomai-core mailing list

Christopher Stone
Sombrio Systems Inc.
Xenomai-core mailing list

Reply via email to