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 1QnXVu-0005HD-8s for garchives@archives.gentoo.org; Sun, 31 Jul 2011 15:01:10 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 103F121C218; Sun, 31 Jul 2011 15:00:54 +0000 (UTC) Received: from mail.ukfsn.org (unknown [77.75.108.3]) by pigeon.gentoo.org (Postfix) with ESMTP id EF820E0521 for ; Sun, 31 Jul 2011 14:59:49 +0000 (UTC) Received: from localhost (smtp-filter.ukfsn.org [192.168.54.205]) by mail.ukfsn.org (Postfix) with ESMTP id 1FB47DED50 for ; Sun, 31 Jul 2011 15:59:49 +0100 (BST) Received: from mail.ukfsn.org ([192.168.54.25]) by localhost (smtp-filter.ukfsn.org [192.168.54.205]) (amavisd-new, port 10024) with ESMTP id k+aKkqP9C254 for ; Sun, 31 Jul 2011 16:00:38 +0100 (BST) Received: from wstn.localnet (unknown [78.32.181.186]) by mail.ukfsn.org (Postfix) with ESMTP id DF1AFDED4E for ; Sun, 31 Jul 2011 15:59:48 +0100 (BST) From: Peter Humphrey Organization: at home To: gentoo-user@lists.gentoo.org Subject: Re: OT: Re: [gentoo-user] X Freezes With Firefox on Many Post 2.6.38 Kernels Date: Sun, 31 Jul 2011 15:59:47 +0100 User-Agent: KMail/1.13.7 (Linux/2.6.39-gentoo-r3; KDE/4.6.3; x86_64; ; ) References: <20110725182047.GM30008@ns1.bonedaddy.net> <201107311451.36206.peter@humphrey.ukfsn.org> In-Reply-To: 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 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201107311559.48160.peter@humphrey.ukfsn.org> X-Archives-Salt: X-Archives-Hash: a27135b3ecfae08d45b7ee3b34bfdb56 On Sunday 31 July 2011 15:17:16 Joshua Murphy wrote: > There probably is a fair chunk of difference in maximum speed the disk > can work at on each end (I've even seen around a 20MB/s difference on > several 160GB drives I've dealt with), but outside of some older > drives that've been heavily abused in their lives, I'm not sure I've > seen a sata drive that I've used my usual drive test (MHDD on a > Hiren's bootable USB) on register below around 60MB/s on the slow end, > and USB2's *theoretical* limit is 480Mb/s (60MB/s) ... real-world > implementations rarely reach, let alone top, around 40MB/s, so disk > speed variation across the disk is an unlikely source of the slowdown. Sounds entirely reasonable, and I wasn't really trying to blame the slowness on that variation - just mentioning it in passing. > More likely, it's the fact that parted has to start from the end, and > work its way backwards, reading, writing, and verifying in separate > rotations of the disk with no benefit from the drive's ability to > stream a larger block into cache, since the whole process is backwards > compared to the streaming read most drives are optimized for. Perhaps I'm naive here, but I should have thought an intelligent disk copying algorithm would be able to account for that, at least in part. Maybe that's why it ran the speed tests at the beginning. > Of course, this is all off the cuff conjecture on my part, including my > assumptions about how parted approaches the whole task... mixed with a > bit of anecdotal evidence on my end... but, makes for amusing > conversation and contemplation, if nothing more substantial. Indeed. > I will point out that the newer advanced format WD 500GB blue's I've > worked recently with pulled a consistent 120-110MB/s speed from end to > end... when their older 320s usually peaked at around 85 or so. Well, I haven't run any proper tests, but watching gkrellm during an occasional large transfer I don't remember seeing more than half that lower figure. These are two Samsung Spinpoint F3 1TB disks in md-raid with LVM-2, and I haven't fiddled with any of their settings. -- Rgds Peter Linux Counter 5290, 1994-04-23