Date: Fri, 31 Dec 1999 09:50:52 +0100 From: Brad Knowles <blk@skynet.be> To: Mike Smith <msmith@FreeBSD.ORG>, tsikora@powerusersbbs.com Cc: "freebsd-stable@FreeBSD.ORG" <freebsd-stable@FreeBSD.ORG> Subject: Re: Temperature Findings Message-ID: <v04220800b4921b47e7a3@[195.238.23.239]> In-Reply-To: <199912310627.WAA00576@mass.cdrom.com> References: <199912310627.WAA00576@mass.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
At 10:27 PM -0800 1999/12/30, Mike Smith wrote: > The difference has already been explained as a different instruction mix. > This should be obvious to anyone that has been in the industry for as > long as you have. It seems to me that you guys are all talking past each other: 1. He's mentioned that he runs the same instruction mix (i.e., two seti@home clients) under both Linux and FreeBSD 2. He's mentioned that he's run FreeBSD in both uniprocessor and SMP modes 3. He's mentioned that he's run FreeBSD SMP with 3.3 without problems 4. He's mentioned that the overclocking is a recent introduction to the issue and the system was overheating before then 5. He's also mentioned that this is a chipset which we now know is not directly supported by the measurement interface, and therefore the temperature multiples might (or might not) be off Now, I don't recall seeing which version of the Linux kernel he was talking about -- I'd be guessing that might have some effect. If it was a 2.0.x kernel, then obviously he's not getting more than one processor under Linux anyway. Depending on which 2.1.x or 2.2.x kernel he runs, he should be getting SMP under Linux (if he's built the kernel to support SMP), although he might not have very good SMP (2.2.13+, from all reports I've heard). I'd be real surprised if they found some way to HLT the processor under Linux in SMP, but I wouldn't rule it out as impossible. I do still find it suspicious that the temperature difference is 14 or 26 degrees, and that it rises much more quickly than would appear to be possible, given the thermal mass, etc.... I also find it suspicious that this works fine under FreeBSD in SMP in version 3.3 (even with all the overclocking, etc...) and that this only breaks in 3.4. Of course, the fact that everyone is talking past each other is not surprising, seeing as many of the correspondents are spread around the globe. If I might make a suggestion based on my own recent introduction to this mailing list -- it really helps if the new poster provides as much detail as possible and doesn't make any assumptions about how much they know about the problem based on their decade-plus (or more) experience, and it really helps if the other people involved give the guy at least half a break while he tries to explain what weirdo whacked out thing he's seeing. Myself, I think I've permanently pissed-off some of the important contributors to the FreeBSD project (and perhaps even some of the core members) by coming in too strong. I hope that one day I'll manage to be able to erase that deficit either by patching things up with the parties in question, or by making enough of my own positive contributions that the past can be forgiven, if not forgotten. Ghu help me if I'm actually the voice of reason in this case, but I felt like something needed to be said before this got too far out of hand. -- These are my opinions -- not to be taken as official Skynet policy ____________________________________________________________________ |o| Brad Knowles, <blk@skynet.be> Belgacom Skynet NV/SA |o| |o| Systems Architect, News & FTP Admin Rue Col. Bourg, 124 |o| |o| Phone/Fax: +32-2-706.11.11/12.49 B-1140 Brussels |o| |o| http://www.skynet.be Belgium |o| \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Unix is like a wigwam -- no Gates, no Windows, and an Apache inside. Unix is very user-friendly. It's just picky who its friends are. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?v04220800b4921b47e7a3>