New computer is not running as fast as expected

jay73 · 04-30-2007, 08:17 PM

I suggest you boot into Linux (if possible) and issue the following commands:

hdparm -I /dev/sda

hdparm -tT /dev/sda

(which assumes your drive is actually sda, not sdb or whatever - adjust as required).

Then post the results of hdparm -tT and skim the output of the other command for mode: are you using pio or udma (the one you are using should be indicated by an asterisk).

Quakeboy02 · 04-30-2007, 08:31 PM

Have you gone into the BIOS and checked to see if there's something like "optimize for speed"? I have an MSI mobo here that defaults the FSB speed to 100MHz when you clear NVRAM. I'd look to the FSB speed and perhaps any setting related to the PCI bus or memory speed. Does your system report the correct processor speed? If not, that's one clue of a problem.

Electro · 04-30-2007, 09:33 PM

There is also filesystem overhead and other latency issues. Both EXT3 and ReiserFS have poor copy throughput. About 3 MB per second to copy a file from one drive and then to another drive that is using EXT3 or ReiserFS as the filesystem seems reasonable. I suggest using JFS or XFS. I use XFS with custom format options. With XFS, I get near normal desktop usage which is about 20 MB to 60 MB per second. I use XFS for majority of my partitions except for /var/log and /boot.

nVidia motherboard chipset and Intel processors do not mix well. nVidia motherboard chipset and AMD processors works well and performance is better than any chipset for AMD. If you can, upgrade the BIOS. I suggest using Intel chipsets, but if you do not want Intel chipsets, I suggest your next selection be ATI. ATI does not provide stable drivers in Windows, but 3rd party drivers that Linux provides are more reliable. Though I do not have any proof, but what I do have is nVidia makes pathetic chipsets for Intel processors.

Quote:

As for Electro's recommendation, I'm not 100% sure. Samsung may have had a poor reputation but this latest line of Spinpoints appears to be much better than their earlier drives. I just benchmarked my Western Digital drives against the Samsung and they get beaten by a considerable 11MB/s. Or is hdparm unreliable as a benchmark?

People still do not understand that throughput does not matter when it comes to accessing files. Again throughput can always be improved by using RAID-0. Accessing times can not be better or lower easily.

hdparm only tests raw performance. It does not test filesystem performance.

davidguygc · 04-30-2007, 09:41 PM

I checked, and FSB is 1066 MHZ, memory 800 MHZ.

Here is the output from hdparm -I

Code:

/dev/sda:

ATA device, with non-removable media
	Model Number:       SAMSUNG HD501LJ                         
	Serial Number:      S0MUJ1CP100444      
	Firmware Revision:  CR100-10
Transport: Serial, ATA8-AST, SATA 1.0a, SATA II Extensions, SATA Rev 2.5
Standards:
	Supported: 8 7 6 5 
	Likely used: 8
Configuration:
	Logical		max	current
	cylinders	16383	16383
	heads		16	16
	sectors/track	63	63
	--
	CHS current addressable sectors:   16514064
	LBA    user addressable sectors:  268435455
	LBA48  user addressable sectors:  976773168
	device size with M = 1024*1024:      476940 MBytes
	device size with M = 1000*1000:      500107 MBytes (500 GB)
Capabilities:
	LBA, IORDY(can be disabled)
	Queue depth: 32
	Standby timer values: spec'd by Standard, no device specific minimum
	R/W multiple sector transfer: Max = 16	Current = 16
	Recommended acoustic management value: 254, current value: 0
	DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6 udma7 
	     Cycle time: min=120ns recommended=120ns
	PIO: pio0 pio1 pio2 pio3 pio4 
	     Cycle time: no flow control=120ns  IORDY flow control=120ns
Commands/features:
	Enabled	Supported:
	   *	SMART feature set
	    	Security Mode feature set
	   *	Power Management feature set
	   *	Write cache
	   *	Look-ahead
	   *	Host Protected Area feature set
	   *	WRITE_BUFFER command
	   *	READ_BUFFER command
	   *	NOP cmd
	   *	DOWNLOAD_MICROCODE
	    	SET_MAX security extension
	    	Automatic Acoustic Management feature set
	   *	48-bit Address feature set
	   *	Device Configuration Overlay feature set
	   *	Mandatory FLUSH_CACHE
	   *	FLUSH_CACHE_EXT
	   *	SMART error logging
	   *	SMART self-test
	   *	General Purpose Logging feature set
	   *	64-bit World wide name
	   *	Segmented DOWNLOAD_MICROCODE
	   *	SATA-I signaling speed (1.5Gb/s)
	   *	SATA-II signaling speed (3.0Gb/s)
	   *	Native Command Queueing (NCQ)
	   *	Host-initiated interface power management
	   *	Phy event counters
	    	DMA Setup Auto-Activate optimization
	    	Device-initiated interface power management
	   *	Software settings preservation
