Any Suggestions To Rectify These ATTO Results

jbloggsjbloggs
edited March 2005 in Hardware
Hi,

I have recently fitted 2 x 74GB Western Digital Raptors in RAID0 array on an Intel ICH5R con, on an Asus P4P800 E Deluxe mobo. Page file is on "E" partition. It is partitioned as C, D, E with Windows XP Pro SP2 on C. What could be the cause why the "write" value is so much more than the "read" value from 16KB onwards? The ATTO results for "D" & "E" are of the same kind of pattern, ie much greater "write" values than "read" values from 16KB onwards.

Comments

  • jbloggsjbloggs
    edited March 2005
    Would a possible reason for these ATTO results be because the ICH5R con. on the Asus mobo does not support "Command Queuing"?

    Here is also a copy of an SISoftware Sandra, does the latency appear to be about right?
  • Mt_GoatMt_Goat Head Cheezy Knob Pflugerville (north of Austin) Icrontian
    edited March 2005
    It is the same problem I am having with the Hitachi drives and 74GB Raptors on my NF4 board. The problem is that the controller needs to have the latency tweeked, like I wrote here. Unfortuneately both of our controllers are integrated into the chipset and cannot be accesed by the Powerstrip program used in the link above. Unless someone knows of other tricks to change the latency of these controllers the only option I can think of would be to use a PCI RAID controller card. Command queing has nothing to do with this issue.
  • Mt_GoatMt_Goat Head Cheezy Knob Pflugerville (north of Austin) Icrontian
    edited March 2005
    Sandra does not show device latency.

    What is running on your Promise controller listed at the bottom of you system IRQ list?
  • jbloggsjbloggs
    edited March 2005
    I have 2 X 200GB Seagate Barracudas SATA (without ncq)in RAID0, 32KB stripe, 16KB cluster. I did have these on the ICH5R con before I got the Raptors. The ATTO read/write pattern was such that the read was a bit bigger than the write. It looked what I thought was "normal".

    Here are 2 Powerstrips, which one is the ICH5R con? So there is no way to adjust the latency on the ICH5R?
  • jbloggsjbloggs
    edited March 2005
    Here are ATTO results of 2x200GB Seagate Barracudas SATA on the Promise 20378 RAID con, stripe 32KB, Cluster 16KB, which appear "normal" to me???
  • lemonlimelemonlime Canada Member
    edited March 2005
    I'm having a similar issue with the NF4 controller on my DFI board. Writes are much higher than reads on the top end. Does not seem like much I can change to increase them, as the controller is not a traditional PCI based controller. Pretty disappointing, especially considering my NF3 250GB (which has essentially the same on-chipset controller) does not have this problem. I'm wondering if it is something tuned on the mobo that a bios/firmware upgrade could help?
  • jbloggsjbloggs
    edited March 2005
    From what I understand, changes to the ICH5R con are made through a BIOS update.

    When I ran the 2x200GB Seagate Barracudas SATA on the ICH5R con I got read/write values that were quite near to each other, ie, the read value was usually a bit larger thab the write.

    Why would the ATTO read/write result pattern change so much for the Raptors, the write value greatly exceeds the read value, when nothing else has changed? ie the ICH5R latency has not changed, or does the same latency on the ICH5R give different ATTO read/write result patterns?
  • TexTex Dallas/Ft. Worth
    edited March 2005
    Your writes are bordering on the extreme theoretical limit of what the 32bit pci bus can even transmit.
  • jbloggsjbloggs
    edited March 2005
    Hi Tex,

    Maybe you could explain by what you mean when you said in your post ie "Your writes are bordering on the extreme theoretical limit of what the 32bit pci bus can even transmit".

    The ATTO results of the Raptors, is the "read" value to low, or what is your opinion regarding the read/write values? Should the "read" value be higher? If so, what should I do to increase the "read" value?

    I really know very little about RAID etc..

    I appreciate your comments on this. :thumbsup:
  • TexTex Dallas/Ft. Worth
    edited March 2005
    more like I don't feel the write scores are accurate. Trying to get over 120,000 on the 32bit pci bus is bordering on impossible. 130 to 140,000 is like the theoretical limit but due to overhead its almost impossible to achieve.

    In most ide raid 0 setups the reads are slightly faster. Hopefully not way faster or we have to increase the latency as the writes take longer to complete. Look at latency as the time the controller has control of the pci bus to complete a transfer.

    Thats why several here have suggested a latency problem. Buts it the reverse of what we normaly see as a latency problem.

    The reads on each individual raptor should be around 65 to 70,000 but in real life its going to be hard to double that for raid-0 due to the pci bus limiting ya. If your getting 110,000 plus on reads and writes out of both in raid-0 I wouldn't worry about it. ATTO acts funny sometimes. The 114,000 on sandra for two drives is kick butt and I wouldnt worry about it. And I tune disk subsystems for a living. Your there baby! Your worrying about a problem that does not exist really. Congrats!

    If you wanted to try anything further you could verify both drives perform identicaly as single drives not raided. Not all drives actually perform perfectly and do not match well.

    They look funny in atto but man those are FINE scores for anything on a 32bit bus. Your gonna stress out and mess around over and over trying to get a slight increase you will never feel in real life.

    Tex
  • jbloggsjbloggs
    edited March 2005
    Many thanks for your comments Tex, I do appreciate it.

    Maybe it's is a case of "If it ain't broke, don't try and fix it"!!

    :thumbsup:
  • lemonlimelemonlime Canada Member
    edited March 2005
    Correct me if I am wrong, but aren't the ICH5 and NF3 250GB/NF4 raid controllers on chipset? If that is the case, wouldn't these controllers be independant of the PCI bus? I was under the assumption that the ~130MB/s limit did not apply to these boards..

    Check out my thread here : http://www.short-media.com/forum/showthread.php?t=26845

    With my NF3 chipset, I got much more linear performance (still slightly higher writes than reads), but with the NF4, I got a problem very similar to what you are experiencing. At some instances, the top end delta/difference between reads and writes was around ~45,000! Kind of odd to me. I started up a thread on DFI's support forum to see if anyone has some ideas. Since this is not a traditional pci-based controller, I was told that the latency could not be adjusted. But Tex is right, those drives are still screaming fast! big improvement over the WD360 drives as you can see from my attos in the other thread.
  • jbloggsjbloggs
    edited March 2005
    lemonlime

    I have submitted a couple of attachments of Powerstrip a few posts back:

    The first one is ASUS Tek RAID Controller,
    Adapter ID: Asus Tek - 80F51043H, Rev. 02,
    Location: Bus 2, device 4, function 0,
    IRQ 23, Latency 96.
    This refers to the Promise 20378 RAID con, which appears on the SCSI & Raid Controllers in Device Man as Win XP Promise FastTrak 378 (tm) Controller.

    The second one is labelled ASUS Tek RAID Controller also,
    Adapter ID: Asus Tek - 80A61043h, Rev. 02,
    Location: Bus 0, device 31, function 2,
    IRQ: 18 Latency:0
    This refers to the Intel ICH5R con, which appears in the SCSI & RAID Controllers in Device Man as Intel (R) 82081ER SATA RAID Controller.

    If you look at the Intel ICH5R "Latency" value it reads "0", and it also is "faded out", whereas the Promise con "Latency" value reads "96" and is not "faded out".

    Can the "Latency" value (I presume that this is the "latency" value that you are referring too) in your opinion be changed? And if so what would I changed it to?

    I have not tried to change any "Latency" values in Powerstrip yet.

    Pardon my ignorance, but what/where is the DFI suppost forum?

    As regards the "ICH5 and NF3 250GB/NF4 raid controllers being the chipset", my knowledge of RAID controllers etc is small to non-existent, so I am not really sure about that. I must admit I am hoping to get the answers here from "knowledgeable" people on the subject!! :thumbsup:
  • lemonlimelemonlime Canada Member
    edited March 2005
    From my understanding, 'on chipset' sata/raid controllers operate independantly of the PCI bus. The PCI bus is not only for devices plugged into PCI slots on your mainboard, but also for certain 'onboard' devices, such as SiI/Promise Raid controllers, onboard sound, USB controllers etc. The PCI bus is shared, so all devices consume some of the avaliable bandwidth. Most 'non-server' boards employ the 32-bit PCI bus, which has transfer limit of about ~130MB/s. So theoretically, your drives should not be able to transfer any quicker than 130MB/s, assuming the controller is on the PCI bus, and no other devices are hogging the 'shared' bandwidth. Since your ATTOs show ~150MB/s, you have pretty much exceeded that limit, which would jive with the ICH5 being 'on chipset' instead of on the PCI bus. The chipset should communicate at your FSB speed afik, much quicker than the PCI bus at 33MHz (or sometimes 66MHz). So, if that controller is indeed 'on chipset' then, you should be able to add another raptor to your Raid-0 and get 200+ MB/s (theoretically of course). I don't think it is very linear, but none the less, that 130MB/s limitation should not be there.

    For the most part, these on-chipset controllers yeild better performance. For example, my NF3 board got me over 15K higher scores in atto for my write performance compared to my old rig with a PCI based SiI controller.

    But as of now, I am scratching my head to determine why the NF4 is not acting in the same manner as the NF3. The ATTOs are not very linear in nature, and things seem unbalanced between read and writes, regardless of stripe/cluster setup as well as how full the logical volume is.

    When you mentioned that the latency value is faded out, that is probably because of the nature of the controller, so PCI latency is irrelevant.

    DFI is the manufacturer of my mainboard, I was looking to their support forum for an answer to my questions. So far I have not gotten any good feedback from there.

    Good luck! :thumbsup:
  • jbloggsjbloggs
    edited March 2005
    lemonlime

    I looked around and it appears that RAID ports on the ICH5R do not reside on the PCI bus (as I think you said). The PCI bus with add-on controllers such as Promise 2037x, SiliconImage 3112, or SiS180, on certain mobos has a throughput limit of no more than about 120MB/s, while the limit of ICH5R’s CPU pipeline appears to be twice that.

    This would seem to be quite in line to allow the ATTO "write" values that I have posted with quite a bit of "headroom" to spare.

    However it does NOT explain how I can increase the "read" values so that they come up to the value of the "write" values.

    I will continue to keep my "eyes" (& "ears") open for a possible reason for this.

    The 2 X 200GB Seagate Barracudas SATA in RAID0 on ICH5R gave me a "normal" set of ATTO results (in my opion anyway), the "read" value being just a bit bigger than the "write" throughout the whole range of values. :thumbsup:
  • MissilemanMissileman Orlando, Florida Icrontian
    edited March 2005
    If you really want to put the effort into you can balance these out by adjusting the RAID stripe size and then playing with the partition block/cluster size.

    You will have to restore between each build. Each controller/drive combo is different so you just have to play with the ratios.

    The big thing is like Tex said. Not worth the effort since you won't see a difference in REAL use. The benchmark numbers will change though.

    I think when I had a ICH5 it was 64K stripe was sweet spot with a 16K cluster. 32K was also quite good with a standard 4K cluster.

    Place to start maybe.
  • jbloggsjbloggs
    edited March 2005
    Many thanks to you all for your helpful suggestions! :thumbsup:
Sign In or Register to comment.