• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

SSD BIOS setting for 4P

Core32

[H]ard|Gawd
Joined
Mar 3, 2012
Messages
1,065
I "tweaked" up my 4P rigs by swapping to 64GB SSDs for each one. I'm using Crucial M4s because they run background garbage collection since I don't know if Trim is a feature in Ubuntu 10.10
After I finished, of course, I realized the SuperMicros have additional BIOS settings for hard drives, including one called "AMD_AHCI". I did not select this before installing the SSDs.
I know when installing SSDs on Win machines AHCI is the "preferred" setup and Crucial even mentions this in their Win installation guide.
My question is whether I should re-do these drive installations with the AHCI setting selected, just select it now after the installation is done or leave it alone.
Lastly, is there an Ubuntu SSD speed check application out there?
Thanks.

 
Unless you know how to rebuild the initrd module, a reinstall is the best option if you switch to AHCI native commands setting. For speed testing at least with reads, you can use 'hdparm -T /dev/sdXY' where X= drive leter and Y is the partition number.
 
AHCI will provide much better performance.
 
Thanks for the information.
I suppose now I need to decide whether to wipe and reinstall completly or try and backup/restore after switching on AHCI.
Other than a BIOS setting, are any other steps required to enable Trim in Ubuntu?
 
Switching to AHCI in linux is not nearing as bad as Windoze. You just need to make sure the correct drivers are loaded in the initrd module. If you do a little bit of research you can find out how to do that. Rebuilding the initrd module for the AHCI drivers will allow you to keep the system as it is without the reinstall/backup/restore.
 
Ok. Just for the heck of it, before re-building initrd or reinstalling Ubuntu, I changed the setting in the BIOS to AMD_AHCI.
The box boots fine with no hiccups.
My guess is this did not actually engage AHCI but also did not destroy anything.
Is there any method to check whether AHCI is active, from within Ubuntu?
 
Code:
$ dmesg | grep scsi[0-9]
[   11.466006] scsi0 : ahci
[   11.466237] scsi1 : ahci
[   11.466457] scsi2 : ahci
[   11.466676] scsi3 : ahci
[   11.959671] scsi4 : pata_atiixp
[   11.960265] scsi5 : pata_atiixp
[324375.850226] scsi6 : usb-storage 6-5:1.0
[807585.510338] scsi7 : usb-storage 6-5:1.0
[816641.445232] scsi8 : usb-storage 6-5:1.0
$
 
BTW, on my 4Ps (both Tyan and SM) AHCI gets used even w/default
BIOS setting (E-IDE). I would suspect that AMD_AHCI is something yet
different (some special flavor or sth).

In any way I'd check what dmesg line gives w/default setting.
 
I get the same output as you on the rig that I have not changed the BIOS setting to AMD_AHCI.
On the 2 rigs I have changed it, both scsi4 and scsi5 also show up as ahci.
The only difference.
 
A-ha! So that's AHCI for PATA ports which n/b are not present in these boards :)
 
A-ha! So that's AHCI for PATA ports which n/b are not present in these boards :)
I'll have to take that back, it does affect SATA ports, at least that's what it looks like:

SM (same as above):
Code:
$ cat /proc/scsi/scsi 
Attached devices:
Host: scsi4 Channel: 00 Id: 01 Lun: 00
  Vendor: ATA      Model: FUJITSU MHV2120B Rev: 892C
  Type:   Direct-Access                    ANSI  SCSI revision: 05
$ dmesg | grep scsi4
[    9.273845] scsi4 : pata_atiixp
$

but on Tyan:
Code:
$ cat /proc/scsi/scsi 
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
  Vendor: ATA      Model: ST9100821AS      Rev: 3.AA
  Type:   Direct-Access                    ANSI  SCSI revision: 05
$ dmesg | grep scsi0
[   11.466006] scsi0 : ahci
$

Odd (scsi4 and 5 are atiixp just like w/SM) .. hmmm.... perhaps HDD is plugged
in a different port.
Tyan has only one SATA exposed. SM has 6. I'll check when I'm home.

Anyway, SSD for a folding box is an overkill IMHO (unless one has money to burn).

HDD w/workaround to FAH's thrashing the medium doesn't impact performance enough
to spend so much time and effort...
 
