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

[Steven Critchfield]

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.
-- 
Steven Critchfield  <critch at basesys.com>