On Tue, 2004-09-07 at 21:02, Malcolm Baldridge wrote:
Once people
see how much better it works than 2.4+ll there will be no
stopping it.
Does it work better? I'm sure these things are changing daily, but the last
time I tested it with an oscilloscope connected to a parallel port control
line with an RTC-interrupt generated square wave toggle showed 2.4 having
less error when sampled over the course of an hour during routine system
usage testing (disk, graphics card, network I/O, etc).
Yes, it certainly does work better. I have boatloads of numbers to back
this up. In the past few weeks there have not been many new latency
fixes, mostly stability improvements and ports to other architectures.
For a regular UP 32-bit desktop x86 system it has been stable for
several weeks now.
From that test,
having 2.6 simply MATCH 2.4's performance would seem an
upgrade. Let alone,
bettering it.
Um, this is exactly what I said in my response to
the 2.6 low latency
thread. If you read my post I said that unless you enjoy patching and
recompiling your kernel and living on the bleeding edge in general that
you should wait for binary kernel packages for your distro.
The realtime-lsm module is ~200 lines of code.
What is does to the
kernel can be summed up in one sentence.
Ah, realtime-lsm - OK, I misread the subject (semantically, obviously). My
apologies.
OK, apology accepted. I made a similar mistake (read "debian stable"
where soneone wrote "unstable") on LKML the other day with similar
results... it happens.
You have examples of where an
end-user/application-oriented popularity poll
swung a proposed patch into being adopted by the LK maintainers? I'm all eyes.
One of the goals of the new kernel development model worked out at OLS
was to get useful patches into the mainline kernel more quickly, because
vendors will just patch them in anyway.
Please RTFS
before you assume things like this, or at least read the
freaking LKML threads. This is exactly what has been achieved.
Did you just read that kernel traffic summary that was posted to
linux-audio-user? That information is all at least a month old, a LOT
has happened since then. Please know what you are talking about next
time.
Bleh. Fine, it's been 3 or 4 weeks since I've last look at source. If it's
changing that wildly, my original remarks have even more pertinence, not less.
The reason I posted this was that the 2.6 low latency patches are
starting to stabilize, and I didn't want to wait until they _were_ ready
for general use before trying to get realtime-lsm into the kernel. The
idea was to make the eventual, inevitable migration to 2.6 as smooth as
possible.
I wasn't declaring a reality, I was simply
pointing out the dangers of such
unbridled enthusiasm for a relatively untested kernel branch, as emitted in
your sentence:
Now that the final touches are being put on the
2.6 low latency
patches, a massive migration of linux audio users to 2.6 is
imminent.
Maybe you will be more enthusiastic as well once you test it. ;-)
Anyway my goal is to make it easier for people to try 2.6 when and if
they want to by eliminating the extra step of installing the
realtime-lsm module. I certainly did not mean to imply that it is ready
for production use. But we certainly do need more testers, as long as
they know what they are getting into. ;-)
Lee