Re: Custom Kernel Networking support
On Thu, Feb 2, 2012 at 1:43 PM, Camaleón <noelamac@gmail.com> wrote:
> On Thu, 02 Feb 2012 13:17:24 -0500, A E [Gmail] wrote:
>
>> On Thu, Feb 2, 2012 at 12:37 PM, Camaleón <noelamac@gmail.com> wrote:
>
> (...)
>
>>> 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.
>
> (...)
>
> Yes, which can be good for multimedia purposes but not for the usual
> server stuff.
>
>> In other words, there is no single value for the timer frequency which
>> works for all users.
>
> I have no complaints and all of my systems (servers, workstations and
> netbooks) have the default setting :-)
>
>> 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? "
>
> Yup. There are linux distributions that provide precompiled kernels with
> these settings "tweaked" so the users can install the best kernel for
> their needs. openSUSE does this way, for instance.
>
>> 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). "
>
> Sure, the change can be noticeable in some conditions or specific
> environments.
>
>>> 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.
>
> Mmm, I don't see a direct relation between this setting and the
> networking stack :-?
>
> (...)
>
>>>> 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!
>
> Yes... I've never heard about that before. I wonder if the architecture
> (being a kernel compiled for sparc64) can make a difference here :-?
>
I don't know...it could be. I have done this for Debian in x86_64
environment and went without a hitch. I guess I need to post this in
the debian_sparc mailing list, which I had done in the beginning.
Reply to: