[PlanetCCRMA] another kernel patch

[James van Zeeland]

Yep...I've been testing it on a 2.4G P4 and a 1.2G Celery under RH9. 
Works great I use a tuning of 400Hz, more overheads, but the P4 has no 
problem with that, the 1.2 hasn't really seen a multimedia load just 
yet. responsiveness is certainly up over stock kernels.

I simply recompile all modules ( including ALSA ) from source under ck 
kernels. I am booting the P4 over gigabit uplink, recording is done to 
local RAID0. Minor stability issues, but that is not the kernel, but 
rather the Intel e1000 uplink, which has a distressing habit of 
occaisionally locking everything up under a couple of very specific load 
conditions...tuning might help here, I suppose. haven't got that far, 
and it hasn't been really strapped as a media workstation yet, but I'm 
really happy with it so far.

What I'd like to ask is does anyone else find RH9 a real pain in the 
proverbial when it comes to compiling kernels from source? Here's the 
issues I have. Stock RH9 kernels installed from source rpm will not 
compile. devfs is apparently broken. I use RH8 ones instead. they do 
compile, and work just fine on servers. Stock kernel.org downloads 
compile fine and dandy. I've found this on every machine I've installed 
RH9 on.

I haven't used the planet kernel a great deal so I can't make a direct 
comparison with Con Kolivas' . I can't compile modules against the 
planet kernel, you see. The source seems to be out of sync with the 
binaries, and unless it's been fixed since I last tried, it doesn't 
compile from source either. mine complained about missing acpi headers 
if I recall.

RH9 has exhibited another annoyance as well. On the 1.2Gig celery 
kernels that DO compile fine sometimes lockup while resolving module 
dependencies. Never been a bother for me under 7.0, 7.2, 7.3 or 8.0. Now 
all of a sudden I can't compile a kernel properly. Only the stock RH9 
kernel works reliably at boot on this machine. Compiling and installing 
a kernel from source will work first time, and often next reset it locks 
up resolving module dependencies. deleting /lib/modules/kernel-version 
and recompiling/installing will sometimes fix that, but today I 
discovered on powering up a machine today that its only a band-aid. On 
this particular machine the Planet kernel is unuseable....will even 
corrupt ext3 filesystems...

So is there something I'm missing that would cause the module 
dependencies lockup?
Does it sound like a hardware ( memory? ) fault? I've gotten to the 
point where I need to get to the bottom of this cantankerous machine . 
The occaisional gigabit lockup I can put up with, as there is only one 
application/scenario that causes it. (synaptic, when it reads the 
package lists and checks /var/cache/apt/archives....OR if I do something 
dodgy like mass copying/moving really big files using NFS when I really 
should ssh to the server and do it locally....:-)...basically if it's 
exceeding 50Mb/sec sustained transfer over gigabit, it's liable to fail. 
short burst transfers of up to 70+Mb/sec seem fine. I suppose I should 
compile a stock RH8 kernel to check this against, but haven't gotten 
around to it yet. Having said that it's currently at 4 days uptime, so 
it certainly isn't rendering the machine unuseable; just irritating when 
I want to update with synaptic....I have to shut as much as possible 
down and cross my fingers. 2/3 times there's no issue.

Anyone else using gigabit and throwing a load at it under RH9 and a 
pre-emptive kernel?

James

Florin Andrei wrote:

>Anyone else played with the Con Kolivas kernel on a multimedia
>workstation?
>
>http://members.optusnet.com.au/ckolivas/kernel/
>
>In my experience, this kernel has the best responsiveness under all
>kinds of loads. No matter what you do, the system remains responsive.
>This is probably a result of the O(1) batch scheduler, the VM
>improvements, the read latency and the scheduler tuning.
>(That read latency thing is awesome! Even when you do a "cat /dev/zero >
>/testfile" you can still read files easily; the read and the write
>operations become "decoupled" almost completely.)
>When i compare it to CK, the PlanetCCRMA kernel seems to have a somewhat
>poorer interactivity, especially under heavy load. Things like switching
>desktops or unminimizing windows are slower under the PlanetCCRMA
>kernel, when compared to the Con Kolivas kernel (or even compared to the
>Red Hat kernel).
>
>OTOH, i'm not sure how good the CK kernel is to do things like digital
>audio recording (a la Ardour), if you compare it to the PlanetCCRMA
>kernel. Sure, it still has the low latency patch, but i wonder what
>happens if you don't include the DRM, the ALSA RTC and the capabilities
>patches (which are included in the PlanetCCRMA kernel but not in the CK
>kernel).
>(What is this DRM thing anyway?)
>
>Ideally, i'd like to use a combination of the PlanetCCRMA kernel and the
>Con Kolivas kernel, but i'm not sure how well all those things would go
>together.
>
>Anyone can shed some light please?
>
>  
>