26 Comments

The WD6400AAKS-00A7B is very fast with no access time problems at all.

Here are the Benchmarks.

HD Tune 3.00 read transfer rate

Minimum 51.1 MB/sec

Maximum 108.4 MB/sec

Average 87.6 MB/sec

Access time 12.5ms

Burst rate 90.2 MB/sec

CPU usage 9.5%

It near silent and cool running.

After partitioning the drive in Windows Vista there will be 595GB left of the original 640gb.

Just a thought. Looking at HD tune benchmark graph. The drive does not loose much transfer rate over the first 30% of the drive. The first 30% shows a transfer rate of 108-98 MB/sec. So if you only make a 200gb partition, the drive will be faster than a 150GB Raptor except for the access time.

I made 2 partitions. One 195gb for windows and my favorite games and one 400gb for storage. I have never had a faster computer!

I'd like to see some comparison of XP64bit vs Vista64. SP1 has been delayed (yanked that is) and shows no signs of performance improvement anyway (if betas are to be believe there is no improvement). So why can't we look to something that has been 64bit for quite a bit longer and should have better drivers to boot? How about some XP64 testing for a change? If nothing else it should drive traffic to the site (isn't that the point of a website?) just because NOBODY else is doing XP64bit vs. Vista64. Why no love for XP64? With only 18% of Steampowererd.com using Vista why test in it? I don't really care if it ships on a PC when people run home and format and install XP. Shouldn't we see testing in the OS that 80% of the people use? Why cater to 18% of the market? Most of those people still have Vista because they don't know how to format and install XP (ok, maybe 1/2 of those people actually want that OS and like it). Until they remove DRM garbage and fix networking this OS sucks. Don't even get me started on application problems (SP1 BROKE 3rd party apps like Trend Micro for example). Search google for this for a complete rundown: vista sp1 3rd party apps

I just want to know, is it work going to XP64bit for my 6GB to show up in XP? Or are we stuck with Vista? Do games run as faster or faster in XP64bit as they do in XP32? Reply

The screenshots seem to be from HDTach RW, so why didn't Anadtech run the STR test on _all_ disk sectors, instead of using the "zones" approximation (the graph is clearly that of a "zoned" test, not a full one)? Sure, it can take over one hour, but can't you spare more than 5 minutes for an article that's going to be read by thousands of people?

Running a full test (2 or 3 times) is the only way to spot drives that ship with remapped sectors (ie, some sectors already mapped to the spares, in a non-sequential way), which can cause problems in high-performance situations (such as video servers).

Western Digital's 400 GB "RE" drives had lots of problems with that. The 500 GB "RE2" were better but some still came with remapped sectors. These show up as (consistent) "dips" in a full STR test (as done by HD Tach RW and WB99, for example), but won't be noticeable in a "zoned" test (which is the only kind available in the free version of HD Tach, and most other benchmarks).

Oh, and the fact that the rest of his reply was completely inaccurate. Actually the only thing in his post that wasn't "wrong" was his joke about the 30 seconds. On second thought, taking into consideration how poor his post was, you may be right. :) He could be serious... Reply

Actually, there was a post in silentreview.com[1] that Samsung discovered the MC error detected by Samsung's HUTIL was caused by version 2.10 of the utility being incompatible with F1 drives. If there is any doubt about the drive's problem, you should wait for the HUTIL update.

"Testing 4 of these in raid 0 and 5 in raid 5 would give me an orgasm. "

No they wont, because multiply that horrible access time by however many drives you plan to add. Your sustained transfer will be good, but it'll take 30 seconds just to bring up a large directory of files.

And forget extracting rar's from and to it.

RAID arrays are good for a collection of drives with low access time and average at best sustained transfer rates. ie, Raptor's. The low access time makes up for the fact your multiplying it, and the sustained transfer rate's scale with the number of drives you add.
Reply

Apparently you don't understand how access times work, and you don't even understand how file systems work. I suppose the fact that you use the expression "RAID arrays" should be a clue.

You don't need to "multiply" anything; seek commands are sent to all drives at the same time. You will have to wait for the _slowest_ one, but that's still only the (maximum) seek time for _one_ drive.

And reading a directory means reading only a couple of meta-files (typically placed at the middle of the drive, in modern file systems, so head travel times are never more than 50%). The system doesn't scan the whole disk looking for files; it only needs to read the file table. For large (multi-sector), contiguous file tables, that means arrays can actually read them _faster_ than single drives.

Finally, most operating systems cache large chunks of the file table, so chances are you don't have to wait at _all_. The time you need to wait when displaying large directories in Windows Explorer, for example, is the time it takes to sort the data (by name, date, size, whatever) and prepare to display it (generate the icons, build thumbnails, etc.). Actual directory access (ex., for a program trying to save a file) is virtually instant.
Reply