Slashdot Mirror
Hard Drive of the Future: Ram Drive
benzick writes "3d Retreat has posted a hands on look at a 2gig ram drive called the Rocket Drive. Article blurb: Overall the rocket drive is the best in I/O performance I have seen. It outperforms U160 SCSI drives by almost a factor of two. Yet there are some drawbacks to the Rocket drive, foremost is the price, although listed at the end of the review is some alternative pricing options to make it less expensive. And the rocket drive can not act as a boot drive. Also, if you have some extra money to spend, you can use multiple rocket drives in parallel."
Product: Rocket Drive (2 gig)
Manufacturer: Cenatek
Web site: Product Information
Price (MSRP): $2,999 (as tested)
Release Date: Available Now
Keeps that data after the pc is turned off, which i bet your amstrad didn't do.
It has an external supply that keeps the card powered.
And i believe this is the whole point of this card, its pretty much useless otherwise.
Also the xfer speeds are limited to PCI (66mhz) speeds, that is why "its only" 2x as fast as a U160 scsi.
This is really pretty interesting. The device has it's own power supply that actually allows you to save data when you shut down your computer. It doesn't seem like it would be too reliable, but it does provide a reason as to why this is better than a traditional RAM drive (provided you have it hooked up to a UPS).
The official website lists the capacity as 4 GB.
i hope they put some sweet memory in there...
I know this article doesn't exactly seem to be chock full of information, but the comments can at least be intelligent.
This is different from using a RAM disk and just using RAM for a disk drive. A RAM drive can actually store information - which is something that RAM disks, which aren't really storage devices at all, cannot do.
This even means you can store stuff and it's still gonna be there when you reboot. Although, granted, this isn't exactly new technology. I remember talking with a company at Internet World probably 6 or 7 years ago that sold these things to big companies with deep wallets.
I've nothing to say here...
The bios is set so you can only put in the amount of memory that was specified by the card. So If I purchased the 2Gig empty card. My only option is to put in 4 sticks of 512 pc133 memory. If I wanted to upgrade my card to 4gig. I would have to pay for an upgrade, and then replace all the sticks of memory with 1024Meg sticks.
I use Macs to up my productivity, so up yours Microsoft!
Back in 1998, Quantum announces a DRAM-based hard drive. They offered two models, a 1.6GB version which was priced at $39,000 and a 1.07GB version which was priced at $28,000. They seemed revolutionary at the time, but the main drawback was always the price.
Most people can't allocate 2GB of RAM for use as cache or RAM disk because their computer can only *take* 2GB or less of RAM. Most PCs max out at between 512MB and 2GB RAM, most Macs max out at 1GB to 2GB of RAM.
I'd suggest a better option would be a fast hard disk or RAID appliance with 2GB of cache.
Wasn't there just a slashdot story a while ago saying how it was Power supplies that were the huge cause?
This maps as an ATA Device. It needs a specific driver, and does not currently work as a boot drive. Regardless, it is supported by Windows 2000, XP, and NT 4.0 Red Hat 7.3 Free BSD Solaris 8/UltraSPARC II As for the power cord? It does not have to be in the whole time. Just while the computer is OFF. Although there are rumors on the Cenatek message board of a rocket drive with an on board battery backup..
This tells you very little about the relative performance of the drives since image processing is typically not disk bound.
Actually, the author of the article made it disk bound, by forcing Photoshop to go into swap space with an image much larger than the available memory.
And you missed the HD testing pictures, measuring high throughput (sp?) and unbelievable low latency.
In reality, caching is not always better. It has two weaknesses.
1. Random I/O patterns do not benefit from caching.
2. Latency, it takes time to fill the cache which from a disk is on the order of ms.
Caching for I/O on random applications is only good if your cache is larger than your access pattern.
Latency for most applications has a larger impact on performance than IOP/s and MB/s. RAM drives have extremely low latencies, so for some appliations it's better.
I would buy extra ram instead of this rocketdrive. The bandwidth of my system ram is 2.1GB/s. This rocketdrive benchmarks at 78MB/s.
Liberty.
On the first-generation IBM PS/2s, the amount of ram on the motherboard (or in IBM-speak 'planar') was limited, with more added by plugging cards into the MCA bus. I have a Model 80 which has only eight megabytes on the motherboard but another 32 on a Kingston MCA card. Back then, RAM speeds were a lot slower and the new bus was fast - memory on the expansion card is only about twice as slow as that on the motherboard. (I haven't yet found a way of persuading Linux of this fact, I would prefer the kernel to use the lower eight megs preferentially.)
There was even a feature called 'matched memory cycles' in the very early machines where the MCA bus would be temporarily underclocked when accessing memory so that it could work synchronously (cutting some wait states). But then the increasing speed of RAM and the fairly constant bus speed (MCA was 32 bits wide at 10MHz, standard PCI not that much better at 33MHz, while RAM access times have gone down hugely from 85ns to goodness knows what) made the idea look silly, and IBM abandonded MCA-bus memory cards for its second-generation models in 1992 or so. Nowadays you could never get away with using something so slow as the PCI bus for 'memory', so it has to be marketed as 'RAM disk'.
-- Ed Avis ed@membled.com
While profiling a high-volume qmail server with fast mirrored drives, I noticed that I could get at least an order of magnitude sustained mail throughput by eliminating the fsync() system call, which essentially forces the disk subsystem to stop whatever else its doing and get a few specific blocks all the way onto disk. You can't run it in production this way, as the SMTP RFC specifies that the mail must be actually on disk before the server can claim that its done.
The problem is that magnetic-media drives can only seek a few hundred times per second. Regardless of their claimed sustained throughput, if you are writing a bunch of small files to disk, you are completely dependent on the seek time of the drive.
But mounting a magnetic-media-based ext3 with data=journal and the journal on an NVRAM block device would essentially use this as a trusted write-cache. Linux will return from the fsync() system call as soon as the data is in the journal, which could happen instantly on an NVRAM disk as there is no seek time. It then reads from the journal in its spare time, sorts it to minimize seeks, and writes the data out to disk.
I suspect that this should offer roughly the same speed as eliminating the fsync()s entirely.
I was looking into ordering a similar product to test this. I found:
Aaron
Any Xeon motherboard. Not all x86 OSes support the Xeon addressing model, and it's a segmented addressing system that still restricts you to 4 GB chunks per process.
You must've missed the article on here a few months/year back about the guy (@ MIT?) that was disassembling RAM and able to find the 'most used position' of transistors to recover data out of memory, similiar to how they can do it from mechanical hard drives if not completely wiped.
That is the real gain of solid state drives. If you have say a database with lots of small writes then your speed is limited by seek time of drives of around 5ms. You can add more spindles to help in some situations. With SCSI solid state drives they max out at 8000 trans per second (usually) because of the scsi controller.
I don't know why a hobbyist website is reviewing this unit - the target market is not for hard-core gamerz or other home user types. Solid state disks are primarily used as database accelerators. Although the throughput of a solid state disk like this can be easily beat by a reasonably small raid, it takes a much larger raid to beat the io/s rate. If you have indices that don't fit in ram, you stick them on the solid-state disk and watch your database speed up by an order of magnitude.
Alternatively, as at least one other poster has already mentioned - if you use a journalling filesystem like ext3 or rieserfs, then putting the journal on a seperate solid-state disk is a huge performance gain.
When information is power, privacy is freedom.
Solid State Drive have a place in high end computers primarily and not for computers used by comsumers. SSD technology has many advantages over mechanical drives, unfortunately price isn't yet one of them. When the technology becomes cheap and is sensible enough for standard PCs then you'll see the technology readily available for most consumers. As many people here have already pointed out, todays PC can't really integrate SSDs without slowing data throughput and that would really defeat the primary advantage of these devices. I found a good link to a SSD manufacturer that explains this all very well: http://www.sparcproductdirectory.com/curtisart.htm
"You helped our nation celebrate its bicentennial in 17 -- 1976." --George W. Bush, to Queen Elizabeth, Wash
To be more specific, you can't go beyond 2-3GB per process using intel, at least, directly. (You could access more indirectly, just not as actual memory.)
The reason is that the kernel needs memory too. Say you try to load some data from disk. You call the read() system call, which switches to the kernel execution context. The kernel then checks to see if the data you're trying to read is available in the disk cache. If it is, it copies. If it's not, it schedules a load, puts your process to sleep, and when the load finishes, it copies.
So, basically, either way, the kernel needs to be copying data from the disk cache to your program's memory space. This means, it needs to see both at once!
The standard way this works is, all physical memory (which might be used as cache) is mapped into the kernel, normally limited to the high 1GB. The user process gets the low 1GB. So, when you switch to kernel mode, the kernel has all memory, physical and program-virtual, available to it.
Now, some people have more than 1GB ram. The easiest thing for these people to do is use a 2/2 split, if they only have 2GB. This means the process can't use more than 2GB at once, but usually that's ok because most programs don't need that, really. A 1/3 split is also possible.
However, obviously no straight split scheme like this is going to work if you install 4GB of ram! Instead, the kernel is going to have to play some trickery with the page tables and segment registers to get access to this extra memory. This way, it can support more than 1GB, up to 64. The user process of course is still limited to 3.
The problem here, of course, is that doing tricks to get access to your memory in the kernel is obviously going to be slow. So, a kernel that actually tries to use more than about 1 (or maybe 2) GB of ram will be slower than a kernel which does not, and this is unavoidable. Now, this may be just fine, because that extra ram can be used for disk cache - and if your program uses a stupendous amount of disk space, even if the kernel is slower, the huge disk cache will still be a big help for you.
But to make a long story short, >1 (or at most, 2) GB of ram will actually make your computer slower, unless you actually do something which uses all of that ram.
None of this would be true, of course, on a 64-bit machine.