Re: a joint letter on low latency and Linux

[Roger Larsson]

> I'm adding a feature to our RTLinux consumer. It collects a frame
> and dumps it, then it looks at the queue -- if the queue is at a low
> water mark, the RT consumer reaches down into Linux, sets need_resched and 
> boosts the priority of the Linux process, if Linux is in user
> mode it might even be worthwhile to generate a timer interrupt
> for Linux. This "runs a faster clock" and can look ahead.
> 
> I want to try this trick on TCP/IP sometime. 

Sorry, this will not help...

It is in fact very close to what we are doing with low latency tests.
The test thread runs AT HIGHEST SCHED_FIFO (there is no higher prio...)

The driver sets need_resched of currently running process and moves
the SCHED_FIFO process to the run queue.

The interrupt ends and the current process should be rescheduled - but it
can't since it is running in the kernel and may remain there for over 100ms.

Even RTLinux needs a low latency kernel to be able to USE standard
processes.

/RogerL