How bad is 60MB/s for a boot drive

Solution
It's a respectable streaming speed for an older drive. It's a little slower than a first-generation WD Raptor (a quick test shows that the venerable WD740GD in the PC I'm using now pushes 67MB/s; for comparison, the other drive, a recent 500GB DeskStar, manages 145MB/s).

The factor that will affect boot (and application startup) performance most strongly is not streaming speed but average seek time - the average time it takes the drive to get the disk heads to the right location on the disk to retrieve a file (which entails both moving the heads to the right track and waiting for the disk to turn to the right sector). A typical 7200rpm desktop hard drive has a seek time of around 8.5ms (1ms = 1/1000 second). The WD740GD comes in at a...
It is not bad unless you use it up.
With ONLY windows, you are ok,
You will actually only have 54gb or so available to you.
Once you get past 90% usage, the ssd has to work hard to find a free block to do an update quickly.
At current prices, you are really much better off with a comfortable 120gb.
That gives you room for other things that want to go on the C"C drive normally.
 

molletts

Distinguished
Jun 16, 2009
475
4
19,165
It's a respectable streaming speed for an older drive. It's a little slower than a first-generation WD Raptor (a quick test shows that the venerable WD740GD in the PC I'm using now pushes 67MB/s; for comparison, the other drive, a recent 500GB DeskStar, manages 145MB/s).

The factor that will affect boot (and application startup) performance most strongly is not streaming speed but average seek time - the average time it takes the drive to get the disk heads to the right location on the disk to retrieve a file (which entails both moving the heads to the right track and waiting for the disk to turn to the right sector). A typical 7200rpm desktop hard drive has a seek time of around 8.5ms (1ms = 1/1000 second). The WD740GD comes in at a very respectable 4.5ms. A fast 15,000rpm hard drive may reach 3.5ms. An SSD doesn't really have a "seek time" as such but there is some latency from other factors which can be seen as being equivalent to it and which typically comes in at somewhere below 0.1ms. These numbers all sound very small (what's a few thousandths of a second?) but booting a PC up involves accessing many files, meaning that the thousandths add up thousands of times over to give "real world" times we can measure by looking at the clock on the wall.

A little anecdotal evidence: The latest-generation VelociRaptor serving as a boot drive in one of my PCs (which streams at over 200MB/s and has a rated seek time of 6.8ms) is completely pwned (technical term) by the CompactFlash digital camera memory card serving as a hard drive in my 9-year-old laptop - a race from boot menu to login prompt is frankly embarrassing. That card streams at "only" 75MB/s over its Ultra ATA 100 interface but has negligible access time compared with the mechanical hard drive. A "real" SSD would perform even better.

Keeping the boot partition as small as possible helps to reduce the average access time for a mechanical hard drive by limiting the "stroke length", the distance the heads have to seek (it's called "short stroking") and thus improves performance. Of course, it also comes with a convenience/complexity cost - you have to choose the size of the partition carefully to ensure that you have sufficient space for everything you want to keep on it and ensure that everything else gets redirected to somewhere else. There's usually no performance benefit to be had from doing this on an SSD although there can be benefits at the OS level from keeping the file-system structures smaller and simpler.

I remember when Windows 2000 was released, I got very excited about the new "mount points" feature that promised to make this much easier - I was able to have "C:\" (including "C:\Windows") on a small partition at the start of one physical hard drive, "C:\Program Files" on another and "C:\Documents and Settings" on yet another and programs would be none the wiser. It was never quite as simple as it seemed - mount points just don't seem to be completely transparent and you get some strange and hard-to-troubleshoot issues. (As usual, it "just works" on Linux - it's a fundamental design feature of the file system on Unix-style OSen.)

This can now be done much more robustly during Windows setup using unattended install response files - I use this to move the Profiles folder to the D: drive on PCs at the school where I work, mainly to keep them from "polluting" the C: drive (which I am able to keep almost completely write-protected for non-Administrators) but I get the benefit of short stroking into the bargain, which can make a substantial difference when your Win7 installation is small (our standard Win7 x64 image fits easily into a 40GB partition; the x86 one fits in 20GB) and the destination drive is big (our latest PCs came with 500GB disks).

I'd better sign off now before this turns into a full-blown article... :)
 
Solution