Re: 2.6.14-rt1

[Fernando Lopez-Lezcano]

On Tue, 2005-11-01 at 21:55 -0500, Carlos Antunes wrote:
> On 11/1/05, Fernando Lopez-Lezcano <nando@xxxxxxxxxxxxxxxxxx> wrote:
> > On Tue, 2005-11-01 at 12:18 -0800, Fernando Lopez-Lezcano wrote:
> > > On Sun, 2005-10-30 at 14:33 +0100, Ingo Molnar wrote:
> > > > i have released the 2.6.14-rt1 tree, which can be downloaded from the
> > > > usual place:
> > > >
> > > >    http://redhat.com/~mingo/realtime-preempt/
> > > >
> > > > this release is mainly about ktimer fixes: it updates to the latest
> > > > ktimer tree from Thomas Gleixner (which includes John Stultz's latest
> > > > GTOD tree), it fixes TSC synchronization problems on HT systems, and
> > > > updates the ktimers debugging code.
> > > >
> > > > These together could fix most of the timer warnings and annoyances
> > > > reported for 2.6.14-rc5-rt kernels. In particular the new
> > > > TSC-synchronization code could fix SMP systems: the upstream TSC
> > > > synchronization method is fine for 1 usec resolution, but it was not
> > > > good enough for 1 nsec resolution and likely caused the SMP bugs
> > > > reported by Fernando Lopez-Lezcano and Rui Nuno Capela.
> > > >
> > > > Please re-report any bugs that remain.
> > >
> > > 2.6.14-rt2 seems to be running fine on my athlon x2 smp system. Apart
> > > from some time warp messages when starting up it looks fine so far (this
> > > is on fc4).
> >
> > Actually, after enough time logged in (or maybe just with the kernel
> > running without a reboot) I still get the usual Jack warnings:
> >
> > delay of 5469.000 usecs exceeds estimated spare time of 2641.000;
> > restart ...
> >
> 
> I'm also having some when using SCHED_FIFO and SCHED_RR. When running
> several hundred threads, each sleeping on a loop for 20ms, SCHED_OTHER
> performs ok with latencies of less than 10ms while with SCHED_FIFO or
> SCHED_RR, I see latencies exceeding 1 full second!

Wow...
I still have to find time to try to get more data, but I'm _not_ getting
xruns. Something in the kernel timekeeping or the way Jack uses it is
wrong. The messages appear to be bogus as far as I can tell, but they
should not be there in the first place. As before they depend on the
kernel being running for a while, they don't happen right after a
reboot.

-- Fernando


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/