Security: 
	Master password revision code = 65534
		supported
	not	enabled
	not	locked
		frozen
	not	expired: security count
		supported: enhanced erase
	168min for SECURITY ERASE UNIT. 168min for ENHANCED SECURITY ERASE UNIT.
Checksum: correct

and -tT:

Code:

/dev/sda:
 
Timing cached reads:   21328 MB in  1.99 seconds = 10726.93 MB/sec
 
Timing buffered disk reads:  254 MB in  3.01 seconds =  84.44 MB/sec

davidguygc · 04-30-2007, 09:45 PM

Also, when I got the 2.8 MB/s xfer rate it was from vfat to NTFS while running Windows, I'm sure I'd get the same results in Linux, just at the moment it takes about 5 mins to jump back and forth between each OS, no LILO or GRUB installed.

islamabadi · 04-30-2007, 10:17 PM

guys why do we complain about having slow response time or data transfer rate...why cannt we simply use command line to move stuff in between the partitions....and then compare the speed...A REAL LINUX USER has to be a GURU of Command Line...GUI is for Microsoft Users ...hehehehe

jay73 · 04-30-2007, 10:18 PM

Quote:

About 3 MB per second to copy a file from one drive and then to another drive that is using EXT3 or ReiserFS as the filesystem seems reasonable. I suggest using JFS or XFS

I use XFS exclusively; yet I am seeing these huge differences in performance when switching from Gnome to KDE.

Quote:

People still do not understand that throughput does not matter when it comes to accessing files. Again throughput can always be improved by using RAID-0. Accessing times can not be better or lower easily.

Well, I do understand that part. But this particular Samsung drive has equal if not lower access times than my WD2500KS drives. I'm sure one could find WD drives that do perform better, but those would fall in a higher price category (the Samsung was about $130 the last time I checked).

@davidguygc:

Are you sure that your drive is as slow when you use Linux as when you use Windows? The output you posted here would appear to indicate otherwise. You do have UDMA6 enabled and the reads are actually somewhat better than those I get from my own system. Have you checked in windows whether it is not using PIO mode? Is it optimized for performance?

davidguygc · 04-30-2007, 10:38 PM

Well, When I was shifting backup files from partition to partition in Linux, it would say around 25 MB/s.

When I looked at it, it said "Let BIOS pick the mode" but I can switch it to PIO mode manually, is that what I want to do?

davidguygc · 04-30-2007, 10:42 PM

I found a "Read Speed Test"

This is what it says for my drive:

Code:

Theoretical limit: 300
Burst Speed: 91.2
Sustained Speed: 69.7

I turned on PIO mode, and I'm assumming I don't want it, because the read test slowed down, and the music I was playing was slowed to about half speed during the test.

jay73 · 04-30-2007, 10:51 PM

No, you don't want PIO mode. That's the slowest you can get. But sometimes people are using PIO without knowing it so I wanted to make sure that you weren't when I saw that 2.8MB/s.

Again those figures look fine to me. They are more of the theoretical kind of information but they do mean something at least. One thing that could play a considerable role is the nature of those files: are they small or big, scattered or grouped? If you move one big file, you should see better performance than when you are accessing a lot of smaller ones.

davidguygc · 04-30-2007, 11:29 PM

Right, those numbers look great, it's just that I'm not actually seeing it happen.

jay73 · 05-01-2007, 12:09 AM

Well, as I said, those are theoretical speeds. If you move one large file, say a dvd movie or so, you should see the transfer rates go up. Smaller files involve more searching = lower speed.

davidguygc · 05-01-2007, 12:29 AM

Well, I've been testing all of these numbers based on 1 650MB file. So I gotta figure out a way to find why my hard drive is only going about 1/2 as fast as it should be. I only have a few more days to return it if it needs to be returned for a different hard drive. I spent too much money on this computer to have a shotty hard drive

jay73 · 05-01-2007, 12:48 AM

I would do the same. But when you boot into Linux again, I suggest you try and move that file from the command line, just as an experiment. As I said, one file I had (100MB) took 30 seconds doing cut & paste but only 2 second when I used the command line. If you see something similar, then it's rather unlikely that the disk is to blame.

davidguygc · 05-01-2007, 01:58 AM

OK, I'll be sure to do that ASAP