Date: Thu, 11 Nov 1999 18:36:25 -0500 From: Simon Shapiro <shimon@simon-shapiro.org> To: Randell Jesup <rjesup@wgate.com> Cc: freebsd-arch@freebsd.org Subject: Re: I/O Evaluation Questions (Long but interesting!) Message-ID: <382B52F9.2C6D1E00@simon-shapiro.org> References: <ybuogd21ago.fsf@jesup.eng.tvol.net.jesup.eng.tvol.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Randell Jesup wrote:
>
> 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.
Of course you are right, but, at times, I come across
info that is not to be quoted at the source.
> First, are you certain they're not caching the data, even
> if they're not supposed to be? This would be my #1 guess.
AKAIK, you really have to be an NT kernel hacker to get raw i/o.
> 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.
This happens in FreeBSD on raw I/O. I belive some work was done
to do that on block i.o too (something to do with zero copy
in vm...
> 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.
Hard to do with the i2o protocol, as you give the IOP
a S/G list and have no control from that point on...
> 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???
(bragging corner: 167 read, 138 write :-) DPT PM3755U2B with
256MB of ECC cache in a Dell PowerEdge 1300/600.
FreeBSD RELENG_3, single CPU running.
> --
> 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
--
Sincerely Yours, Shimon@Simon-Shapiro.ORG
404.664.6401
Simon Shapiro
Unwritten code has no bugs and executes at twice the speed of mouth
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?382B52F9.2C6D1E00>