From owner-freebsd-hackers Wed May 30 18:20:27 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from saturn.cs.uml.edu (saturn.cs.uml.edu [129.63.8.2]) by hub.freebsd.org (Postfix) with ESMTP id 92A6637B422 for ; Wed, 30 May 2001 18:20:24 -0700 (PDT) (envelope-from acahalan@saturn.cs.uml.edu) Received: (from acahalan@localhost) by saturn.cs.uml.edu (8.11.0/8.11.2) id f4V1KIw327035; Wed, 30 May 2001 21:20:18 -0400 (EDT) Date: Wed, 30 May 2001 21:20:18 -0400 (EDT) Message-Id: <200105310120.f4V1KIw327035@saturn.cs.uml.edu> From: "Albert D. Cahalan" To: tlambert2@mindspring.com Cc: freebsd-hackers@FreeBSD.ORG, jandrese@mitre.org Subject: Re: Real "technical comparison" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > This "postmark" test is useless self flagellation. The benchmark tests what it was meant to test: performance on huge directories. > The intent of the "test" is obviously intended to show > certain facts which we all know to be self-evident under > strange load conditions which are patently "unreal". That apps designed with UFS in mind don't usually create such directories is irrelevant. Those that do are being pushed past their original design, which does happen! > We already knew the limitations on putting many files > in a directory; the only useful thing you could do with > that many files in a single directory is to iterate them > all. If the application were trying to "remember" 60,000 > path names, we are talking about 60MB of RAM, just for > the potential top end path data alone, not including the > linked list pointers for a simple linked list approach. Some people think 60 MB of RAM is tiny. > I would suggest a better test would be to open _at least_ > 250,000 connections to a server running under both FreeBSD > and Linux. I was able to do this without breaking a sweat > on a correctly configured FreeBSD 4.3 system. > > Even if all the clients were simultaneously active, on a > single Gigabit NIC, that's still in excess of 4 kilobits a > second per client. > > This could easily be the case with, for example, a pager > network or other content broadcasting system, or an EAI > tool, such as IBM's MQ-Series. How about a real benchmark? At www.spec.org I see SPECweb99 numbers for Solaris, AIX, Linux, Windows, Tru64, and HP-UX. FreeBSD must be hiding, because I don't see it. BSDI, Walnut Creek, and WindRiver all have failed to submit results. (the cost is just loose change for WindRiver) Linux is still #1 for 1 to 4 processors. The 8-way results need to be redone on newer hardware (Windows is ahead now) and Linux doesn't have 6-way or 12-way numbers. Go on, show some numbers. Stop hiding. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message