SSD is far slower in laptop than in desktop? Any ideas?

Ok, so I replaced the hard drive in my new laptop. I noticed a bit lower speeds in hdtune than I was initially expecting.

Here's the lappy: http://usa.asus.com/product.aspx?P_ID=ZfpnPRZ5UxVOtrHJ

Specs are:

HM55 chipset (most important to this thread IMO)
i7 720qm
4gb ddr3 @ 1066

I added an x25-m g2 just yesterday...

So here's the hdtune result from the lappy directly (w/ssd installed):



And here's the same ssd in my desktop:



Each time the drive had windows 7 installed on it. It went directly from the fully functioning laptop to the desktop (as a second drive).

Any ideas? Tha lappy has the latest chipset driver from intel as well as all the ancillary drivers.

I was expecting a mobile h55 to be pretty close to the speed of an x58? They're both reasonably new tech, right?

Just to compare, here's my 120gb ocz, with windows 7 on it, in my desktop:



So, any ideas to get my lappy running faster? I checked in the "info" screen in hdtune, and I am running at sata 2 speed. Teh driver is the newest from intel:



So, is this as good as it gets? Can I attribute the speed drop to the fact that it's a mobile chipset rather than destop?

Preemptive thanks

Your lappy is definitely running at SATA1, not sure why though. Did you set SATA to AHCI in bios? Starting with Intel ICH8M and above, it does SATA2, ICH7 and below are SATA1 or PATA...

Thnx for the response.

Yup. It was ahci by default.

Even though it says "generation 2" in the matrix manager?

yeah, it's weird. I have an older laptop and it shows same results as you, and it's SATA1-limited. My newer one works at SATA2 and it's just as fast as my desktop in terms of SSD performance. Might wanna try contacting ASUS support as yours must be working at full speed too but for whatever reason it doesn't.

here's a few hdtach results. Does it confirm your suspiscion?

yes, of course. Like I said, contact support, something is definitely fishy with your laptop.

mega suck. Thanks for the help. Will hit up the asus boards. Nothing in search yet.

funny similar thread I just found.

http://www.ocztechnologyforum.com/f...GB-Slow-4K-Read-Results-on-Asus-G51J-Notebook

nah not fishy at all. dell and other manufacturers will limit the motherboards to sata 1 speeds even though the chipset is capable of sata 2. they do it to save power and also because they figured that there wouldnt be drives that would need the sata 2 spec. remember that most lappy hdd are 5400 rpm. there are some that oyu can unlock in the bios, and others that you will have to find a modded bios to unlock it. however, on some, like mine, i am screwed. oh well you still benefit tremendously from better access time.

grrrr.

Might roll back to old bios to see.

Computurd said:

nah not fishy at all. dell and other manufacturers will limit the motherboards to sata 1 speeds even though the chipset is capable of sata 2. they do it to save power and also because they figured that there wouldnt be drives that would need the sata 2 spec.

Click to expand...

I dunno, I have a 3.5 year old dell laptop, and it works just fine at SATA2, and I did go through every other official BIOS update. Intel SSD is blazing fast on it.

My issue is that this is a two week old -new- lappy. It has been pretty badass up to this point. Replaced the old (7200rpm) drive and plop right on it's face it goes. Not particularly slow, just not $200 faster.

I had this problem on a new Sony Vaio F. I put an Intel X25-M G1 drive and was getting 9MB 4K reads. Pop it into my desktop, run the same tests and get 22MB 4K reads. I hear some people with HP Envy's have this issue too.

conclusion: get an older laptop j/k of course but I think complain to support first and then try to find an 'unofficial' workaround.

