PDA

View Full Version : hard drive transfer speeds twice as fast on 64 bit OS



dayzed
27th September 2005, 04:45 PM
The gain of running 64 bit OS is negligible from everything I have read. From my understanding a 64 bit OS should not give any gain to hard drive performance. But that’s not what I am experiencing. I am running the following hardware
-------------------
Mother board = EPoX EP-9NPA+Ultra Socket 939 NVIDIA nForce4 Ultra
Hard Drive = 2 Western Digital Caviar 7200 RPM 8MB Cache SATA 3.0Gb/s
Processor = AMD Athlon 64 3000+ Venice
Memory = CORSAIR XMS 1GB (2 x 512MB) 184-Pin DDR SDRAM DDR 400 (PC 3200) Unbuffered Dual Channel
-------------------
It’s a raid0 setup and I am getting almost double the hard drive transfer speeds according to “hdparm –t” when running fedora core 4 64 bit edition vs fedora core 32 bit edition. For example with the 32 bit OS I am getting about 55-65 MB/sec but with the 64 bit OS I am getting about 100-110 MB/sec. What’s the deal? Can some please shed some light? Maybe someone else can also test this out?

Furball
27th September 2005, 04:57 PM
I have a similar setup but slight older hardware (also raid0 on a 64bit machine).
For me the difference between 32bit and 64bit is negligible, just some MB/s.
I don't know what might be the reason for the difference on your machine, maybe different dma settings, but the first value (55-65) seems to be somehow wrong, as that would mean about 30 MB/s for a single hard disk and that's really low for a modern sata disk.

dayzed
29th September 2005, 05:42 AM
Thanks for the reply. Does my SATA drive need to be a SCSI device? Maybe this is the problem? Yeah something is wrong but I don't know what. After reinstalling the 64 bit version of fedora I am back down to 55-65 MB/sec. Maybe hdparm has a problem with the driver I have loaded or maybe hdparm was not intended at all for SATA drives.


[root@localhost xxxx]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/md0 55G 3.9G 48G 8% /
/dev/sda1 92M 14M 73M 16% /boot
/dev/shm 501M 0 501M 0% /dev/shm


---------------------------
[root@localhost xxxx]# cdrecord -scanbus
Cdrecord-Clone 2.01-dvd (--) Copyright (C) 1995-2004 Jörg Schilling
Note: This version is an unofficial (modified) version with DVD support
Note: and therefore may have bugs that are not present in the original.
Note: Please send bug reports or support requests to http://bugzilla.redhat.com/bugzilla
Note: The author of cdrecord should not be bothered with problems in this version.
scsidev: 'ATA'
devname: 'ATA'
scsibus: -2 target: -2 lun: -2
Linux sg driver version: 3.5.27
Using libscg version 'schily-0.8'.
cdrecord: Warning: using inofficial libscg transport code version (schily - Red Hat-scsi-linux-sg.c-1.83-RH '@(#)scsi-linux-sg.c 1.83 04/05/20 Copyright 1997 J. Schilling').
scsibus0:
0,0,0 0) '_NEC ' 'DVD_RW ND-3540A ' '1.01' Removable CD-ROM
0,1,0 1) *
0,2,0 2) *
0,3,0 3) *
0,4,0 4) *
0,5,0 5) *
0,6,0 6) *
0,7,0 7) *


-----------------------
[root@localhost xxxx]# /sbin/modinfo sata_nv
filename: /lib/modules/2.6.12-1.1456_FC4/kernel/drivers/scsi/sata_nv.ko
version: 0.6
license: GPL
description: low-level driver for NVIDIA nForce SATA controller
author: NVIDIA
srcversion: 3094AD48C1B869BCC301E9F
alias: pci:v000010DEd*sv*sd*bc01sc01i*
alias: pci:v000010DEd0000003Esv*sd*bc*sc*i*
alias: pci:v000010DEd00000036sv*sd*bc*sc*i*
alias: pci:v000010DEd00000055sv*sd*bc*sc*i*
alias: pci:v000010DEd00000054sv*sd*bc*sc*i*
alias: pci:v000010DEd000000EEsv*sd*bc*sc*i*
alias: pci:v000010DEd000000E3sv*sd*bc*sc*i*
alias: pci:v000010DEd0000008Esv*sd*bc*sc*i*
depends: libata
vermagic: 2.6.12-1.1456_FC4 gcc-4.0


