[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Custom Kernel Networking support



On Thu, Feb 2, 2012 at 12:37 PM, Camaleón <noelamac@gmail.com> wrote:
>>
>> root@v100:/usr/src/linux-2.6-2.6.32# dmesg | egrep -i 'eth|bond'
>
> (...)
>
> Bonding? I would first try to setup the ethernet cards separately and
> once you have checked they're working okay with no errors, proceed with
> bonding.
>
>>> When compiling my own kernels, I use "make localmodconfig" to avoid
>>> forgetting modules which are being used/loaded.
>>>
>>>
>> Ok, Thanks for this tip. I followed this with the system running
>> normally as I want. But whenever I make this 1 change in the Kernel
>> config, it stops the networking from working. The change I'm trying to
>> make is change the 'Timer Frequency' of the kernel from 250Hz to 1000hz.
>
> I neither have it enabled:
>
> sm01@stt008:~$ grep -i CONFIG_HZ_1000 /boot/config-*
> # CONFIG_HZ_1000 is not set
>
> OTOH, I've always thought that lower values for timer frequencies are
> better for servers...

a faster timer interrupt, as a I understand, allows for a more precise
and granular track of time and how events are scheduled handled. As I
understand it, a timer frequency of 250Hz will have an CPU interrupt
once every 4 seconds and 1Khz will be once every sec. or something
along those lines. This becomes critical where latency is important,
for e.g. a server that handles real-time voice/video communication.
This person explains it better:

"A faster clock can allow the system to perform more precise delays,
and to respond to events more quickly. Systems running at a higher
clock frequency should have lower latencies in many situations. There
is an overhead associated with the timer interrupt, however; a
higher-frequency interrupt will take more CPU time. So, for server
loads (where latency is
less important), the overhead of a higher timer frequency is not worth
it. On laptops, the default 1KHz timer can also defeat the CPU's power
management features and significantly reduce battery life.

In other words, there is no single value for the timer frequency which
works for all users. Changing the frequency is still relatively hard,
however; some people are more comfortable with building new kernels
than others. Wouldn't it be nice if the frequency could be made into a
boot-time parameter, so that it could be changed from one boot to the
next without a kernel rebuild? "

I have noticed a big difference between 1000HZ and 100HZ on a system
running in VMware. The clock will often end up being much slower than
the real time clock just because VMware can't deal with the overhead
(100HZ being the fix). "

> Anyway, do the cards came up when no bonding is set
> or it fails in the same way?
>

Yes, fails the same way with or without bonding.

>> If I do that and save the configuration without ANY other change and
>> then compare the .config.old and .config, I see a whole bunch of other
>> stuff changed with respect to audio/sound and what not. Then when I
>> build the kernel, the networking/bonding all fails to start. Here's the
>> diff between the two files.
>
> (...)
>
>> Can anyone see what is making it fail? Note, I have ONLY changed the
>> Timer Frequency and nothing else
>
> Nope, sorry, I can't decipher what can be wrong. But sometimes you need
> to use the menuconfig instead manually making the changes because some
> kernel menus/options require another modules to be enabled.
>

Not modifying anything by hand, all being done in menuconfig. I did
the following:

# cp -p /boot/config-2.6.32-5-sparc64 .config
# make menuconfig
<Changed the Timer Frequency from 250Hz to 1000Hz>
<Exit><Exit>
# diff .config.old .config (The output of which is pasted above)

and then saw ALL those changes that got made on its own by simply
changing the Timer Frequency.

Weird!


Reply to: