From owner-freebsd-current Mon Nov 13 10:22:11 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA16195 for current-outgoing; Mon, 13 Nov 1995 10:22:11 -0800 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA16184 for ; Mon, 13 Nov 1995 10:22:08 -0800 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA16915; Mon, 13 Nov 1995 11:15:05 -0700 From: Terry Lambert Message-Id: <199511131815.LAA16915@phaeton.artisoft.com> Subject: Re: ISP state their FreeBSD concerns To: jgreco@brasil.moneng.mei.com (Joe Greco) Date: Mon, 13 Nov 1995 11:15:05 -0700 (MST) Cc: dyson@freefall.freebsd.org, current@FreeBSD.org In-Reply-To: <199511120717.BAA25951@brasil.moneng.mei.com> from "Joe Greco" at Nov 12, 95 01:17:11 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1844 Sender: owner-current@FreeBSD.org Precedence: bulk > > I am working on this stuff right now. Give me benchmarks!!!! I'll > > do what I can. > > This noted as well. I am frustrated that I cannot seem to hit more than a > PEAK of 4 arts/sec without MMAP, or around 5.5-6 with MMAP. My pet Solaris > news server, with PrestoServe and 128MB RAM, and only 4 disks, can peak out > at around 15. I do know that with only 48MB of RAM, news.sol.net takes more > of a hit on history lookups (expected), but with the I/O load spread over a > dozen disks, I would expect that would compensate somewhat... PrestoServe does striping. Striping is a win for concurrency of access; probably not nearly the win kernel reentrancy would be in effective concurrency, but still a major win. I would like to see striping, volume spanning, and other technologies integrated by way of devfs. This requires a cleanup/reworking of the way that volumes and media perfection, etc. are handled in BSD in general, and the whole idea of logical drives in specific. > Test code that breaks, problematic - at least as far as MMAP goes. MMAP > appears to work fine at first glance, but the panic rate of the system goes > from once every few weeks to once every two or three days. I have no idea > what tickles it. Any way to get a traceback? Any particular panic message? Can you force the panic to happen? > I can probably get you some numbers in terms of file creation/removal rates > on both Solaris x86 and FreeBSD 2.1R (well, SNAP). I don't know what they > will look like so it would be a doubly interesting test for me to perform. Unless the Solaris volumes are mounted async, I expect them to be on the same order as FreeBSD numbers if taken from similar drives. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.