On Tue, 2005-11-01 at 21:55 -0500, Carlos Antunes wrote:
> On 11/1/05, Fernando Lopez-Lezcano <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]