Date: Tue, 4 Nov 2003 19:01:00 -0500 From: "nw1" <network101@covad.net> To: <freebsd-questions@freebsd.org> Subject: Re: Overheating attributed to Freebsd --sysctl variables not available-- Message-ID: <015601c3a32f$e581b820$0300a8c0@install>
next in thread | raw e-mail | index | archive | help
Jud, (see below) ----- Original Message ----- From: "Jud" <judmarc@fastmail.fm> To: "nw1" <network101@covad.net> Cc: "freebsd-questions" <freebsd-questions@freebsd.org> Sent: Tuesday, November 04, 2003 3:17 PM Subject: Re: Overheating attributed to Freebsd --sysctl variablesnotavailable-- > > On Tue, 4 Nov 2003 14:05:02 -0500, "nw1" <network101@covad.net> said: > [snip] > > > > I'm interested in those missing sysctl variables I posted @ > > > > http://69.3.136.141/freebsd/installation/sysctl_variables_missing. > > > > Using a Third party > > > > application/script to fix something that was natively working or under > > > > control, I don't > > > > think, is the way to go and causes another level of complexity. > [snip] > > No problem, I am interested in any and all *sane/reasonable feedback. I > > haven't been to > > much a fan of using third party applications to fix something the > > original code or > > hardware should be able to handle. > > FVCool isn't a "third party application" as I understand the term. > Perhaps a portion of the README file will make things clearer: I understand better now (FVCool). Thanks for taking the time to explain that FVCool is not a "third party application". I'm still questioning the difference in behavior --not only between the two (2) OS's when idling, --overheating in FreeBSD, and *not overheating in the non FreeBSD OS. whatsoever. > > "As is well known AMD's Athlon/Duron is a 'hot' CPU. It really produces > a lot of heat. This is mainly because it consumes a lot of electric > power. However, there is an another reason: Generally CPU goes into > power-save mode when it is in the idle state, but in almost all the > mother boards this is prohibited in the case of Athlon/Duron mother > boards in their original BIOS settings. This software changes the PCI > configuration data of the chipset (north bridge), and allow Athlon/Duron > to go into power-save mode. The principle is very simple if you have > information. Actually, you can do exactly the same thing as this > software > manually by using the 'pciconf' command in FreeBSD. > > "Why mother board vendors release their products with such BIOS > settings? What's the reason? <nothing here> > Well, there is a reason: There is a possibility to get the system > unstable > and/or even to hang or crash the system. Therefore, this software is > somewhat dangerous in this respect, and I will not take any > responsibilities for problems caused by using this software. Please > check the original Martin Peters's VCool web site for learning more of > technical details: > > http://vcool.occludo.net/" > > So what FVCool does is utilize the 'pciconf' command to encourage AMD > CPUs to go into power-save mode when idle, a function most motherboard > manufacturers turn off for the stability reasons mentioned by FVCool's > author. As the documentation says, you can manually make these changes > with the 'pciconf' command, but why not save typing by installing the > port and running the 'fvcool' command, or run it automatically with a > script? > > Based on the names of the sysctls you're after, I'd speculate they may > operate in much (or even exactly) the same way. That is why I wondered, > in response to your advice to Paul Mather, whether those sysctl settings > would work with Intel CPUs. My suggestion to *Paul Mather was in fact a blind suggestion only based on the settings to lower the usage of the cpu and not raise; had it been the other way around, I'm not sure I would have recommended he set those knobs to '1'. The following fact/issue, i think, still remains outstanding; Using the setup I originally posted, we can do somethings within the non FreeBSD OS that will rival a looping 'make buildworld | buildkernel, utilizing both cpu's for encoding purposes while playing a quake3, utII game and the like, never overheating or exhibit any instability. Please don't take that above statement as a "this OS is better than your OS". What I've understood from this particular posting is this: the motherboards used for the AMD Athlon/Duron(s) have a default BIOS setting --not allowing the processors to go into 'Power Saving Mode' --while intel based --default BIOS settings: *do allow 'Power Saving Mode' for the processor(s). y/n? That seems to be just a bit disturbing. If we could for the purposes of this paragraph alone, suspend the notion of *over heating while idling*... As someone stated earlier in the thread, what about these cpu's under heavy load within FreeBSD? <-- in our case, without the air-conditioner on;--> will overheat and shutdown I have put these cpu's under heavy load in a non FreeBSD environment and the hardware refuses to break down, overheat or shutdown -- Unsuspend the notion of *over heating while idling*... -- Should we turn our air-conditioner off and set: machdep.apm_suspend_delay: 1 machdep.apm_standby_delay: 1 and let this dual AMD idle, the machine will overheat and shutdown in a matter of hours. Once the room is at a tempurature warm enough to make the machine shutdown, the only way to keep that machine on for more than five (5) to Twenty (20) minutes is to turn the air-conditioner on and leave it on. Should we turn our air-conditioner off and set: machdep.apm_suspend_delay: 0 machdep.apm_standby_delay: 0 Run a script to loop: make buildworld && make buildkernel KERNCONF=<MY_KERN> The machine seems to run like a champ without overheating/shutting down. SUMMARY: I hear all of what you're saying here, however, if we leave apm out of this altogether, whether inTel, AMD or any other processor, shouldn't the processor(s), dual or not, be able to run full-throttle or, idle without overheating/ shutting down? > > Jud > _______________________________________________ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?015601c3a32f$e581b820$0300a8c0>