:[ grrr

you will find the light at the end of the tunnel is dim with this issue, unfortunately. my laptop is new as well. this is not something they were doiing, this is ssomething they continue to do. and dell arent the only ones doing it. NOW if you want to buy a laptop with a ssd already in it, and pay serious cash, you can get the sata 2 speeds. this is marketing at its very finest guys. if you dont have ssd preinstalled it is hard to find lappies that actually run the spec. dude google it for about two minutes, you will find all you need to know about this bullshit.

it SAYS sata 2 but it doesnt run AT sata 2. That is why yer numbers look mysteriously EXACTLY like sata 1.

I posted on the asus forums. I really don't expect a response, as most threads seem to die as soon as they're posted.

It is common, and as someone said before, the reason is power saving. The chipset simply runs in slower speed mode, which is ok for hard drives, but not for SSD. I experienced the same result with my Toshiba laptops (M800 and U500).

Still, the sequential read is not the main point of SSD, it is the access time which makes the biggest gains and that is still OK even with the low-power mode chipset.

well if it makes you feel any better, it's still way faster than any hard drive

Sequential speeds dont matter for an OS.
Secondly its faster than any HDD

You can try to get your mobo to SATA2, but its not like your going to notice better performance in real world use.

Sure it will bench better...but that doesnt really matter.

Yeah, I am fine with it. It is fast enough for me, I just wanted to make sure I couldn't do anything to make it better (working properly). I have accepted the fact that there's nothing I can really do about it.

Thanks everyone for your help, comments, and ideas.

yeah see here is the deal, mine works great too! even at sata 1 your not going to be doing much to really utilize the sequentials. it is just a lappy after all still very very good upgrade for a laptop. i would still do it again.

I can tell you from experience, SATA1 does limit the performance. I'm running two laptops, one with SATA1 and one with SATA2, both on Intel SSDs and the SATA1 is noticeably slower. It does have a slightly slower CPU but both have same amount of RAM (4gb) and same OS (win7). At first, I couldn't figure out what's the problem was but once I've ran benchies (mind you, AFTER I noticed that it's slower) I've established that one is running at SATA1 and the other is at SATA2

Update: I uninstalled the intel matrix storage manager, just to see...



Looks a good deal better than my old results. Definitely not sata 150 limited...

that looks like sata 1 speeds to me bro. sorry. your average speeds are right at sata 1. disregard max numbers, they are burst. yer bonered on the deal.

awww. was getting hopeful too.

even @ 168 average? Thought it was capped at 150.

every board is different. might do slightly over 150. if you measure with other benchmarks you will see. do this:

elevate a cmd prompt to admin status, then open
once open type in :

winsat disk


then post the results.

I wonder if your issue is related to mine.

my new laptop....

HP Envy 15 with 2x intel 160gb SSD's (G2) in RAID 0 32kb stripe with WB cache enabled)
Aren't I supposed to see ~500+MB/s here???

HDTUNE:


350MB/s

sigh, I might have to unRAID and try to figure this out...

I think the difference in the numbers you are getting is because in the laptop the SSD is the boot/OS drive and constantly working and in the desktop the SSD is a secondary drive that's just hanging out untill you access it, that does seem to have a effect on these drives !

oldbrave said:

I think the difference in the numbers you are getting is because in the laptop the SSD is the boot/OS drive and constantly working and in the desktop the SSD is a secondary drive that's just hanging out untill you access it, that does seem to have a effect on these drives !

Click to expand...

But my desktop runs an 80gb G2 as the main boot drive, with indexing, superfetch, page file all enabled and running and it still gets over 250 sequential...

32KiB stripesize will wear your SSD more and makes no sense really; anything below 128KiB is wrong.

Also, do not test with single queue depth benchmarks like HDTune and HDTach but use ATTO, HDTune Pro File benchmark, AS SSD or CrystalDiskMark.

sub.mesa said:

32KiB stripesize will wear your SSD more and makes no sense really; anything below 128KiB is wrong.

Also, do not test with single queue depth benchmarks like HDTune and HDTach but use ATTO, HDTune Pro File benchmark, AS SSD or CrystalDiskMark.

Click to expand...

Whoa.. how is that? Will a larger stripe size also serve to fix my sequential read speeds? I thought it's the large stripe sizes that cause wasted data, performance as a full stripe would need to be read for even the smallest 200 byte file.

32KB not set by me but the setting done by factory / HP engineers...

Here is some interesting info from the help on raid stripe sizes with intel Rapid Storage Technology:



They seem to set smaller stripe for SSD, 16 kb default, while my laptop was 32kb from the factory.

I am not really familiar with stripe size and its impact on performance and wear. I have run 128KB and 256KB for the RAID 6, RAID 5, RAID 0 arrays in my desktop with 6X WD6400AAKS and now 4X WD15EARS. I chose 128/256 for those applications because they benched the best when I tested HDTUNE & HDTACH on those arrays.)


Thanks.

With striping RAID, to achieve a reasonable benefit, you have to make sure every I/O done by your operating system is handled by one physical disk; not multiple disks.

Thus, if the OS reads a 128KiB chunk, it would only have to read that from a single device in the array, leaving the others free to handle other I/O in parallel if there are queued I/O's. This also causes less wear on the SSDs; as when writing 32KiB to an SSD you're actually writing 128KiB physically as Intel SSDs have 128KiB erase blocks. Using a 128KiB stripesize makes sense in this case; the SSD wants to see 128KiB writes.

A common misconception is that you cannot transfer anything smaller than the stripesize; this is not true. On FreeBSD, if you have a 1 Megabyte stripesize and you read 512 bytes; it will only cause 512 bytes of physical I/O and not read the whole stripe. Some windows-drivers do this, however, as a quick and dirty optimization technique. It totally destroys the IOps performance, though.

So 128KiB stripesize would be the optimal stripesize i think. Perhaps you should post some benchmarks with AS SSD and CrystalDiskMark (random I/O) and then re-configure the RAID with 128KiB stripesize and see what that changes.

In my benchmarks, a larger stripesize yielded the best random I/O results in multiqueue benchmarks:
http://submesa.com/data/raid/geom_stripe
(scroll down to Stripe Size Influence)

sub.mesa said:

With striping RAID, to achieve a reasonable benefit, you have to make sure every I/O done by your operating system is handled by one physical disk; not multiple disks.

Thus, if the OS reads a 128KiB chunk, it would only have to read that from a single device in the array, leaving the others free to handle other I/O in parallel if there are queued I/O's. This also causes less wear on the SSDs; as when writing 32KiB to an SSD you're actually writing 128KiB physically as Intel SSDs have 128KiB erase blocks. Using a 128KiB stripesize makes sense in this case; the SSD wants to see 128KiB writes.

A common misconception is that you cannot transfer anything smaller than the stripesize; this is not true. On FreeBSD, if you have a 1 Megabyte stripesize and you read 512 bytes; it will only cause 512 bytes of physical I/O and not read the whole stripe. Some windows-drivers do this, however, as a quick and dirty optimization technique. It totally destroys the IOps performance, though.

So 128KiB stripesize would be the optimal stripesize i think. Perhaps you should post some benchmarks with AS SSD and CrystalDiskMark (random I/O) and then re-configure the RAID with 128KiB stripesize and see what that changes.

In my benchmarks, a larger stripesize yielded the best random I/O results in multiqueue benchmarks:
http://submesa.com/data/raid/geom_stripe
(scroll down to Stripe Size Influence)

Click to expand...

I like your logic and intuition on that. I'll give it a try. I am using the Intel controller to handle the RAID, so hopefully it can properly handle sub-stripe size I/O requests. One question, though, did you just choose 128KB because of the erase block size? I ask because I think the Intel G2 erase block size is actually 2048KB (could be wrong here)

Need to make sure to do some good testing and get good results from this 32kb setup before moving to 128kb for more benching. If it does bring me back to 500MB/s sequential read I may reconsider breaking the array and keeping RAID 0 at the larger stripe.

whoa whoa whoa
@sub.mesa...bro you have absolutely no idea what you are talking about. you should not post on subjects that you know nothing about.
INTEL themselves recommend a 16k stripe size. there is no harm, and i mean zero, in running a 32k stripe size. as long as you are above 4k you are fine. 4k is the size of the blocks on the SSD, using LBA (Logical Blcok Abstraction) the ssd will allocate the space necessary. if you ran some real tests, and knew how to read the results, you would see that real world results are best with smaller stripe sizes.
to say that you want only one disk, not multiple disks, to handle the I/O is the most ludicrous thing i have ever heard. that goes against the very principle of raid. RAID is used for increasing I/O by readsing from multiple disks SIMULTANEOUSLY. your nice little link, when read by someone who knows what they are looking at, proves you have no idea what you are talking about. you need to go hit the books. your line of reasoning is totally flawed.

LOL the more i read your link the more i am laughing. do you even know what NCQ is, or how it functions? you think it limits the number of seeks! LOL
and what is this retarded insistence that the I/O being handled by one drive, so the other ccan handle I/O? jesus! your whole understanding of parralel I/O, is again, flawed.
have you heard of asynchronous I/O?

Computurd said:

whoa whoa whoa
@sub.mesa...bro you have absolutely no idea what you are talking about. you should not post on subjects that you know nothing about.

Click to expand...

I usually do not respond well to posts like this. But, i will do reasonable efforts to try and convince you. So that hopefully, you can correct your own mistake.

INTEL themselves recommend a 16k stripe size. there is no harm, and i mean zero, in running a 32k stripe size. as long as you are above 4k you are fine. 4k is the size of the blocks on the SSD

Click to expand...

512 bytes is the sector size of Intel SSDs. 128KiB is the size of the erase blocks on Intel SSDs. That means if you modify 512 bytes, the SSD has to read 127.5KiB+erase the block+write 128KiB.

Now let's see what happens when we modify 64KiB of data with 32KiB stripesize assuming perfect alignment:

SSD1 gets request write 32KiB (part a) -> has to read 96KiB+erase 128KiB+write 128KiB
SSD2 gets request write 32KiB (part b) -> has to read 96KiB+erase 128KiB+write 128KiB

Intel SSDs are actually pretty smart, though. They can remap small writes to spare area and not having to modify data which is very slow on any SSD. But your erase blocks will wear out, causing this trick to stop at some point. Then you fall back to very low random write performance, even on Intel SSDs.

I achieved best results with a stripesize of 1 megabyte. This gave best random I/O performance with request sizes ranging from 4096 bytes to 128KiB. Unlike some bad quality Windows RAID drivers, if you read 512 bytes on a good RAID0 driver, it will read 512 bytes and not the whole stripe block. Otherwise, high stripesizes would actually cause lower performance. Those RAID engines are broken in design.

if you ran some real tests, and knew how to read the results, you would see that real world results are best with smaller stripe sizes.

Click to expand...

Anything wrong with the benchmarks i posted? Any wrong interpretation of its results? I'd love to hear them.

to say that you want only one disk, not multiple disks, to handle the I/O is the most ludicrous thing i have ever heard. that goes against the very principle of raid. RAID is used for increasing I/O by readsing from multiple disks SIMULTANEOUSLY.

Click to expand...

I believe you misunderstand how striping RAID achieves that. Let's keep things simple and assume we are running RAID0 with four harddrives:


Plan A: low stripesize; make sure writes of 128KiB cover all disks; meaning 32KiB stripesize. 4 x 32KiB = 128KiB. So when we read or write 128KiB in a single request, we actually put all four disks to work. This is the method you're accustomed to, i presume?

Plan B: high stripesize; make sure each I/O request lands on one disk alone, keeping the other disks ready for other queued I/O. 1 Megabyte stripesize (1MiB) makes quite sure any request will only work on one disk only.

Now benchmark the two and you'll see some differences:


single-queue sequential I/O (caused by: artificial benchmarks like HDTune, HDTach)
plan A scales well well due to each request involving all four disks, having near-maximum performance. Plan B does not scale well at all and get stuck with a bit more than single disk performance. Due to this kind of performance being a non-issue since it does not occur in realistic circumstances, the performance benefit of plan A is artificial.


multi-queue sequential I/O (caused by: filesystem sequential I/O; benchmarks like HDTune Pro File benchmark, ATTO, AS SSD, CrystalDiskMark, SiSoftware Sandra)
plan A: max speed; more CPU overhead. plan B: max speed; less CPU overhead. The additional overhead is due to unnecessary splits of 128KiB requests into 32KiB or even lower chunks to the SSD.


single-queue random I/O (caused by: blocking I/O or synchronous I/O)
plan A is slower than single disk due to all disks having to seek the average seek time is higher than with just one disk; this has to do with average rotational delay. plan B is exactly or even slightly faster than a single disk; no performance degradation of any kind.


multi-queue random I/O (caused by: non-blocking I/O or asynchronous I/O)
plan A scales very poorly or hardly at all. Plan B scales near 90% efficiency; almost doubling IOps when doubling the amount of disks. This is where huge performance gains can be made by opting for Plan B instead.


I vote for plan B.

your nice little link, when read by someone who knows what they are looking at, proves you have no idea what you are talking about. you need to go hit the books. your line of reasoning is totally flawed.

Click to expand...

Computurd said:

LOL the more i read your link the more i am laughing.

Click to expand...

All truth generally passes three phases:

1) where it is being ridiculed and laughed at;
2) where it is being aggressively disputed;
3) where it becomes generally accepted.

