Date: Thu, 8 Apr 1999 01:13:39 +0100 From: Mark Ovens <marko@uk.radan.com> To: Greg Lehey <grog@lemis.com> Cc: Darren Pilgrim <dpilgrim@uswest.net>, "Dragon Knight ][" <dragonknight@dtgnet.com>, FreeBSD Questions <questions@freebsd.org> Subject: Re: K6-2/333, was: Re: Debug kernel by default (was: System sizewith -g) Message-ID: <19990408011339.B2997@marder-1.localhost> In-Reply-To: <19990407143044.E2142@lemis.com>; from Greg Lehey on Wed, Apr 07, 1999 at 02:30:44PM %2B0930 References: <Pine.LNX.4.04.9904051605450.10244-100000@hades.riverstyx.net> <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> <19990407143044.E2142@lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Apr 07, 1999 at 02:30:44PM +0930, Greg Lehey wrote:
> 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.
>
Ah, thats what I needed to know. So as long as the CPU samples BF2
then 66MHz & 5X will have the same effect as 95MHz & 3.5X (apart
from a slightly reduced CPU <==> memory speed. Thank you for the
explanation.
> > 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
>
--
FreeBSD - The Power To Serve http://www.freebsd.org
My Webpage http://www.users.globalnet.co.uk/~markov
_______________________________________________________________
Mark Ovens, CNC Apps Engineer, Radan Computational Ltd. Bath UK
CAD/CAM solutions for Sheetmetal Working Industry
mailto:marko@uk.radan.com http://www.radan.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990408011339.B2997>