Re: a joint letter on low latency and Linux

[Roger Larsson]

Larry,

Have you actually tried this code - it should have the same problems...
Use the stress_* programs from Bennos latency test page.

[2 RTLinux processes, 1 Linux processor, 1 selected stress_* program]
 
> 
> OK, now we are getting somewhere.  So I have a kernel level source, user
> level processing, and a kernel level sink, right?  And the problem is that
> we can have long delays which mess that up.  Here is how you handle that
> with RTLinux:
> 
> There are three processes:
>

I assume RTLinux producer can be run anytime - correct?
Like when another random process runs in kernel.

>     RTLinux producer
>         for (;;) {
>                 sample();
>                 put_data_in_shared_mem();
>                 up(producer_sema);

up will wake up the process waiting. But that process
won't get out of bed :-)

>         }
> 
>     Linux processor
> 
>         for ( ;; ) {
>             down(producer_sema);

and here you have the problem!
The "Linux processor" won't start until the random process
has left the kernel (no upper limit)

=> It is the time from the wake up to actual run that is the
problem.

>             get_data_from_shared_mem();
>             process();
>             put_processed_data_in_shared_mem();
>             up(consumer_sema);
>         }
>

Ok, so the "Linux processor" has not kept up... consumer_sema
is not up yet. Ohh. there is nothing to move to device - sound drop out.
 
>     RTLinux consumer
>         for ( ;; ) {
>             down(consumer_sema);
>             move_shared_mem_to_device();
>         }
>

The RTLinux processes won't be much better than a normal driver.
You could put stuff soft synths in drivers too... (there are!)

> I think that 99,000 out of the 100,000 lines of code still lives in the
> Linux process just like it always did.  The only difference is that the
> RT processes get scheduled when they need to get scheduled - the Linux
> kernel and all of it's processes get preempted any time a RT process
> wants to run.
> 
> Think about this.  You already have a mechanism that gives you exactly
> what you need.  And it is _way_ better than any of the proposed hacks.
> The only complaint that is valid is that it is "different".  Yup, that's
> true, the wheel was different too.  Such is life.  You have to give a
> little to get a lot, that's a better tradeoff than you normally get.
>

Try it - you won't like it.
 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [e-mail]
> Please read the FAQ at http://www.tux.org/lkml/

--
Home page:
  http://www.norran.net/nra02596/