From owner-freebsd-hardware Mon Sep 29 08:05:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA15469 for hardware-outgoing; Mon, 29 Sep 1997 08:05:30 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id IAA15464 for ; Mon, 29 Sep 1997 08:05:19 -0700 (PDT) Received: from East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA14866; Mon, 29 Sep 1997 08:00:58 -0700 Received: from suneast.East.Sun.COM by East.Sun.COM (SMI-8.6/SMI-5.3) id LAA11127; Mon, 29 Sep 1997 11:00:55 -0400 Received: from compound.east.sun.com by suneast.East.Sun.COM (SMI-8.6/SMI-SVR4) id LAA11372; Mon, 29 Sep 1997 11:00:53 -0400 Received: (from alk@localhost) by compound.east.sun.com (8.8.7/8.7.3) id KAA25150; Mon, 29 Sep 1997 10:05:02 -0500 (CDT) Date: Mon, 29 Sep 1997 10:05:02 -0500 (CDT) Reply-To: Anthony.Kimball@East.Sun.COM Message-Id: <199709291505.KAA25150@compound.east.sun.com> From: Tony Kimball MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Face: O9M"E%K;(f-Go/XDxL+pCxI5*gr[=FN@Y`cl1.Tn To: tom@sdf.com Cc: Anthony.Kimball@East.Sun.COM, michaelv@MindBender.serv.net, toj@gorilla.net, freebsd-hardware@freefall.freebsd.org Subject: Re: supermicro p6sns/p6sas References: <199709282221.RAA23164@compound.east.sun.com> X-Mailer: VM 6.33 under 19.14 XEmacs Lucid Sender: owner-freebsd-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Quoth Tom on Sun, 28 September: : > The supporting argument is insufficient for the conclusion. AMD and : > Cyrix are actively engaged in providing alternate paths to cache. One : > proposed solution is to make a low-profile Socket 7 module with an : > on-board cache controller, making the Socket 7 interface effectively : > a point-to-point bus -- analogous to Slot 1. : : None of these methods exist yet. Compare the MediaGX. "Proposed" in the sense of proposed for industry standardization. : Is CPU performance measured in months now? :) I was not thinking about CPUs, but CPU development paths. To my mind, the performance comparison of different development paths (application-based, rather than feature-based -- so this principle can apply equally well to comparing Alpha to clone-86 or name-your-poison) is best done, not in terms of raw performance of the best exemplar at any given moment, but rather, by how long a given performance point of one development path (i.e. performance of best exemplar, or perhaps best exemplar at a given cost-benefit-point, depending on the planning purposes of the metric) lags behind the equivalent point in the development cycle of another path. This approach is much more useful for purposes of technology management (e.g. in an enterprise) than is raw benchmarking -- and I see no reason why I should not apply the same rationale to my personal purchase planning, on a smaller scale. But for some people/situations, all that matters is what runs make world fastest within your budget, or whatever. We can all read the benchmarks, eh? : I'm little dubious about how well AMD : can make it work. K6, due to bugs, was unable to run FreeBSD reliably up : until a few weeks ago (see archives about which stepping are known to : work, and which are not). And we all know that Intel has had no major Pentium or PPro bugs? (BIG smiley face on that one.) Frankly I don't see any reasonable argument to the effect that AMD or Cyrix are less technically competent than Intel -- quite the contrary, given track records (and the fact that the AMD/Cyrix task is much more difficult than the Intel task). : Also, you can use socket 8 processors in a slot 1 with an adapter. Where can I learn about this?