From owner-freebsd-advocacy Fri Apr 24 11:35:54 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA25232 for freebsd-advocacy-outgoing; Fri, 24 Apr 1998 11:35:54 -0700 (PDT) (envelope-from owner-freebsd-advocacy@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA25210; Fri, 24 Apr 1998 11:35:48 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.8.8/8.8.5) with ESMTP id LAA00871; Fri, 24 Apr 1998 11:31:34 -0700 (PDT) Message-Id: <199804241831.LAA00871@dingo.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Marc Slemko cc: Mike Smith , freebsd-advocacy@FreeBSD.ORG, freebsd-hardware@FreeBSD.ORG Subject: Re: *** Real Action Item: SPECweb In-reply-to: Your message of "Fri, 24 Apr 1998 12:23:12 MDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 24 Apr 1998 11:31:33 -0700 From: Mike Smith Sender: owner-freebsd-advocacy@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Fri, 24 Apr 1998, Mike Smith wrote: > > > > I have spoken to several of my lower level sal> Once we have the system spec'd, I have no doubt I can get hardware, because it's > > > very obvious that this will be an enormous bonanza for all major corporate > > > sponsors. > > > > - Dual 400MHz PII's (I think this will finally pull ahead of the 1M > > cache 233MHz P6'en). > > I really doubt that dual processors will give you any advantage even if > you were willing to use current. I'm not up on the current state of > FreeBSD SMP, but if it isn't beyond the level of a single spin lock on > kernel code, you won't win and you could even lose by going SMP. You can > actually get worse performance when using SMP on stable Linux kernels than > not using it. That depends on where the load is; if it's in kernel space then I'd be inclined to agree with you (and I'd say that the 1M P6 would probably be a contender there). If the load is even substantially in user space, then the story seems to change entirely. If nothing else, having the second CPU would be educational from our perspective. > > - A BX-based board with as much memory as the PII's will cache. > > - All of the OS, and if possible all of the web data in MFS. This may > > involve the biggest, nastiest PicoBSD config you can imagine. > > The size of the SPECweb dataset actually changes with the "expected" > benchmark results. You are probably looking at... 500-750 megs or so. What sort of working-set size is the system likely to have? On a 1GB system, you could probably get away with an MFS like that. > I don't think you can use MFS, there are certain restrictions on what you > can and can't do when reporting SPECweb numbers. 8( Ok, solid-state SCSI disks then. > > - If it won't all work in an MFS, a DPT controller and a small farm of > > 10000rpm fibrechannel disks. Otherwise, the disk is irrelevant. > > - No swap. > > No, you want swap especially if using Apache (because of all the COW > pages). It won't be "really" used, but you still need it. I'm not sure I follow this, but I may be missing a nuance in our handing of COW. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-advocacy" in the body of the message