[opensuse] Hard disc questions Slight OT
Hi . I have been noticing this system is somewhat slow on the drive i use for music and video storage the drive is an SAMSUNG HD403LJ 400Gb Sata and it seems very slow 7-of-9:/data5 # time dd if=/dev/zero of=test bs=1M count=1024 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB) copied, 12.9316 s, 83.0 MB/s real 0m13.004s user 0m0.008s sys 0m2.956s now that compared with the main system drive which is an ST3200826A 7-of-9:/ # time dd if=/dev/zero of=test bs=1M count=1024 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB) copied, 9.57748 s, 112 MB/s real 0m9.581s user 0m0.004s sys 0m4.300s seems very slow for a drive that is a lot newer anyone seeing this or got any ideas System is Asrock Mboard KS8Xxxxx 64bit AMD Athlon64 CPU 2Gb ram Nvidia FX5500 @256 Mb Opensuse 10.3 x86_64 KDE 3.5.7 "release 72.9" Kernel 2.6.22.19-0.1-default Not the best or fastest on MoBo's but this from the Sata drive is poor Cheerrs Pete . -- SuSE Linux 10.3 (Linux is like a wigwam - no Gates, no Windows, and an Apache inside.) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2008-11-23 at 11:52 -0000, peter nikolic wrote:
I have been noticing this system is somewhat slow on the drive i use for music and video storage
the drive is an SAMSUNG HD403LJ 400Gb Sata and it seems very slow
Try with hdparm -t If you have several partitions, try them all: some results differs. Also, consider if the disk is busy somewhere else during the test. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkkpTXEACgkQtTMYHG2NR9X23gCfbI+pGfn7j/2xcOoJCrUQ+y9A J7IAnAo5gdf6Xf3j4qoSjkxcNHoetFx6 =dw0R -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sun, Nov 23, 2008 at 6:52 AM, peter nikolic
Hi .
I have been noticing this system is somewhat slow on the drive i use for music and video storage
the drive is an SAMSUNG HD403LJ 400Gb Sata and it seems very slow
7-of-9:/data5 # time dd if=/dev/zero of=test bs=1M count=1024 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB) copied, 12.9316 s, 83.0 MB/s
real 0m13.004s user 0m0.008s sys 0m2.956s
now that compared with the main system drive which is an ST3200826A
7-of-9:/ # time dd if=/dev/zero of=test bs=1M count=1024 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB) copied, 9.57748 s, 112 MB/s
real 0m9.581s user 0m0.004s sys 0m4.300s
seems very slow for a drive that is a lot newer
anyone seeing this or got any ideas
System is Asrock Mboard KS8Xxxxx 64bit AMD Athlon64 CPU 2Gb ram Nvidia FX5500 @256 Mb Opensuse 10.3 x86_64 KDE 3.5.7 "release 72.9" Kernel 2.6.22.19-0.1-default
Not the best or fastest on MoBo's but this from the Sata drive is poor
Cheerrs Pete .
First 83 MB/sec is about 5GB a minute. That is a very respectable speed, but I can see why you would like to get 112 MB/s, which would be about 6.5 GB a minute. Hard to say what is going on, but a few issues with your benchmark. 1) /dev/zero in 11.0 (iirc) is buggy and causes performance limitations. Should not be used for bench mark purposes, especially at speed as high as you are getting. 2) Inner radius of the physical drive will transmit at a different speed than outer radius. iirc, the outer radius is faster because the RPMs are the same, but they pack more data onto the outer tracks than they do on the inner tracks so you get more data per revolution. Since you are writing to a file, you don't have anyway to say what part of the drive you are writing to. And yes, the variation can be pretty big. Try performing your process to an entire drive (dd if=/dev/zero of=/dev/sdb ...) And then use iostat -d 5 to watch the transfer speed. Assuming /dev/zero is not limiting you, you should see the transfer rate slowly decrease as you continue writing data. 3) You don't say if it is the same filesystem / PCI-bus / cabling / disk controller / etc. At 100MB/sec you are really pushing all of the components hard. 4) A 1 GB test is way to small to mean much. Lots of caches involved that can interfere with that small of a test. ie. If your disk has a 256MB write cache, it will report done when you're really only 75% done. Kernel cache can be even bigger. Add them together and is is very conceivable that well over half of your 15 second test is just pushing data to cache, and it is taking another 15 seconds to flush those caches. Thus in reality you are only getting half the speed you think you are. Good luck tracking in down, but I suspect it is much more of a complex issue to even benchmark than you suspect. Greg -- Greg Freemyer Litigation Triage Solutions Specialist http://www.linkedin.com/in/gregfreemyer First 99 Days Litigation White Paper - http://www.norcrossgroup.com/forms/whitepapers/99%20Days%20whitepaper.pdf The Norcross Group The Intersection of Evidence & Technology http://www.norcrossgroup.com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sunday 23 November 2008, Greg Freemyer wrote:
On Sun, Nov 23, 2008 at 6:52 AM, peter nikolic
wrote:
First 83 MB/sec is about 5GB a minute. That is a very respectable speed, but I can see why you would like to get 112 MB/s, which would be about 6.5 GB a minute.
Hard to say what is going on, but a few issues with your benchmark.
1) /dev/zero in 11.0 (iirc) is buggy and causes performance limitations. Should not be used for bench mark purposes, especially at speed as high as you are getting.
2) Inner radius of the physical drive will transmit at a different speed than outer radius. iirc, the outer radius is faster because the RPMs are the same, but they pack more data onto the outer tracks than they do on the inner tracks so you get more data per revolution.
Since you are writing to a file, you don't have anyway to say what part of the drive you are writing to. And yes, the variation can be pretty big. Try performing your process to an entire drive (dd if=/dev/zero of=/dev/sdb ...) And then use iostat -d 5 to watch the transfer speed. Assuming /dev/zero is not limiting you, you should see the transfer rate slowly decrease as you continue writing data.
3) You don't say if it is the same filesystem / PCI-bus / cabling / disk controller / etc. At 100MB/sec you are really pushing all of the components hard.
4) A 1 GB test is way to small to mean much. Lots of caches involved that can interfere with that small of a test. ie. If your disk has a 256MB write cache, it will report done when you're really only 75% done. Kernel cache can be even bigger. Add them together and is is very conceivable that well over half of your 15 second test is just pushing data to cache, and it is taking another 15 seconds to flush those caches. Thus in reality you are only getting half the speed you think you are.
Good luck tracking in down, but I suspect it is much more of a complex issue to even benchmark than you suspect.
Greg -- Greg Freemyer Litigation Triage Solutions Specialist http://www.linkedin.com/in/gregfreemyer First 99 Days Litigation White Paper - http://www.norcrossgroup.com/forms/whitepapers/99%20Days%20whitepaper.pdf
The Norcross Group The Intersection of Evidence & Technology http://www.norcrossgroup.com
Hi . I suspect it is something to do with the last kernel update i had never noticed it slow before the last kernel update it gets that bad at times it causes the music to actually pause briefley , reacon it is going to take a bit of hunting down noticed i got the Mobo wrong it is an 939A8X-M still Asrock i have never had any problems with them so stick with what woks Cheers Pete still hunting -- SuSE Linux 10.3-Alpha3. (Linux is like a wigwam - no Gates, no Windows, and an Apache inside.) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
participants (3)
-
Carlos E. R.
-
Greg Freemyer
-
peter nikolic