Now that Vista Release Candidate 1 is available, it's time to start playing with it. I'm tired of using my current legacy operating system. Testing Vista probably means I'll probably be booting from an external hard drive.
I’ve found the best way to test Vista is using VMWare. It is free, it works, and it allows me to share the same data between XP and Vista, to play around with it. Vista seems a bit slow, but I think that’s because Vista is a bit slow, not because of VMWare 
Bits are technically more correct, as it the actual unit of transfer (it is SERIAL ATA after all); plus, with parity and overhead, the bytes per second start to sound pretty small.
How many people actually get 100mBITps throughput on their Ethernet wire? Same for SATA. Parallel cables actually have extra paths for the extra bits, but you can’t beat the form factor of serial…
If you can get Vista working off an external, I’d love to know how, based on the hoops you need to go to in order to do this with XP.
http://www.ngine.de/index.jsp?pageid=4176
(in fact, i’m pretty sure you can’t with Vista).
Do you mean you’re going to install Vista on the external hard drive? I’d be interested to know if you can get that to work. There have been numerous reports in the blogosphere about how they couldn’t get earlier Vista builds to boot from external drives. I’ve not heard anything about RC1.
Kevin: if the drive is just outside of the case, but connected with an eSATA connector to the motherboard, it’s not exactly like having a regular external drive. Basically if Vista wouldn’t boot in the setup that Jeff’s describing, it wouldn’t boot at all in that machine.
People may be having trouble booting from USB or FW drives I’ve not heard. I thought that OS’s usually had to be modified to deal with that. (i.e. they have to “know about” USB or FW disks much earlier in the boot cycle)
I’m not trying to fan the flames of a holy war here, but …
Why do people still use bits insteads of bytes for data transfer statistics?
I mean, what still actually transfers bits instead of bytes? Some compression algorithms, sure. Some cryptography algorithms, alright. But the logical unit of transfers to hard drives and anything on the network above Layer 2 has been bytes for how long now? And are bits still a useful unit of measure, even for crypto or compression? Can you even get a hard drive to transfer bits instead of bytes?
Is it just to inflate the numbers? Is it because 480Mbit/s sounds so much sexier than 60MB/s?
Personally, bytes just seem to make more sense. We talk about data storage size in terms of bytes, so why don’t we talk about data transfer size in terms of bytes?
Rick O: It’s the “Big number factor” if you’re sleepy and haven’t had your morning coffee (or are the average Best Buy shopper) which do you think is better: 480gigglewhoozits, or 60whatchmagiggers?
An alternative explanation is that since bandwidth numbers are usually attached to serial devices, the number of bits per second is a pretty fundamental measurement. Granted, you can still talk about bytes per second, but the fundamental unit of transmission in a serial situation is the bit. (Now, why parellel transmissions would be labled that way, I don’t know. Inertia I guess.)
Rick-- yes, megabits are annoying. I totally agree.
As far back as I can remember, transfer speeds have always been in bits per second. I think it’s because you’re talking about how fast the line can switch back and forth from 0 and 1, but that’s just an educated guess.
I imagine it’s how we started, so we’ll just keep doing it that way.
My understanding from back in the BAUD days (the B there stands for “bits” as well), is that not all information transferred is client data. For a serial interface (which SATA is), only one bit at a time can go across, so the client data bits have to wait for the overhead bits. Since how much of that information is client data can vary depending on what settings are used and what kinds of things the client is doing, reporting the rate in bits is more accurate (or less subject to cheesy manipulation by marketing weasels) than trying to report it in Bytes would be.
This could be obsolete information though.
ACK.
I wasn’t sure about the Baud thing I posted above, so I went and looked it up. Its possible I could have been more wrong, but it would have taken some work. Since we can’t edit our posts here, I’ll just say everything I said about Baud above should be ignored. Read http://en.wikipedia.org/wiki/Baud for the skinny.
You won’t see the benefit of Raptors when (like every other Western Digital drive I’ve had) they die on you.
One other interesting note with eSATA enclosures is that you can attach them to a number of cable DVRs. For example, the Scientific Atlanta 8300HD has a 160GB internal drive and an eSATA port. That much space is fine for SDTV programming (60+ hours) but not much for HD (20-30 hours), so an external drive is useful. Unfortunately, the format isn’t compatible with a PC, so you can’t transfer the files anywhere.
I think it’s one of the few ports on the cable box that’s enabled - mine has firewire, USB, and an IR port all disabled.
My 2cent Warning:
I use firewire drives daily for storing loads of different vm’s (performance is better than usb, and I have a laptop) and was pretty worried when XP SP2 broke some spb2 devices.
http://www.bustrace.com/delayedwrite/
These guys wrote a free “1394 Delayed Write Stress Tester” for the purposes of trying to force the error to show up.
If you can get Vista working off an external,
Steve, there is effectively no difference between an internal drive connected via SATA and an internal drive connected via eSATA.
If this doesn’t work, then Vista won’t work with any computer that uses a SATA drive… which rules out most of the known world. 
You will have to tweak the boot order of your hard drives in the BIOS, though.
Jeff - good point on eSata enclosures. I was thinking about USB/Firewire externals.
Time to replace my usb ones with esata…
I will second the Raptor drive recommendation. Since installing one as my system drive boot times are two thirds what they used to be and the system is more responsive to interaction while my startup tools are loading. Very noticable improvement with virtual memory (next upgrade is from 1GB to 2GB to avoid using it at all).
While we’re at nitpicking and inflating numbers using impractical units of measure why not return to nibbles, then we can quadruple the numbers and still be truthful. Honesty, very few people would recognize the archaic unit of measure and would probably think that we’re rocketing into virgin territory with our capacities and throughputs. OH… while we’re at it lets get the MB to equal 1048576 (the actual amount) and not 1000000 (used to inflate hard drive sizes). Ask Western Digital, they learned that one the hard way!!
Jeff,
In one of your posts, I notice you recommended a 10,000 RPM raptor as a boot drive in combination with 2 7,600 RPM drives in Raid-1 configuration as data drives.
I was under the impression that every disk you add in a Raid-1 setup increases your read speed by the number of disks you add. So, wouldn’t having the OS and virtual memory installed on 2 7,600 RPM drives lead to faster booting and general file access than having the OS on the 10,000 RPM drive? Given this, why even have the 10,000 RPM drive if you have a RAID-1 configuration?
I’m looking to build a Core 2 Duo system of my own soon and I want to clarify this before I spend an extra $120 on the 10,000 RPM drive :-).