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 1P21SS-0001By-0I for garchives@archives.gentoo.org; Sat, 02 Oct 2010 12:44:56 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A3096E0777; Sat, 2 Oct 2010 12:44:31 +0000 (UTC) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by pigeon.gentoo.org (Postfix) with ESMTP id 77F45E0777 for ; Sat, 2 Oct 2010 12:44:31 +0000 (UTC) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.messagingengine.com (Postfix) with ESMTP id 5084D3B6; Sat, 2 Oct 2010 08:44:31 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Sat, 02 Oct 2010 08:44:31 -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=Fumxb0bTBYZ9NCl+43gbo9oZx+o=; b=ouv73X3HxljYQWqyv5CDuyAXYE1y9vNfJJr8F07rK2vrSz2OerEXLDgIQkj1bEyk36Nf06D99HRAEL3c6mIecL9twdVsHsGMGME/CWZpbt1k2rTj6IblShhibKQBQCKVpX36EgcOGva5U9ibjMNJDrcbqKiYeFjF4kju9e80Ado= X-Sasl-enc: CMgkWX0cGDLhLeWvSohnMGtE/zvDQWYFfzyUu8ecpCZ8 1286023470 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 4FE73408352 for ; Sat, 2 Oct 2010 08:44:29 -0400 (EDT) Message-ID: <4CA72923.8000500@f_philipp.fastmail.net> Date: Sat, 02 Oct 2010 14:44:19 +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> In-Reply-To: <201010021411.49279.volkerarmin@googlemail.com> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8B6D1538C65C3A03765B736C" X-Archives-Salt: b06219c2-db2d-4b94-bea1-f29c33d8765f X-Archives-Hash: 035917d918faaefca827679ef399aa2c This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8B6D1538C65C3A03765B736C Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable 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. >=20 > I think you misunderstood my remark. >=20 > Tapes try to stream. Take an old DLT drive with 5-10mb/sec streaming sp= eed.=20 > Slow, isn't it? >=20 > But when you do a backup on such an old tape even with a modern harddis= k you=20 > have problems keeping it streaming. As soon as you hit a directory with= many=20 > small files - like ~/Mail or /usr/portage you are screwed.=20 >=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 thous= ands of=20 > small files, harddisks suck. > And your tape drive has to stop and rewind every couple of seconds beca= use=20 > your harddisks were not able to keep up the required 10mb/sec. Trueley = > pathetic. 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. Still it is a valid assumption: *On average*, the read/write head has to 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 the whole disk, we can simply take an average value for seek times. The model also doesn't take into account that even with no fragmentation, there might be some seek operations: Blocks on an HDD are 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. [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. --------------enig8B6D1538C65C3A03765B736C 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/ iEYEARECAAYFAkynKSgACgkQqs4uOUlOuU9aUACfXfM0r0MHI3e9SgoTBgQ7cp3M i+wAnR7VPs5aBaQ1Ro91gEktCSHCkIhV =NF52 -----END PGP SIGNATURE----- --------------enig8B6D1538C65C3A03765B736C--