[Asterisk-Users] A question about Linux kernels and Asterisk

[WipeOut]

I understand.. Thanks for explaining..

I am going to give kernel building a go but I don't think it will be on 
a production box for a while, not until I am happy that I have at least 
some understanding as to what I am doing..

Thanks again, as always you are a great source of informed help..

Later..



Steven Critchfield wrote:

>On Fri, 2004-01-09 at 09:22, WipeOut wrote:
>  
>
>>Steven Critchfield wrote:
>>
>>    
>>
>>>On Fri, 2004-01-09 at 05:08, WipeOut wrote:
>>> 
>>>
>>>      
>>>
>>>>I know nothing about building custome kernels so if these are stupid 
>>>>questions then tell me.. :)
>>>>
>>>>I am guessing that since the kernel can be built with all sorts of 
>>>>options and settings.. So is there anything in the kernel setup that 
>>>>could be used to make a custome kernel that would be optimised for use 
>>>>with asterisk and make it better able to process the codec operations 
>>>>and RTP streams?? or is it all about as optimal as its going to get in 
>>>>the standard kernels that come with various distros..
>>>>
>>>>The thinking came from a post that I saw a while ago that said that the 
>>>>Fedora kernel was far better with Asterisk than the RH9 kernel..
>>>>   
>>>>
>>>>        
>>>>
>>>The basic wisdom about a kernel is to use as few pieces in it as
>>>possible. If you can get away with stripping it down to bare minimum
>>>then you have removed sections of low non-swappable memory from ever
>>>loading. Optimize to your current CPU level. Maybe implement QoS and
>>>firewalling so you can protect your system better plus get your RTP out
>>>with priority. 
>>> 
>>>
>>>      
>>>
>>So apart from minimising memory usage there is nothing that can really 
>>be done to improve the kernels computational ability.. The best way I 
>>can articulate my thinking is if we take an example of a car engine, you 
>>can take the cylender head and clean up the inlet on outlet ports, even 
>>open them up a little to get a better path for the air fuel mixture to 
>>travel through.. Is there no way to "open up" the computational paths in 
>>the kernel to give it the ability to process more data through the CPU 
>>(obviously the CPU is the the hard limit of the processing ability).
>>    
>>
>
>Nothing like cleaning up flow so much as minimizing the junk that
>pollutes that space. To really push the analogy here, think of your CPU
>as the cylinder, the cache as the volume of space in the intake runners,
>and the clock cycles as something akin to the valves. The memory
>reduction removes code from the cache that isn't interesting to your
>application and therefore move more productive code into cache(don't
>those pesky EGR valves piss you off sticking exhaust gasses into your
>intake). You may find some kernels are compiled for lower class
>processors, this would be like having the wrong kind of fuel being
>provided to your engine(Some diesel can be added to your gasoline engine
>but it won't run at peak performance). So if you optimize the kernel to
>your CPU family, you might get the CPU to handle some of it's integer
>math faster for you.
>
>Essentially all of this comes down to trying to reduce contention for
>the CPU. Minimizing the kernel reduces what it might try and accomplish
>during it's clock cycles. If the kernel can get out of the way faster,
>you leave asterisk with more clock cycles per second. I think you might
>end up getting better reward for effort by making sure you have the
>lowest process count and that every process is really needed. 
>
>On my main switch, I have 47 processes at the moment and 20 of them are
>asterisk, 3 are postgres, 1 sshd, 4 related to my login and ps, 6 idle
>gettys, and a few kernel related and inet related processes. This
>machine doesn't ever break a sweat on my call load.
>
>  
>
>>>I can't comment on Fedora vs. RH9 versions of the kernel as I personally
>>>won't ever run one unless I am hog tied to some special driver whose
>>>creator pushes binary only packages against one of those pre made
>>>kernels. I prefer the bone stock kernel.org sources, but that is just a
>>>preference.   
>>> 
>>>
>>>      
>>>
>>About the only app I run from source is Asterisk so i think creating 
>>(and trusting) my own kernel would be a real stretch..
>>    
>>
>
>Trusting isn't an issue, it works or it doesn't. Rolling your own kernel
>from source is a very rewarding experience. There is many little help
>comments in the kernel help that will also help you find out what might
>help you speed your kernel up or not. For example look at the comments
>about CONFIG_MTRR:
>  x On Intel P6 family processors (Pentium Pro, Pentium II and later)                                                                                                                                  x  
>  x the Memory Type Range Registers (MTRRs) may be used to control                                                                                                                                     x  
>  x processor access to memory ranges. This is most useful if you have                                                                                                                                 x  
>  x a video (VGA) card on a PCI or AGP bus. Enabling write-combining                                                                                                                                   x  
>  x allows bus write transfers to be combined into a larger transfer                                                                                                                                   x  
>  x before bursting over the PCI/AGP bus. This can increase performance                                                                                                                                x  
>  x of image write operations 2.5 times or more. Saying Y here creates a                                                                                                                               x  
>  x /proc/mtrr file which may be used to manipulate your processor's                                                                                                                                   x  
>  x MTRRs. Typically the X server should use this.                                                                                                                                                     x  
>  
>Once you are over the hump about how to create a custom kernel, you will
>be less dependent on RH or fedora for any of your systems. Eventually
>you might be able to choose a different distro based on your new
>knowledge.
>  
>