From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1P23fY-0006xC-Gn for garchives@archives.gentoo.org; Sat, 02 Oct 2010 15:06:36 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 87BEDE062D; Sat, 2 Oct 2010 15:06:16 +0000 (UTC) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by pigeon.gentoo.org (Postfix) with ESMTP id 6FC71E062D for ; Sat, 2 Oct 2010 15:06:16 +0000 (UTC) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.messagingengine.com (Postfix) with ESMTP id 5450E150; Sat, 2 Oct 2010 11:06:16 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Sat, 02 Oct 2010 11:06:16 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=message-id:date:from:reply-to:mime-version:to:subject:references:in-reply-to:content-type; s=smtpout; bh=icfG94LHbhyq2pep5pW2p10G0l4=; b=mJyUAq9G5ma0MqpXggYLUguf+5qyyLd9AYbRPOHjWhE+UvkQvJVfHASqxzYEGtpNAAEzmeieXUpjtUllPW7f3HwWKzJdfM4UcZHjRCpPTafHMFNCIGvHyw/IYNNNOj/F1GvwlPeKgKAr9wmIsmyV4fIUIskgaOCtGni+7AKn7js= X-Sasl-enc: zMDKvr/bjzv+9HPUeMeBiELzwP/gUJjith4dIVUiePEC 1286031975 Received: from [192.168.5.18] (lvps83-169-5-6.dedicated.hosteurope.de [83.169.5.6]) by mail.messagingengine.com (Postfix) with ESMTPSA id 436DF4066B7 for ; Sat, 2 Oct 2010 11:06:15 -0400 (EDT) Message-ID: <4CA74A5D.4040505@f_philipp.fastmail.net> Date: Sat, 02 Oct 2010 17:06:05 +0200 From: Florian Philipp User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.9) Gecko/20100927 Lightning/1.0b3pre Thunderbird/3.1.4 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Normal disk speed? References: <201010011823.01414.volkerarmin@googlemail.com> <4CA71D8F.4010508@f_philipp.fastmail.net> <201010021411.49279.volkerarmin@googlemail.com> <4CA72923.8000500@f_philipp.fastmail.net> In-Reply-To: <4CA72923.8000500@f_philipp.fastmail.net> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigCFA6184EC7CEA48573BB572B" X-Archives-Salt: 59057c7f-0959-4375-806c-8275e87917ca X-Archives-Hash: e5dc7141a2e494d7ce4c02f16e15dbf3 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCFA6184EC7CEA48573BB572B Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Am 02.10.2010 14:44, schrieb Florian Philipp: > Am 02.10.2010 14:11, schrieb Volker Armin Hemmann: >> On Saturday 02 October 2010, Florian Philipp wrote: > [...] >>> >>> Assumptions: >>> >>> 1. Seek time is constant. For HDDs we can take an average value. Of >>> course this doesn't work for tapes. They have a seek time which >>> increases linearly with the distance between the fragments. >> >> I think you misunderstood my remark. >> >> Tapes try to stream. Take an old DLT drive with 5-10mb/sec streaming s= peed.=20 >> Slow, isn't it? >> >> But when you do a backup on such an old tape even with a modern harddi= sk you=20 >> have problems keeping it streaming. As soon as you hit a directory wit= h many=20 >> small files - like ~/Mail or /usr/portage you are screwed.=20 >> >> Yes, you have wonderfull 100mb/sec when you read a big, fat file. Or a= single=20 >> small file. But when you have houndreds, thousands or hundreds of thou= sands of=20 >> small files, harddisks suck. >> And your tape drive has to stop and rewind every couple of seconds bec= ause=20 >> your harddisks were not able to keep up the required 10mb/sec. Trueley= =20 >> pathetic. >=20 > Well, that's exactly what my little math shows. When you read 4kB files= , > you can end up with 0.0065 * 50 MB/s =3D 0.32 MB/s effective throughput= > (worst case). >=20 >> >> Besides, seek times are not constant ;) >> >=20 > Sure they aren't. That's why it is stated as an assumption. It is just = a > model. Like every model it has its limits.[1] It doesn't take into > account prefetching, caching and NCQ/TCQ, for example. >=20 > Still it is a valid assumption: *On average*, the read/write head has t= o > move around half the radius of the platter to reach its next position > and it has to wait for half a rotation until the right block is under > the head. If we assume that fragments are uniformly distributed over th= e > whole disk, we can simply take an average value for seek times. >=20 > The model also doesn't take into account that even with no > fragmentation, there might be some seek operations: Blocks on an HDD ar= e > organized in rings (tracks), not as a spiral like the sound track on an= > good old LP. That means that at some point, the r/w head has to switch > to the next track when the file does not reside on one track alone. >=20 > [1] A bit off-topic: I work in applied sciences and engineering. There > I've learned two basic rules about models: 1. Truth doesn't matter, > usefulness does. 2. Every model has its limits. Knowing these limits is= > the single most important important thing when using a model. >=20 Hmm, I've just looked up some specs from this page: http://www.wdc.com/en/products/products.asp?driveid=3D512 These make me a wonder a bit: Average latency is 5.5 ms. That's the time the disk needs for half a rotation. However, read seek time is 12 ms. That's a bit more than one rotation. If that's an average value rather than a maximum, it makes me wonder what takes it so long. It can't be rotational delay (that's their average latency). Therefore it must be the time it takes the r/w head to move into position. I find it a bit unbelievable that this takes so long. If that really is the limiting factor then a high-end server disk couldn't be much faster simply by increasing the RPM. Well, I guess their "seek time" is the maximum value. Then it makes sense: One rotation is 11.111 ms. Then they might add some latency due to data processing etc. Any different thoughts? Another interesting bit of information: Track-to-track seek time is 2 ms. That's the seek time I mentioned above which also occurs for sequential reads/writes. Regards, Florian Philipp --------------enigCFA6184EC7CEA48573BB572B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkynSmEACgkQqs4uOUlOuU+SIQCfeNujMUKrPo5pHsgtQ3O/mTGh U2cAn1AuZXk6lgm0GAWfYrsoGXwH21gn =DW8/ -----END PGP SIGNATURE----- --------------enigCFA6184EC7CEA48573BB572B--