Slow performance on flashed M1015

[dikkiedirk]

I have a M1015-IT HBA on a X9SCM-F. There is a Samsung 7200 rpm 1 TB disk attached to it. I see preclear speeds of about 60-70 MB/s in telnet. Is this normal, or rather slow? Are there any settings of the M1015, that influence this speed?

[BetaQuasi]

That's a perfectly normal preclear speed.  No, there are no speed influencing settings, other than if you have a fully loaded card, ensuring it is in a PCIe x8 slot.

 

Parity checks are likely to be a little faster.

[dikkiedirk]

That's a perfectly normal preclear speed.  No, there are no speed influencing settings, other than if you have a fully loaded card, ensuring it is in a PCIe x8 slot.

 

Parity checks are likely to be a little faster.

 

Is parity check faster than rebuild? I saw parity rebuild speeds with disks using the same controller about 45 MB/s.

[marcusone]

Well. Depends on the position of the preclear. Near the start should see over 100. But average will be about 80 when done (so could get below 80 near the end) 

 

Get weeboo's file creation speed test if you want to be sure.

Also check smart status of the drive (can do during preclear. Won't hurt)

 

Sent from my SGH-I727R using Tapatalk 2

[dikkiedirk]

Trying SMART-report on the mymain-page gives me this:

 

smartctl 5.40 2010-10-16 r3189 [i486-slackware-linux-gnu] (local build)Copyright © 2002-10 by Bruce Allen, http://smartmontools.sourceforge.netSmartctl: Device Read Identity Failed (not an ATA/ATAPI device)A mandatory SMART command failed: exiting. To continue, add one or more '-T permissive' options.

 

 

Can't I get a SMART-report of a disk connected to a M1015?

[BobPhoenix]

Trying SMART-report on the mymain-page gives me this:

 

smartctl 5.40 2010-10-16 r3189 [i486-slackware-linux-gnu] (local build)Copyright © 2002-10 by Bruce Allen, http://smartmontools.sourceforge.netSmartctl: Device Read Identity Failed (not an ATA/ATAPI device)A mandatory SMART command failed: exiting. To continue, add one or more '-T permissive' options.

 

 

Can't I get a SMART-report of a disk connected to a M1015?

Yes if you edit the .AWK files and look for "-d ATA" and change it to "-d SAT" and save them.  Or go to a command line and issue the same smartctl command that mymain shows but without the "-d ATA".  Sorry I'm at work and I can't tell you the files to edit or the exact command beyond the change above.

[Johnm]

It really depends in the drive also. I have seen new green drives blow away 7200 and 10k drives of just a few years ago. As drive density gets higher they get faster data throughput 

 

Try plugging the drive into the once it's done and run preclear again and compare times.

 

 

Sent from my iPhone using Tapatalk

[PeterB]

Yes if you edit the .AWK files and look for "-d ATA" and change it to "-d SAT" and save them.

 

I've found that it's sufficient to remove the -d ATA and leave the software to identify the interface type - no need to force the SATA mode.

[dikkiedirk]

It really depends in the drive also. I have seen new green drives blow away 7200 and 10k drives of just a few years ago. As drive density gets higher they get faster data throughput 

 

Try plugging the drive into the once it's done and run preclear again and compare times.

 

 

Sent from my iPhone using Tapatalk

 

Thanks John,

 

What did you mean by that last line, "Try plugging the drive into the once it's done and run preclear again and compare times." Plugging in what?

 

[dikkiedirk]

Well. Depends on the position of the preclear. Near the start should see over 100. But average will be about 80 when done (so could get below 80 near the end) 

 

Get weeboo's file creation speed test if you want to be sure.

Also check smart status of the drive (can do during preclear. Won't hurt)

 

Sent from my SGH-I727R using Tapatalk 2

 

I got Weebo's writeread10GB test, please see the test.zip in the attachment. Too slow, when you ask me. I also post the smart report of the disk. Please your opinions. The disk is attached to a M1015 on a X9SCM-F motherboard.

 

I also ran Weebo's test on the cache drive, which is a RAID1-volume on an ARC1200. This shows writes of 40-42 MB/s and at the end a read of 1.4 GB/s. Something seems very wrong here.

test.zip

disk1.txt

[BobPhoenix]

Yes if you edit the .AWK files and look for "-d ATA" and change it to "-d SAT" and save them.

 

I've found that it's sufficient to remove the -d ATA and leave the software to identify the interface type - no need to force the SATA mode.

Good to know.  I didn't have a mix of controller types and I didn't want to break anything since I don't know awk.  Seemed easiest at the time to just replace ATA with SAT so that I wouldn't have to worry about a change in string length if it made a difference - which apparently it doesn't.  I'll have to do this sometime - Thanks.

[dikkiedirk]

Well. Depends on the position of the preclear. Near the start should see over 100. But average will be about 80 when done (so could get below 80 near the end) 

 

Get weeboo's file creation speed test if you want to be sure.

Also check smart status of the drive (can do during preclear. Won't hurt)

 

Sent from my SGH-I727R using Tapatalk 2

 

I got Weebo's writeread10GB test, please see the test.zip in the attachment. Too slow, when you ask me. I also post the smart report of the disk. Please your opinions. The disk is attached to a M1015 on a X9SCM-F motherboard.

 

I also ran Weebo's test on the cache drive, which is a RAID1-volume on an ARC1200. This shows writes of 40-42 MB/s and at the end a read of 1.4 GB/s. Something seems very wrong here.

 

Little update

 

Changed nothing in the hardware but just plugged another USB stick in from a previous test build. It still contained disk-data for parity, cache and data-disks from the old old build. disk1 showed as missing an I replaced this with the current disk. It started rebuilding the disk immediate with a start-speed of 85 MB/s and ended at 55 MB/s. It's now running a nocorrect parity check witch now at 1 % is at 95 MB/s. The previous USB stick must have been corrupt. It was a software-problem after all I guess.