Tiny Core with Real Time Kernel?

[Fiddler]

Robert,

First of all let me say thanks to you and all of your team members on providing the simplest and most powerful Linux I have worked with in all my experiments over the last year. The hard work and dedication of you and your team is greatly appreciated.
Basically, I have worked with many standard Linux distributions and the -rt patched kernel attempting to get the fastest and most consistent interrupt response to a PCI bus hardware event. This has been an effort for more than 1 year. After learning all the cpu isolation and irq balance techniques with the IOAPIC interface provided by the Linux kernel I decided to return to my roots and test what I had learned on the latest TinyCore 3.5.1.
It turns out that the standard TinyCore 3.5.1 kernel is faster and more consistent than all the rest I have tested. I took this long detour because TinyCore did not have a -rt patched kernel option for me to test. I made many attempts to rebuild and patch the kernel and failed miserably.

Bottom Line, I am working on an industrial application in which I would like to use TinyCore 3.5.1 with the -rt patch and see if I can improve the current 15 to 20 microsecond response I am currently obtaining. Could you or one of your team members help me with detailed instructions on how to apply the -rt patch and re-build TinyCore for the latest kernel?

Edit: Title change - RS

[Arslan S.]

download patched kernel source and its config from
http://distro.ibiblio.org/pub/linux/distributions/tinycorelinux/3.x/release/src/kernel/

download latest rt (PREEMT RT) patch for tc kernel (it is currently 2.6.33.3) from kernel.org

extract sources
cd to linux
apply rt patch
cp kernel config to .config
make oldconfig
make menuconfig (if you want to make changes)
make bzImage
make modules

that's all to compile rt kernel for tc

after that you need to remaster tinycore.gz or microcore.gz with new modules

see remastering section at wiki (remastering and custom kernel)
http://wiki.tinycorelinux.com/

[vinnie]

the rt kernel is always a good thing, if that goes well I hope it be shared in some way 

[Michael Wells]

the rt kernel is always a good thing, if that goes well I hope it be shared in some way 

What is an rt kernel, I asked myself, that Vinnie hopes Fiddler will one day share with us? 

So I did the Google thing and found out that an rt kernel or its brother the RealTime kernel is a patched kernel that can be used on real-time system applications where CPU response time must be exactly known in advance.  That is to say in a normal kernel the latency time for the CPU to respond is unknown in advance because it depends on the general load of the system at a given moment.  This unknown latency time would be unacceptable in a real-time production environment where CPU responses must occur within strict delays.  Hence the rt patches for an already configured distro kernel or the same patches to make a RealTime kernel from the kernel's vanilla sources. 

The answer to my initial question was interesting to me and I thought that any other uninformed person like myself reading this thread might like to be clued in as well.  Good luck to you Fiddler.

[bmarkus]

Next question, what is the negative impact of rt patch? Why Linux kernel's are not realtime by default?

BTW, this is a good starting point for the curious:

https://rt.wiki.kernel.org/

[Arslan S.]

i remember some features from PREEMPT RT project is already imported to mainline linux tree

rt kernel is important for time critical applications such as a control application where you must calculate a control signal every sampling period, and the actual time when the signal is sampled is important for deterministic behaviour of the system

simple control application with just a proportional gain

Code: [Select]

e=x - xd
u=-k*e
x: system state
xd: desired state
e: error
k: proportional gain  (>0)
u: control signal

http://en.wikipedia.org/wiki/Control_theory

with a standart linux kernel you can not guarantee the deterministic behaviour of such systems, but with preempt rt kernel hard rt requirements gained with a latency of a few micro seconds

[vinnie]

the production of music benefits much of a kernel rt, just create two labels in the syslinux with different kernel depending on what you want to do

[curaga]

Usually one loses throughput on a RT kernel, while gaining less latency.

[vinnie]

Very understandable explanation curaga.
I take a little ot, If I had to do the procedure that I have expressed previously with microcore64.gz and bzImage64 (for example with label "core64" to boot) and pointing to the same ./tce directory, should work without problems (of course having a 64bit architecture), or I might have some problems with loading programs?

[curaga]

You might hit the module dependency issue - the KERNEL variable in dep files is replaced on download for the running kernel's version.

[Arslan S.]

happy end
http://farm6.static.flickr.com/5094/5563588591_f1abb885be_b.jpg

[vinnie]

  great Arslan S.

@curaga:  , in practice, though some programs in the repo have both 32bit and 64bit dependencies, during download the right ones are chosen, is correct?
but a 64bit architecture can start any 32bit software?

[curaga]

Yes, if you download say wireless-tools it will choose the right set of modules (32/64-bit).

The 64-bit MC can run all 32-bit software.

[vinnie]

I think I understand: wireless-2.6.33.3-tinycore and  wireless-2.6.33.3-tinycore64, or also alsa-modules-2.6.33.3-tinycore and alsa-modules-2.6.33.3-tinycore64 have tinycore/tinycore64 descriptor.
This is a nice dilemma, if one wants to reuse the same package.
If .dep is chosen to download and not dinamically assigned i think that the only way to save space is create a second folder ./tce for restore (example tce64) and aymlink all the packages that are not modules (and therefore do not contain *2.6.33.3*) in it.
Anyway, thanks for the clarification

[roberts]

Fiddler, Thanks for your kind words on our project.

As you can see, even when I am away for a day, that we have an amazing community of extremely knowledgeable individuals.  Therefore It is always best not to direct a question or request to any one  individual. I have taken the liberty to edit your topic removing "Hopefully, this Message and Request will be read by Robert Shingledecker" and changed to read "Tiny Core with Real Time Kernel?"  That way it is more easily recognized what this topic is about. It will also more benefit others interested in this topic.

Thanks for your interest in our project.