Re: [microblaze-uclinux] Implementing FAT on uCLinux

[Alejandro Lucero <alucero@xxxxxxxxx>]

Hi Falk,

It's necessary to make the difference between RTLinux and real time Linux 
patches. 

RTLinux is a microkernel which virtualizes interrupts to Linux. This 
virtualization is hiden to Linux and from the RTLinux microkernel 
perspective, Linux, as a whole,  runs as the lowest real time task. The 
strength of this combo is you can use a "hard" real time microkernel and a 
GPOS(General Purpose OS) such as Linux in the same machine, and you can do 
whatever you need in the Linux part. Of course, depending on the processor 
performace and the real time work done, Linux will suffer some delays. Also, 
you can send data from RT tasks to Linux processes through FIFOS or shared 
memory, so you can show real time data with Java, web browser, or whatever 
you want and LInux supports.

Whereas, real time linux patches improves determinsm in Linux kernel, enabling 
Linux to do some kind of control or data asquisition in "soft" real time. 
With this approach you can improve a lot Linux performance and to use Linux 
for some "¿¿critical??" code, BUT, you can never make sure this determism is 
100%. Of course, perhaps it is all you need, but don't miss the point!!!

A logical question now is: Why Linux is not "hard" real time? and, Can Linux 
be hard some day?

GPOS are GPOS, and the complexity inside them is too high to make the code 
available for hard real time. The reasons RTLinux is a good approach are:

1) Traditional RTOS like VxWorks, QNX, ..., have a current problem: developers 
want to have all what a GPOS offers and at the same time hard real time. The 
problem is if you want precission, robustness, predictivity, ..., this is 
what a RTOS offers, you need lines of code to be limitted in number, then 
someone can read the full code and ensure the real time requeriments. RTOS 
can not do that, and although they can add some funcionalities, these will 
not be what a GPOS offers, and the cost for them is too high.

2) RTLinux was the first approach to use virtualization in real time, more 
than 10 years ago. Since then, the market is going to this kind of solutions, 
even processors are designed to enable virtualizarion in a easier and better 
way.

I remember you needed to improve interrupts latencies. Then, if you just need 
a better mean response time, you can use real time linux patches. If you need 
to ensure 100% these responses, then you need virtualization.

Some numbers:

With a 500us periodic RT task working and network stress (massive ping flood 
and NFS requests) the worst response time for timer interrupt was 62us. With 
a special configuration with real time code running in LMB: 24us.

I hope this explanation can help you.

Regards.   

On Wednesday 10 January 2007 13:13, Brettschneider Falk wrote:
> Hi Alejandro,
> What improvement have you noticed with your patch on your system? Can you
> give some before<->after numbers? CU, F@lk
>
> ___________________________
> microblaze-uclinux mailing list
> microblaze-uclinux@xxxxxxxxxxxxxx
> Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
> Mailing List Archive :
> http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/

-- 
Alejandro Lucero
Director Técnico
+34 665 68 71 68
Valencia (SPAIN)
www.os3sl.com

___________________________
microblaze-uclinux mailing list
microblaze-uclinux@xxxxxxxxxxxxxx
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/