I don't use good memory either. kingston value ram is top of the line for me. I must be living good too, because I have not had any memory compatibility problems.
Yeah, I think there's a stick of Kingston Value Ram somewhere in my mess of machines too... most of the crate farm is actually running generic PC-133 from my junk box (old sk00l!!
). IIRC one of them is even running PC-100 overclocked to PC-133 speeds (because the mobo didn't have an option to run FSB at 133 and RAM at 100)...
I did get a P1308 on the TRFbot 650 duron honestly... must have been all that was available.
I have not yet checked all of my systems... but it sure seemed like the 1308s were preferentially being handed out to the faster ones.
The 3100 semprons I have will OC like no tomorrow, but even cranking from 1.8 Ghz to 2.2 does not help as much as it should. Of course at advanced speeds it kicks some butt on gromacs.
I've been thinking of throwing together another couple of diskless nodes... been checking the mobo listings at Newegg etc. for cheap micro-ATX boards that support the Sempron.
evidently freeBSD and Your linux are running the same linux subsystem.
Well... I've actually got quite a diverse range of Linux versions here. Redhat 8/9, Fedora Core 2, and LTSP 3. Fedora Core 2 is a 2.6.x kernel, the Redhat ones and LTSP are 2.4.x... glibc versions are all over the map as well. It's a bit of a mess, but I figure if it ain't broke...
so far I have tried recompiling the world and kernel using -02 -funrollloops and -03 with no noticeable difference.
The F@h client probably spends 99+ percent of its time inside its own highly optimized SIMD assembly code. So libraries, kernel, etc. are going to be a very minor contributor to overall F@h performance.
the new GCC is supposed to net an 11% increase in speed, but I have not figured out how to get it installed yet.
Unless you can get Stanford to rebuild the client with the new GCC, it probably won't make much difference.
JBI, are you running polling on your network server, or are U using interrupts.? I am not sure if that question will make any sense to you, but if freeBSD, it is an option to force the kernel to check every so often for other interrupts needing servicing rather than just handing control over to the 1st interrupt and letting it have control (however scheduled) till finished. It is said polling is good for a heavy load to keep from starving processes (clients) in a heavy load net server environment.
I am using the stock kernels... I imagine it is using normal interrupts. I also suspect that the only time there is a heavy load on the server is when I power cycle the entire crate farm and all of the nodes are trying to boot over the network simultaneously (which happens very infrequently).
The years just pass like trains. I wave, but they don't slow down.
-- Steven Wilson