SSD Slow Speeds

F

falkman

Greetings fellow Daemons,

I just purchaced an SSD a few days back which boasts 285MB/s read, 275MB/s write, and 250MB/s sustained write. I happened to try out the nice little bugger on FreeBSD, where I got about 80MB/s sustained write (10GB file, 4096 byte blocks), where on Linux I happened to get 251MB/s sustained write (same file, same block size). I'm trying to figure why this is happening, and how to potentially fix it. Any suggestions? I really do not want to use Linux :P.

Note: My drive is being recognized as SATA150, as it clearly is SATA300, and Linux shows that all the hardware is capable of running at that speed.

Thanks in advance,
falkman
 
What are your BIOS settings, do You have enabled AHCI in BIOS (along with FreeBSD AHCI module loaded)?

Also, SSDs are mostly about random read/write performance as this matters the most, sequential transfer is not all that important.
 
falkman said:
I just purchaced an SSD a few days back which boasts 285MB/s read, 275MB/s write, and 250MB/s sustained write. I happened to try out the nice little bugger on FreeBSD, where I got about 80MB/s sustained write (10GB file, 4096 byte blocks), where on Linux I happened to get 251MB/s sustained write (same file, same block size). I'm trying to figure why this is happening, and how to potentially fix it. Any suggestions? I really do not want to use Linux :P
Click to expand...
What version of FreeBSD is this? At least through 8.1-PRERELEASE, there doesn't seem to be any support for TRIM (pre-erasing unused blocks). That shouldn't matter on a newly-installed, erased SSD though. It will only start impacting performance when previously-written blocks need to be overwritten.

Have you tried running a comprehensive benchmark like IOzone to see where the performance problems lie?

Because of the TRIM issue (and a lack of drive mounting positions), I selected a PCI Express SSD (the OCZ Z-Drive R2 p84). I'm seeing 500MB/sec numbers on sustained I/O (8GB and larger filesize). IOzone plots out to 64GB here. (The "cliff" where performance drops off in the middle of the graph is due to exceeding CPU cache, the FreeBSD buffer cache, and/or the controller's buffer, depending on which plot you look at.)
 
Terry_Kennedy said:
What version of FreeBSD is this? At least through 8.1-PRERELEASE, there doesn't seem to be any support for TRIM (pre-erasing unused blocks). That shouldn't matter on a newly-installed, erased SSD though. It will only start impacting performance when previously-written blocks need to be overwritten.
Click to expand...

It is FreeBSD-8.0. I'm installing FreeBSD right now, so if anyone wants some nice info/dumps I can gladly give them.
 
vermaden said:
What are your BIOS settings, do You have enabled AHCI in BIOS (along with FreeBSD AHCI module loaded)?
Click to expand...

I happen to not have an AHCI setting in my BIOS, and Linux isn't picking up that it is existent either, but there must be something that Linux is finding that FreeBSD is not, because the sequential r/ws are almost meeting the drive specs on Linux, while 25% of them on FreeBSD. It does seem that on Linux the drive is operating at SATA300, and on FreeBSD it is operating at SATA150, even though the controller is detected as SATA300.

The quest continues...
 
Terry_Kennedy said:
What version of FreeBSD is this? At least through 8.1-PRERELEASE, there doesn't seem to be any support for TRIM (pre-erasing unused blocks). That shouldn't matter on a newly-installed, erased SSD though. It will only start impacting performance when previously-written blocks need to be overwritten.
Click to expand...

Could speed diffences be due to the 4k block size and alignment? Or does that not make any difference with SSDs?
 
You should not use partitions at all, or correct partitions bad alignment with BSD labels.

Normally, a partition starts at offset 63 (31.5KiB). By increasing the BSD label offset by one, it would start at offset 64 (32KiB) which is better - but not perfect. 128KiB or 1024KiB chunks should preferably be used to align to. So any start offset has to be a multiple of 128KiB (Intel) and 1024KiB works well with Indilinx SSDs as these have bigger erase block size (512K+). So to align to 1024KiB (like Vista/Win7 do), the BSD disk label has to start at offset: 2048 - 63 = 1985.

So you end up with:

/dev/ad4 -> aligned
/dev/ad4s1 -> partition, unaligned
/dev/ad4s1a -> partition, aligned

I noticed BSD complains when you don't adhere to the older CHS-addressing boundaries. I hope that will be cleaned up soon and removed, as it no longer bears any relevance to either modern HDDs and certainly not SSDs.
 
Right, it looks like I will be reinstalling BSD on this machine as I'm bored today, and I feel like figuring out this alignment. So I'll plan on using 1024KB alignment, and possibly I might try out zfs for once. Would it be a good idea to use zfs, or should I just stick with UFS2?
 
As long as you use the 'production' version of ZFS as released in FreeBSD 8.0, yes i think that works quite well.
The unstable ZFS version 6 that is still in use by FreeNAS is buggy though, generally you should avoid it.
 
Hi Falkman,

Can you let us know if there was any performance improvement after the alignment? And how your disk slices/partitions are actually set up now.

I'm also interested in buying an SSD for my personal laptop; and switching from Ubuntu to FreeBSD (which I use at work) at the same time.
 
I've been doing tests with raw writes using dd so alignment is not a problem. I found out that my 4096 byte block sizes that I used for testing was just not working too well for FreeBSD. I managed to get about 218MB/s write speeds using 409600 block sizes, but still, I should be able to get more than that, and I shouldn't have to use such a large block size. Sadly, I'm still searching for answers.
 
falkman: note that dd is single queue / single threaded. A filesystem will read from the disk with 128K maximum blocksize; but it would issue multiple of those 128K requests at once. This is called multiple queue depth and it is required to gain all potential performance out of parallel I/O devices like SSDs and striping RAID arrays.

Quite often you could see a difference in speeds when doing a dd on the raw device (/dev/...) or when doing it on a mounted filesystem (/mnt/..). This is because the filesystem uses all optimizations like read-ahead and write-buffering.

But i wouldn't say testing with dd and a large blocksize is unrealistic. Generally, if you want to test sequential performance, use a blocksize of "1m" meaning 1MiB (1024*1024). That would be comparable (but not identical) to how a filesystem would deal with non-fragmented contiguous files ("sequential I/O").

So with the right dd commands, you should see 250MB/s read speeds and 200MB/s write speeds when writing zeroes. Note that your Sandforce-based SSD applies compression to writes; so writing random/binary data would be much slower at 100MB/s (which is how fast your SSD can REALLY write; the 200MB/s is only with easily compressable data).
 
You must log in or register to reply here.
Back
Top