* Re: [Xenomai-core] Fundamental Questions
2006-03-06 9:42 [Xenomai-core] Fundamental Questions Roderik_Wildenburg
@ 2006-03-06 13:02 ` Jan Kiszka
0 siblings, 0 replies; 2+ messages in thread
From: Jan Kiszka @ 2006-03-06 13:02 UTC (permalink / raw)
To: Roderik_Wildenburg; +Cc: xenomai
[-- Attachment #1: Type: text/plain, Size: 7473 bytes --]
Roderik_Wildenburg@domain.hid wrote:
> Dear Gurus,
>
> I have 2 fundamental questions and I appologize in advance to burden you with more answering jobs stealing your precious development time, but at least the first question is crutial to our project.
>
> 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. 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. This
gets better with PREEMPT_RT but still remains non-RT because the Linux
networking stack is not designed for hard real-time.
> (I have heard about RT-Net, but as far as I understand it needs its own realtime domain and therefore a gateway to communicate with the outside world. We want to avoid this.)
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.
>
> 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.
> 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.
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]
^ permalink raw reply [flat|nested] 2+ messages in thread