From owner-freebsd-questions Tue Apr 6 22: 2:56 1999 Delivered-To: freebsd-questions@freebsd.org Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (Postfix) with ESMTP id 7989C14C44 for ; Tue, 6 Apr 1999 22:02:49 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id OAA12375; Wed, 7 Apr 1999 14:30:47 +0930 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id OAA13286; Wed, 7 Apr 1999 14:30:44 +0930 (CST) Message-ID: <19990407143044.E2142@lemis.com> Date: Wed, 7 Apr 1999 14:30:44 +0930 From: Greg Lehey To: Mark Ovens Cc: Darren Pilgrim , "Dragon Knight ][" , FreeBSD Questions Subject: Re: K6-2/333, was: Re: Debug kernel by default (was: System sizewith -g) References: <3709569A.70EEC38A@uswest.net> <37097B00.2186EB92@dtgnet.com> <3709EDEB.BE17A2E8@uswest.net> <19990407025433.C4453@marder-1.localhost> <19990407114602.Z2142@lemis.com> <19990407040113.F4453@marder-1.localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <19990407040113.F4453@marder-1.localhost>; from Mark Ovens on Wed, Apr 07, 1999 at 04:01:13AM +0100 WWW-Home-Page: http://www.lemis.com/~grog Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wednesday, 7 April 1999 at 4:01:13 +0100, Mark Ovens wrote: > On Wed, Apr 07, 1999 at 11:46:02AM +0930, Greg Lehey wrote: >> On Wednesday, 7 April 1999 at 2:54:33 +0100, Mark Ovens wrote: >>> >>> As the person who effectively started all this discussion about >>> bus speeds and multipliers I just want to thank all the contributors >>> to this thread. I now have a better understanding of how it all >>> works. The fundamental misunderstanding I had was that the CPU >>> itself did the mutliplication and that the m/b jumpers simply "told" >>> the CPU what multiple of the bus speed to use. >> >> It does. But there are various parts of the CPU. The part which >> creates the CPU internal clock is just a bit of relatively simple >> hardwired logic. > > Just when you thought it was all over.....:-) > > So my understanding was correct. Partially. > Other posters have suggested that the m/b supplies the multiplied > clock frequency to the CPU and therefore the it *can't* ignore it. No, the MB supplies inputs to the three pins BF0, BF1 and BF2. Logic on the CPU chip uses these inputs to multiply the incoming clock frequency by between 2 and 5.5 in increments of 0.5 (that's 8 different values). The rest of the CPU is blissfully unaware of what's going on, and only looks at the clock frequency it's given. > However, whilst 95MHx & 3.5X is equivalent to 66MHz & 5X, if the CPU > doesn't understand "run at 5X" then it may be running at an > arbitrary speed (3.5X bus?). That depends on the CPU. Some CPUs don't sample BF2, so setting 5.0 (which sets BF2 to 0) has the same effect as if it were high: it runs at 3x instead of 5x. > This all started when you said that you had noticed no (significant) > performance increase from a K6/233 to a K6-2/333. Whilst I'm not > disputing with you that an old HD will adversely affect performance > on disk I/O intensive work such as compiling I would expect a > noticeable performance increase overall, especially with 160MB of > RAM. That depends on what you're doing. > This is what prompted me to ask if, whilst mathematically > equivalent, 95MHz & 3.5X was the same as 66MHz & 5X in practice and > if it isn't then that could explain the lack of performance gain. I understand. No, you won't get as much performance with 66x5 as you will with 95x3.5. But my memory won't run at 95 MHz, and what we're really comparing is the 66x5 on a K6-2 and the 66x3.5 on the K6. Clearly the memory bandwidth doesn't change there. Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message