---------------------------
[root@localhost xxxx]# /sbin/lsmod
Module Size Used by
parport_pc 33965 1
lp 16961 0
parport 49613 2 parport_pc,lp
autofs4 34121 2
sunrpc 194729 1
ipt_REJECT 6721 1
ipt_state 2753 2
ip_conntrack 51205 1 ipt_state
iptable_filter 4033 1
ip_tables 22465 3 ipt_REJECT,ipt_state,iptable_filter
dm_mod 67521 0
video 19913 0
button 5313 0
battery 11721 0
ac 6345 0
nvidia 4397676 12
md5 5313 1
ipv6 307553 10
ohci1394 44321 0
ieee1394 380793 1 ohci1394
ohci_hcd 29409 0
ehci_hcd 44621 0
i2c_nforce2 8897 0
i2c_core 26817 1 i2c_nforce2
shpchp 101865 0
snd_intel8x0 40641 0
snd_ac97_codec 95748 1 snd_intel8x0
snd_seq_dummy 4805 0
snd_seq_oss 44581 0
snd_seq_midi_event 11585 1 snd_seq_oss
snd_seq 77465 5 snd_seq_dummy,snd_seq_oss,snd_seq_midi_event
snd_seq_device 11217 3 snd_seq_dummy,snd_seq_oss,snd_seq
snd_pcm_oss 61169 0
snd_mixer_oss 20161 1 snd_pcm_oss
snd_pcm 118989 3 snd_intel8x0,snd_ac97_codec,snd_pcm_oss
snd_timer 37705 2 snd_seq,snd_pcm
snd 67521 9 snd_intel8x0,snd_ac97_codec,snd_seq_oss,snd_seq, snd_seq_device,snd_pcm_oss,snd_mixer_oss,snd_pcm,s nd_timer
soundcore 13537 1 snd
snd_page_alloc 12233 2 snd_intel8x0,snd_pcm
forcedeth 26945 0
floppy 77009 0
ext3 148177 2
jbd 92657 1 ext3
raid0 8513 1
sata_nv 11589 5
libata 53833 1 sata_nv
sd_mod 22337 7
scsi_mod 174105 2 libata,sd_mod

SlowJet
29th September 2005, 06:57 AM
SATA means 150 MB / sec for the channel. Not the device.
A fast 7200 SATA disk will READ about 72 MB / sec. max.
However, the reading includes the underlying control data on the disk which is about 40%.
Also, the resulting rate is dependent on blocksize.
Maximum effective block size is 16K or about a logical track.
With one interupt the Controlloer can get 2 16K blocks from the disk buffer and stuff it into memory.
Since the effective usage for block size is 4K for many reasons, compression, encryption, space waste and all the old things that were tweeked in the last century, the maximum transfer rate is seldom achieved.

so 72 MB x 60% x (.165 2 4k blocks) = 7.128 MB real read transfer rate per device.
With Linux's 1k blocks this would be a bit slower.
But, because the disk is reading successive blocks on the disk it remains about the same for the lage blocks.
72 MB x 60% = 43.2 MB / sec
Yet, a boot time there are many small files being read randomly, hence lower transfer rates.

Think about, if you could really transfer 50 MB / sec at boot time into memeory, a computer should boot up in 3 or 4 secs.


On a raid 0 (striped with the perfect size and perfect block size) the rate would almost twice as much.
With real SCSI devices and a real scsi controller that understood sorted, tag quueing and detached devices from channel while seeking a raid 5 with 7 disks would be about 6 times as fast. while 9 disks would staturate the scsi 320 channel..

It would take 3 SATA controllers with RAID 5 - 4 disks each to approch the 320 MB / sec scsi rate.

SJ

dayzed
29th September 2005, 04:40 PM
Great info, thanks a lot SlowJet.
>A fast 7200 SATA disk will READ about 72 MB / sec. max
I am assuming you are talking about a single disk. Let’s say you have a raid1 setup shouldn’t this at least add 30-60% (just an educated guess) performance enhancement to the transfer speeds? Let’s pick the lower number say 30%. Well a 30% gain of 72 MB/sec would give as you refer to a “fast setup” 102MB/sec. This is not out of the ball park of what I was getting on my first post. Your math only proved that my numbers are consistent with the numbers you posted.

Not arguing with you at all just trying to do the math. I am going to reinstall the 32bit version of Fedora and not create a raid1 this time. I will then post back the results sometime in the next few days.

Another big problem I see is this. I have another computer with a pci controller card running 1 ide 7200 rpm drive. I get almost the same transfer speeds (about 58 MB/sec) as this newer nforce4 MOBO running a raid1. I do however understand that onboard controllers are generally slower. I never expected to get the 150MB/sec a second I know that much. In fact this is a sataII drive meaning it is rated at 300MB/sec not 150MB/sec http://www.sata-io.org/namingguidelines.asp However my original point was I am getting a lot of inconsistencies between the two different 32bit and 64bit versions of Fedora. Now I am getting inconsistencies between installs.

Thanks again.