> prety much self-adaptive. The why to gain performance (if > you need it) is to throw hardware at the problem. Using > fast SCSI disks, loads of RAM and faster CPU(s) are the way to go > but, big but, unless you've hit an identifiable bottle neck > there is no point.
Amen. A lot of people spend a lot of time optimizing what I call "corner cases" -- optimizing things that run so infrequently or have such little impact on the overall system that it's not worth optimizing at all. Memory usage is one: I mean I don't think I can buy anything under 256MB DIMMs anymore; I don't install swap space either (2.4.x is absolutely braindead in swap/RAM usage) -- I'd be surprised if 90% of the standalone * systems out there will come close to using that single 256MB DIMM I install. Same thing with compiling the kernel with optimizations. I think that for the most part, *'s processor usage lies in any codec translations that may be occurring. I have MMX enabled in my zapata drivers and turn the PROC=`uname -m` into PROC=athlon or pentium4 or whatever it is I have in the system. I've seen measurable improvements in the codec translation times. (Aside: I told the 2.4.22 Linux kernel that I was on an athlon chip and had all manner of instability, random segfaults and crashes... Moving back to i486 solved the problem. Compiler bug or kernel bug I'm not sure.) (Aside 2: Does anyone know why the md driver does not select the fastest RAID5 checksumming method? I don't use md RAID5 but it always seems to pick the second-fastest of all the methods it tests, as seen in dmesg.) Regards, Andrew _______________________________________________ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users
