On Thu, Feb 2, 2012 at 1:43 PM, Camaleón <noela...@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 <noela...@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. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cadzy+jiefe15zamboz7bcadxvmzjcenge9w6u-2qusse-n2...@mail.gmail.com