do you even know what NCQ is, or how it functions? you think it limits the number of seeks! LOL

Click to expand...

Native Command Queueing allows for 32 queued I/O's and functions like command buffering. The function was originally intended for mechanical drives to save on seeks by knowing ahead which requests were coming and being able to re-arrange in a more efficient order so it could save some seeks on high queue random I/O workloads.

In Solid State Disks, modern controllers use NCQ (which gets enabled when you enable AHCI mode) to actually process these in parallel. Mechanical harddrives are serial devices; they can only process one I/O on the mechanical part at a time. SSDs, however, can utilize multiple flash channels in parallel and thus really do things at the same time. But for that to work it has to know about multiple I/O requests issued by the operating system. NCQ with its up to 32 queued I/Os will make sure an SSD with 10 flash channels such as the Intel X25-M is properly saturated.

Without NCQ, a modern SSD will have much lower random read. This can be clearly seen with Windows benchmarks like CrystalDiskMark and AS SSD. The 4K Random Read QD=32/64 is barely any higher than the single queue QD=1 benchmark when NCQ is not available, due to the controller being set to "IDE" mode for example. When having AHCI enabled, the QD=32/64 random read tests are up to 10 times higher, close to the number of parallel flash channels the SSD has. The Intel has 10.

and what is this retarded insistence that the I/O being handled by one drive, so the other ccan handle I/O? jesus! your whole understanding of parralel I/O, is again, flawed.
have you heard of asynchronous I/O?

