From owner-freebsd-fs Sat Aug 14 12:37:17 1999 Delivered-To: freebsd-fs@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id CF61A14CB9 for ; Sat, 14 Aug 1999 12:37:09 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.2) with ESMTP id VAA12287 for ; Sat, 14 Aug 1999 21:35:03 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: freebsd-fs@freebsd.org Subject: disk performance model Date: Sat, 14 Aug 1999 21:35:03 +0200 Message-ID: <12285.934659303@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I have spent a few hours trying to figure out a model for the access time of one of my disks. (I wondered to what extent and what way the length of a seek affected the time it took to perform it.) I set up a small program to read random places on the disk, timing each request, and logging the previos sectornumber, this sectornumber and time it took. The program ran in user space so there is some finite overhead included in the below model for the userland to kernel transition. I collected about 100k samples for various transfersizes. This information may or may not give any meaning/inspiration/insight in the current performance discussions... The disk is in a PII/400MHz system: ata1: master: setting up UDMA2 mode on PIIX4 chip OK ad1: ATA-4 disk at ata1 as master ad1: 17206MB (35239680 sectors), 34960 cyls, 16 heads, 63 S/T, 512 B/S ad1: piomode=4, dmamode=2, udmamode=2 ad1: 16 secs/int, 31 depth queue, DMA mode Model variables: size of transfer in sectors -> SZ number of sectors between last request and next one -> D Model: if (D < 1.25e7) Tseek = D ** .42 * 8.05e-6 + .00175 else Tseek = (D - 1.25e7) * 2.4e-10 + .00945 Trotation = random(0 ... .008.5) Taccess = Tseek + Trotation + 36e-9 * SZ Comments: It should be noted that the place where this model has the worst fit is where it is most interesting: values of D < 1.5e6 where the model underpredicts by up to a millisecond. Above 1.5e6 the model predicts better than +/- 500usec. The disk has larger media transfer rate rimwards than hubwards, but this doesn't manifest itself in the data for SZ < 100 I have no idea what this means in terms of UFS/FFS parameters... -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message