> hi i'm doing a project which requires to prove practically that RTLinux
> is faster than Linux ..
> can any one help me in this matter.

Please first define what you mean by "faster":

- Network throughput
- Scheduling overhead
- IPC throughput
- IPC latency
- Filesystem performance
- ...

There are many ways to measure a system's performance, but no general
one.

On Wed, 23 Aug 2006 02:19:39 -0700, amitbhat555 wrote:

> hi i'm doing a project which requires to prove practically that RTLinux
> is faster than Linux ..
> can any one help me in this matter.

Real time is about latency, speed is generally a measure of throughput. A
server running a Realtime O/S will typically have lower throughput than a
standard kernel, its latency (time to respond) will be faster, but it will
not benefit as much from queues and processing large chunks without
context switches.

The majority of workloads requiring realtime have only a small realtime
element, so its normal to run one process as realtime and the rest of the
system scheduled around it - kind of best of both worlds.

You need to analyse the workload, separate hard-realtime, realtime
and standard parts of the workload. If you have hard-realtime requirements
then you cant "prove" anything - as only a realtime O/S can achieve these.

You need to work much harder on understanding what you are trying to prove
before you device a method to prove it .........

Jon

amitbhat555@gmail.com wrote:

> hi i'm doing a project which requires to prove practically that RTLinux
> is faster than Linux ..
> can any one help me in this matter.

It isn't faster. But it's predictable, you get a guaranteed
response within a specified time.

Last time I run such a test (kernel version 2.4.9), I measured
interrupt latency by using a fast counter on a custom PCI board.
It turned out that the interrupt latency on an unloaded linux
system was shorter by a factor of 2 compared to RTLinux on the
same setup.

However, as soon as the system load increased, I measured interrupt
latencies as bad a 0.5 seconds. The main culprit turned out to be
a SCSI driver which sometimes disabled interrupts for that length
of time.

In the same situation, the RTLinux interrupt latency stayed unchanged.

Kind regards,

Iwo