Skip site navigation (1)Skip section navigation (2)
Date:      10 Nov 1999 13:13:27 -0500
From:      Randell Jesup <rjesup@wgate.com>
To:        freebsd-arch@freebsd.org
Subject:   Re: I/O Evaluation Questions (Long but interesting!)
Message-ID:  <ybuogd21ago.fsf@jesup.eng.tvol.net.jesup.eng.tvol.net>

next in thread | raw e-mail | index | archive | help
Simon Shapiro <shimon@simon-shapiro.org> 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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ybuogd21ago.fsf>