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
