Re: a joint letter on low latency and Linux

[David Schleef]

On Thu, Jun 29, 2000 at 10:26:36PM -0600, Richard Gooch wrote:
> [e-mail] writes:
> > On Thu, Jun 29, 2000 at 11:25:27PM -0400, Paul Barton-Davis wrote:
> > > No good. 
> > > 
> > > This assumes it takes zero time for the linux process to do its
> > > thing. If you were running a faster clock, and could tell "ahead of
> > > time" that the linux process hadn't run yet, you could recover. but
> > > otherwise, the RTLinux process is going to run because an audio
> > > interface interrupted, and by that time, it will be too late to try to
> > > generate the data that should have been computed already. Recall: the
> > > RTLinux consumer's job is to move data from shared mem down to the
> > > audio interface. If the data is not ready when it runs, its already
> > > too late.
> > 
> > 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.
> 
> Urg. This is ugly. It's also dangerous, because it fouls up time
> accounting. You'd effectively be changing HZ without telling everyone
> to update their current HZ value to compensate.

I'm currently running a patch that reimplements much of the
timekeeping in the kernel, to avoid all the crud involved with
using the TSC for microsecond timing and the 8254 for long-term
timing and trying to keep them synchronized when using NTP, etc.

One of the things I contemplated doing is to separate jiffies
counting from the timer interrupt.  Basically, treat jiffies
just like seconds -- every time 10 ms rolls over, update jiffies
and do the right thing.  It would be trivial to implement, and
would probably almost work.  This would be the first step to
implementing the equivalent to the microsecond timer feature
of KURT.

(it will be at ftp://stm.lbl.gov/pub/realtime/patch-*-timekeeper
when I get a chance to pull it out of cvs.)

> 
> > I want to try this trick on TCP/IP sometime. 
> 
> I think having RTLinux going in and grope the kernel all over is just
> asking for trouble. That path leads to madness. It will add a tight
> dependency between the internals of Linux and RTLinux. Take it from
> someone who knows: tracking kernel drift is a bitch.
> 
> Again: this is why I like my idea of scheduling user-space RT
> processes with the RTLinux run queue. Only a few well-defined places
> are needed for Linux/RTLinux to co-operate.

I'd like to see a hard-real-time context as a fully-integrated
Linux feature.  Then we don't have to argue about whose patch
is easier to maintain/touches the kernel less/is smaller.  At
one time, I wrote a patch that fully integrated real-time, but
it was impossible to maintain because of kernel drift.

About user-space RT -- since starting to use LXRT, I'm never
going back to writing a module to do hard real time.  Well,
maybe... if I need 10 us latency instead of 15 us.

dave...