.......Odd (scsi4 and 5 are atiixp just like w/SM) .. hmmm.... perhaps HDD is plugged in a different port. Tyan has only one SATA exposed. SM has 6. I'll check when I'm home.

I need to check but I may have disabled PATA "sharing" in the BIOS and that may be what shows scsi4/5 as ahci only on my rig. Another case of too many causes leading to an unexplained effect. :eek:

Anyway, SSD for a folding box is an overkill IMHO (unless one has money to burn). HDD w/workaround to FAH's thrashing the medium doesn't impact performance enough to spend so much time and effort...

Money already burned in this case ;)
Just trying to squeeze every millisec out of TPFs that I can.
Gives me something to play with and educate myself some at the same time.
Thanks for all the help.
I plan to take some benchmarks, as built now, then secure erase and reinstall with the AMD_AHCI engaged. Benchmark again, then try a few of the Ubuntu SSD speed tweaks that have been listed to see any impact.
 
When you do cat /proc/scsi/scsi, what bus is your drive on?
 
Anyway, SSD for a folding box is an overkill IMHO (unless one has money to burn).

I have not burned money lately, but SSDs are the shizzle!

I have had so many problems with hard drives, especially brand new in the box hard drives, that SSDs are my new best friend. The weird problems with bad hard drives have driven me crazy in the past. The price for SSDs is easy for me compared with the insanity of bad hard drives and their funky errors.
 
When you do cat /proc/scsi/scsi, what bus is your drive on?

Code:
~$ cat /proc/scsi/scsi
Attached devices:
Host: scsi4 Channel: 00 Id: 00 Lun: 00
  Vendor: ATA      Model: M4-CT064M4SSD2   Rev: 0309
  Type:   Direct-Access                    ANSI  SCSI revision: 05
Host: scsi6 Channel: 00 Id: 00 Lun: 00
  Vendor: TEAC     Model: DV-28S-V         Rev: 1.0B
  Type:   CD-ROM                           ANSI  SCSI revision: 00

And previous command:

Code:
~$ dmesg | grep scsi[0-9]
[    9.722356] scsi0 : ahci
[    9.722536] scsi1 : ahci
[    9.722607] scsi2 : ahci
[    9.722701] scsi3 : ahci
[    9.722796] scsi4 : ahci
[    9.722870] scsi5 : ahci
[    9.909614] scsi6 : usb-storage 1-5:1.0
[   10.949514] sr0: scsi3-mmc drive: 24x/24x cd/rw xa/form2 cdda tray
 
All right, so it looks (vide: scsi4) like changes you were making were _not_ meaningless...
yet, not surprisingly, they didn't make a lot of difference.

What SATA port is your drive connected to? Wondering if we could identify a pattern
here.
 
Installed into the backplane of the SM server chassis.
I think it would be difficult to track down unless I pulled each cable going from BP to MB one at a time.
Unless you have a better idea!
 
I ran this on both settings. I read about 3500M average transfer rate regardless of setting.

Just noticed this but you need to run hdparm with -t not -T. The uppercase -T is not testing your disk - it's testing your cache speed so it's cpu/ram based testing. Use the lowercase -t to actually test the drive.
 
Just noticed this but you need to run hdparm with -t not -T. The uppercase -T is not testing your disk - it's testing your cache speed so it's cpu/ram based testing. Use the lowercase -t to actually test the drive.

Ok. Using -t they all average about 260MB.
 
What SATA port is your drive connected to? Wondering if we could identify a pattern here.

Actually, looking in the SM manual, it points to the drive bay I am in as SAS/SATA Port #4.
 
Unless you have a better idea!
Core32, nope, not really. You could employ divide & conquer algorithm though :p
I'll check mine tomorrow when I'm home. No biggie.

Just noticed this but you need to run hdparm with -t not -T. The uppercase -T is not testing your disk - it's testing your cache speed so it's cpu/ram based testing. Use the lowercase -t to actually test the drive.
AHCI is not really a disk mode, it's controller interface mode; I'm not expecting -t to make a difference either (whether you touch the platter or not doesn't matter as AHCI operates on whole 'nother layer)...

Actually, looking in the SM manual, it points to the drive bay I am in as SAS/SATA Port #4.
EDIT: and they start at 0, don't they? I'll venture a theory that SATA0-3 == always AHCI whereas SATA4-5 -- configurable in BIOS.
 
Last edited:
Back
Top