From owner-freebsd-arch Wed Nov 10 10:13:55 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 3AF8A1527A for ; Wed, 10 Nov 1999 10:13:49 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id TAA13704 for ; Wed, 10 Nov 1999 19:13:47 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id TAA07799 for freebsd-arch@freebsd.org; Wed, 10 Nov 1999 19:13:47 +0100 (MET) Received: from mail.tvol.com (mail.wgate.com [38.219.83.4]) by hub.freebsd.org (Postfix) with ESMTP id C608B1525E for ; Wed, 10 Nov 1999 10:13:34 -0800 (PST) (envelope-from rjesup@wgate.com) Received: from jesup.eng.tvol.net (jesup.eng.tvol.net [10.32.2.26]) by mail.tvol.com (8.8.8/8.8.3) with ESMTP id NAA10242 for ; Wed, 10 Nov 1999 13:09:45 -0500 (EST) Reply-To: Randell Jesup To: freebsd-arch@freebsd.org Subject: Re: I/O Evaluation Questions (Long but interesting!) From: Randell Jesup Date: 10 Nov 1999 13:13:27 -0500 Message-ID: X-Mailer: Gnus v5.6.43/Emacs 20.4 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Simon Shapiro writes: >> > We run circles around NT in the Random I/O department, >> > but take a beating in the sequential I/O arena; >> > For about the same hardware, they do 98 MB/Sec, >> > I cannot get more than 45. >> >> I've always though FreeBSD has the opposite problem. > >Nope. I am getting 167MB/Sec for random block device. >We are almost nine times faster on random WRITE (and I >am comparing RAW I/O here to buffered there), twice as >fast on random READ (again our RAW vs. their buffered. > >If you compare our block perfromance to theirs, we are >almost fourty times faster. > >We are on-par on sequential WRITEs; we get 10MB/Sec RAW and >14 block, they report under 20. > >There must be some nasty trick to their sequential READ; >It is 5 times as fast as their sequential WRITE. It's really hard to comment without knowing exactly what you were testing on each, and whether they really were equivalent tests. First, are you certain they're not caching the data, even if they're not supposed to be? This would be my #1 guess. Second, could they be (for large IO's) transferring directly into user memory, bypassing all buffers (I haven't really been following the discussion; a good trick is to do direct DMA into the destination buffer - it also allows you to use large commands to the drive (less command overhead). Saving a memory-to-memory copy counts at those speeds. Third, they could be doing some severe page table magic and not actually reading most of the data into physical memory until it's accessed. Unlikely, though, and very tricky. (Interesting idea, though - pseudo-mmap.) They also could set up the DMA, and mark the pages in the page table so that you'll fault if you try to access them, and then undo the mark when the IO is done (or as each N pages of the IO is done make those N pages accessible). There are many cute tricks here... What hardware do you have that gives 100MB/s or more??? -- Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94) rjesup@wgate.com CDA II has been passed and signed, sigh. The lawsuit has been filed. Please support the organizations fighting it - ACLU, EFF, CDT, etc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message