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>