From owner-freebsd-hackers Thu Nov 12 21:56:26 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA26418 for freebsd-hackers-outgoing; Thu, 12 Nov 1998 21:56:26 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA26413 for ; Thu, 12 Nov 1998 21:56:25 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.1/8.9.1) id VAA01110; Thu, 12 Nov 1998 21:55:59 -0800 (PST) (envelope-from dillon) Date: Thu, 12 Nov 1998 21:55:59 -0800 (PST) From: Matthew Dillon Message-Id: <199811130555.VAA01110@apollo.backplane.com> To: Greg Lehey Cc: Bernd Walter , Mike Smith , hackers@FreeBSD.ORG Subject: Re: [Vinum] Stupid benchmark: newfsstone 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> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :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. (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