Date: Thu, 12 Nov 1998 21:55:59 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Greg Lehey <grog@lemis.com> Cc: Bernd Walter <ticso@cicely.de>, Mike Smith <mike@smith.net.au>, hackers@FreeBSD.ORG Subject: Re: [Vinum] Stupid benchmark: newfsstone Message-ID: <199811130555.VAA01110@apollo.backplane.com> References: <199811100638.WAA00637@dingo.cdrom.com> <19981111103028.L18183@freebie.lemis.com> <19981111040654.07145@cicely.de> <19981111134546.D20374@freebie.lemis.com> <19981111085152.55040@cicely.de> <19981111183546.D20849@freebie.lemis.com> <19981111194157.06719@cicely.de> <19981112184509.K463@freebie.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:
:OK, so you want to have 4 15 kB reads, and you expect a performance
:improvement because of it.
:
:Let's consider the hardware: a good modern disk has a disk transfer
:rate of 10 MB/s and a rotational speed of 7200 rpm. Let's look at the
:times involved:
:
: rotational transfer time total
: latency
:
:1 disk/60 kB 4.2 ms 6 ms 10.2 ms
:4 disks/15 kB 7.8 ms 1.5 ms 9.3 ms
:
:Huh? Why the difference in rotational latency? If you're reading
This is only relevant in the non-parallel random-seek-read case. Is
that the case you are talking about? In the linear-read case the disk's
read lookahead cache absorbs the rotational latency. In the parallel
random-seek-read case (i.e. a large concurrent load on the disks from
different processes), it's irrelevant because although the per-request
latency is higher due to lack of spindle synchronization, each disk is
still individually pipelined so if disk #1 finishes it's portion of the
request before disk #2, disk #1 start work on some other concurrent
request, and so forth.
It may seem relevant, but remember that the important resource number
for striped disks is transactions/sec, not the per-transaction latency.
In the large concurrent load case the transactions/sec is not compromised
by the lack of a spindle sync. It should also be noted that the case
where you might think that per-transaction latency is important... the
database case, actually isn't, because concurrent load is typically the
most important factor for a database. I'm sure there are applications
where per-transaction latency is more important, but not many that also
randomly seek the drives. Streaming applications can compensate simply
by reading larger chunks of data (which they do anyway since seeking is
a real killer for concurrent streaming applications).
-Matt
:Greg
:--
:See complete headers for address, home page and phone numbers
:finger grog@lemis.com for PGP public key
:
:To Unsubscribe: send mail to majordomo@FreeBSD.org
:with "unsubscribe freebsd-hackers" in the body of the message
:
Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet
Communications & God knows what else.
<dillon@backplane.com> (Please include original email in any response)
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199811130555.VAA01110>