Click to expand...

Asynchronous I/O issues on the application level will result in multiple queue depth on the device level. But if all disks are working on one request at a time, the whole I/O done is serial in nature and not parallel. You would want async I/O or non-blocking I/O + parallel RAID0 = highest IOps gain.

Just because i'm in such a good mood, i ran some benchmarks on two of my Intel X25-V 40GB SSDs, connected via AHCI to FreeBSD. The results confirm very poor random IOps scaling with a low stripesize like 4KiB and very good random IOps scaling with a high stripesize like 1MiB (1 megabyte).

RAIDTEST (tests with sizes between 4KiB-128KiB; random pattern)


RAWIO (tests with fixed sizes 32KiB; random pattern)


So it seems that 1 megabyte stripesize has double the performance of 4KiB stripesize in random IOps. Difference may be even larger with more disks. A low stripesize like 4KiB would tax the CPU to the maximum and makes little sense.

Moral of the story is that you're better off letting each disk handle one I/O and relying on multiple queue depth to saturate all disks.

you are speaking of running Freebsd. these guys arent.
also, for all of the graphs in the world, yes it would be nice if you are running a server or OLEP, but they arent. for desktop usage small stripe sizes own larger ones, in a real world environment, test some games/app loads. for desktop usage your queue depth rarely goes over 2, and most often stays at 1. especially with raid. you are talking about results that are not going to help these guys. for real world usage smaller stripes are better. yes if you are dealing with a QD of 64 it will be better, but how often do you think that arises in real world usage? the most you will see sustained on a desktop is eight, and that is pushing it.
and to say that smaller stripe sizes are bad for drive wear is wrong. period.