From oracle-l-bounce@freelists.org Sun Jun 6 06:38:17 2004 Return-Path: Received: from air189.startdedicated.com (root@localhost) by orafaq.com (8.11.6/8.11.6) with ESMTP id i56Bc2K07006 for ; Sun, 6 Jun 2004 06:38:12 -0500 X-ClientAddr: 206.53.239.180 Received: from turing.freelists.org (freelists-180.iquest.net [206.53.239.180]) by air189.startdedicated.com (8.11.6/8.11.6) with ESMTP id i56Bbq606995 for ; Sun, 6 Jun 2004 06:38:02 -0500 Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 0E1D272C343; Sun, 6 Jun 2004 06:23:58 -0500 (EST) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09641-24; Sun, 6 Jun 2004 06:23:57 -0500 (EST) Received: from turing (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 5140672C355; Sun, 6 Jun 2004 06:23:57 -0500 (EST) Received: with ECARTIS (v1.0.0; list oracle-l); Sun, 06 Jun 2004 06:22:39 -0500 (EST) X-Original-To: oracle-l@freelists.org Delivered-To: oracle-l@freelists.org Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 33DB472C310 for ; Sun, 6 Jun 2004 06:22:39 -0500 (EST) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06337-95 for ; Sun, 6 Jun 2004 06:22:39 -0500 (EST) Received: from web50607.mail.yahoo.com (web50607.mail.yahoo.com [206.190.38.94]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with SMTP id BDB2572C30D for ; Sun, 6 Jun 2004 06:22:38 -0500 (EST) Message-ID: <20040606114130.24458.qmail@web50607.mail.yahoo.com> Received: from [24.148.161.169] by web50607.mail.yahoo.com via HTTP; Sun, 06 Jun 2004 04:41:30 PDT Date: Sun, 6 Jun 2004 04:41:30 -0700 (PDT) From: Michael Thomas Subject: Re: UltraSPARC IV To: oracle-l@freelists.org In-Reply-To: <20040606072028.90629.qmail@web20422.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by amavisd-new at freelists.org X-archive-position: 2102 X-ecartis-version: Ecartis v1.0.0 Sender: oracle-l-bounce@freelists.org Errors-To: oracle-l-bounce@freelists.org X-original-sender: mhthomas@yahoo.com Precedence: normal Reply-To: oracle-l@freelists.org X-list: oracle-l X-Virus-Scanned: by amavisd-new at freelists.org Hi, --- Paul Drake wrote: > --- Michael Thomas wrote: > > This can be amazing technology, especially in the > > wrong hands. ;-) > > if you read the output of dmesg off of a linux box > with a kernel that knows the difference between a > physical and logical cpu, you'll see that the > runqueue > of logical is mapped to the physical. from just > watching top, in a dual cpu system, the 2 physical > CPUs will be loaded prior to any processes running > on > the logical(s). one can see overall cpu usage higher > than 50% with hyperthreading enabled. > I have not played with this feature much. It really strikes me as something that can be easily mis-understood, so I posted my few experiences. Thanks for your detailed explanation on a linux system. I've quit *killing myself* on bleeding edge new features to allow others the opportunity to *try getting the cheese* first. OT (hijack): I've also enjoyed (sick) your AMD64 experiences. Since your recent postings I noticed a reviewer's article on AMD64 and Oracle was also limited to a *local* SCSI HD system. The author pointed out a storage limitation similar to your problem, but the vendor was less *truthful* (where's my tactful vocabulary this morning). Sorry I lost the link, but you probably already saw it, especially given your vendor. It would not help your evaluation anyway. ;-) My last attempt to *force* a linux system to support new storage I/O interfaces was with SATA drivers, over a year ago. SATA is another marketing wonder. (/hijack) > if the storage system is some form of RAID-F, the > cpu > wait % will be high enough that its not going to > matter if you enabled or disabled hypterthreading > anyways. > I was thinking along the same lines. *Legally*, if you can prove that a hyperthreading Oracle server can *never* utilize this type of parallelization then why would someone pay for double the CPUs? 1) Does the dba need to run seti@home just to keep the CPU utilization high, along the lines of BCHR at 100%? 2) Many systems with hypertheading allow you to turn off the feature in BIOS, or possibly elsewhere, and avoid the *pay double licenses* penalty. > Mike - I'm sure that I'm not saying anything that > you > don't already know. Your info was news to me. Thanks again. > > Paul Regards, Mike Thomas __________________________________ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ ---------------------------------------------------------------- Please see the official ORACLE-L FAQ: http://www.orafaq.com ---------------------------------------------------------------- To unsubscribe send email to: oracle-l-request@freelists.org put 'unsubscribe' in the subject line. -- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------