We All Scream for i-RAM

Gigabyte sent us the first production version of their i-RAM card, marked as revision 1.0 on the PCB. 


Click to Enlarge

There were some obvious changes between the i-RAM that we received and what we saw at Computex. 


Click to Enlarge

First, the battery pack is now mounted in a rigid holder on the PCB.  The contacts are on the battery itself, so there's no external wire to deliver power to the card. 

Contrary to what has been said in the past, the i-RAM still uses a Xilinx FPGA, which gets the job done, but is most likely slower and more expensive than a custom made chip. 

A Field Programmable Gate Array (FPGA) is literally an array of gates that can be programmed and reprogrammed to behave in virtually any fashion; the benefit of using a FPGA over a conventional integrated circuit is that a company like Gigabyte can just purchase a FPGA that is suitable for their application, rather than having to send their own IC design to a fab, which takes much more time and costs a lot more than just purchasing FPGAs for their initial product run.  FPGAs are often chosen because of their quick time to market, although they are more expensive to mass produce than ICs.  

The Xilinx FPGA has three primary functions: it acts as a 64-bit DDR memory controller, a SATA controller and a bridge chip between the memory and SATA controllers.  The chip takes requests over the SATA bus, translates them and then sends them off to its DDR controller to write/read the data to/from memory. 

Gigabyte has told us that the initial production run of the i-RAM will only be a quantity of 1000 cards, available in the month of August, at a street price of around $150.  We would expect that price to drop over time, and it's definitely a lot higher than what we were told at Computex ($50). 

The i-RAM is outfitted with 4 184-pin DIMM slots that will accept any DDR DIMM.  The memory controller in the Xilinx FPGA operates at 100MHz (DDR200) and can actually support up to 8GB of memory. However, Gigabyte says that the i-RAM card itself only supports 4GB of DDR SDRAM.  We didn't have any 2GB unbuffered DIMMs to try in the card to test its true limit, but Gigabyte tells us that it is 4GB. 

The Xilinx FPGA also won't support ECC memory, although we have mentioned to Gigabyte that a number of users have expressed interest in having ECC support in order to ensure greater data reliability. 

Although the i-RAM plugs into a conventional 3.3V 32-bit PCI slot, it doesn't use the PCI connector for anything other than power.  All data is transfered via the Xilinx chip and over the SATA connector directly to your motherboard's SATA controller, just like any regular SATA hard drive. 

Armed with a 64-bit memory controller and DDR200 memory, the i-RAM should be capable of transferring data at up to 1.6GB/s to the Xilinx chip; however, the actual transfer rate to your system is bottlenecked by the SATA bus.  The i-RAM currently implements the SATA150 spec, giving it a maximum transfer rate of 150MB/s. 

With SATA as the only data interface, Gigabyte made the i-RAM infinitely more useful than software based RAM drives because to the OS and the rest of your system, the i-RAM appears to be no different than a regular hard drive.  You can install an OS, applications or games on it, you can boot from it and you can interact with it just like you would any other hard drive.  The difference is that it is going to be a lot faster and also a lot smaller than a conventional hard drive. 

The size limitations are pretty obvious, but the performance benefits really come from the nature of DRAM as a storage medium vs. magnetic hard disks.  We have long known that modern day hard disks can attain fairly high sequential transfer rates of upwards of 60MB/s. However, as soon as the data stops being sequential and is more random in nature, performance can drop to as little as 1MB/s.  The reason for the significant drop in performance is the simple fact that repositioning the read/write heads on a hard disk takes time as does searching for the correct location on a platter to position them.  The mechanical elements of hard disks are what make them slow, and it is exactly those limitations that are removed with the i-RAM.  Access time goes from milliseconds (1 x 10-3) down to nanoseconds (1 x 10-9), and transfer rate doesn't vary, so it should be more consistent. 

Since it acts as a regular hard drive, theoretically, you can also arrange a couple of the i-RAM cards together in RAID if you have a SATA RAID controller.  The biggest benefit to a pair of i-RAM cards in RAID 0 isn't necessarily performance, but now you can get 2x the capacity of a single card.  We are working on getting another i-RAM card in house to perform some RAID 0 tests. However, Gigabyte has informed us that presently, there are stability issues with running two i-RAM cards in RAID 0, so we wouldn't recommend pursuing that avenue until we know for sure that all bugs are worked out.

Index i-RAM’s Limitations
Comments Locked

133 Comments

View All Comments

  • abzzeus - Tuesday, July 26, 2005 - link

    http://www.cenatek.com/store/category.cfm?Category...">http://www.cenatek.com/store/category.cfm?Category...

    This a a 4GB PCI Drive @$3000 (yes three thousand) but this is for a native drive with direct access to the PCI bus thus can sustain 133Mbit/s.

    What I'd like to see is a version that fits in 5.25" drive slot 12+ slots for RAM using a std connector for power and SATA II or SCSI (SCA?).

    I can see several advantages for this product IF you think about it
    Webcache server (hold the cache)
    Temporary files (great for those programs that write temp files like crazy)
    Swap space on Database server (lookup PAE, SQL server and 36bit addressing - 32bit windows can address upto 8GB RAM IF the O/S and the app are writen for it (been there :( )
    Swap space on badly behaved app - there are apps that are ported from *nix to windows that tell the OS I have pagable RAM which the server then dumps to disc (4million page faults in 2 hours!) only for the app to ask for it
    Log files - DB servers write out transitional logs once per transaction, this needs a drive that is FAST

    Having more than one of these in a system (power system) means that you can seperate out the I/O onto seperate physical drives or even better controller or best seperate PCI buses (Servers, Really big servers can have three PCI buses) this means for a server (Unit means logical disc made from RAID arrays, seperated out as much as possible, by controller and PCI bus)

    Unit 1 - OS and Apps Binaries
    Unit 2 - Paging file
    Unit 3 - Logs
    Unit 4 - Temp
    Unit 5 - Data

    Maximum seperation equeals maximum I/O

  • Klober - Tuesday, July 26, 2005 - link

    First off, another good article Anand. Now, on to my point...

    I'm wondering about World of Warcraft. After the first article where the info debuted there was a lot of talk in the comments section, and one of the subjects was WoW. It wouldn't have been possible to install WoW to the i-RAM because it's too big (~4.6GB on my machine). However, once AnandTech recieves another i-RAM to test with, either in JBOD or RAID-0, I would like to hear at least a subjective opinion on how WoW runs in large battles and such. I know my brother's machine gets stuttery when there's a big PvP battle, and through my troubleshooting I've gathered that it's a hard drive speed issue. If any of the AnandTech team has a high level character on their account and like PvP, please post something on performance in WoW.

    Thanks!
  • JarredWalton - Tuesday, July 26, 2005 - link

    I can't see having the i-RAM as being more beneficial to any game than simply adding more RAM to the system. If you're going to have 4x1GB DIMMs installed on the i-RAM, why not just put them into the system itself instead? As for WoW, even if the installed size is 4.6 GB, I doubt the game actually goes much above 1GB of memory use - very few applications do. If you have 2GB or more of RAM, do you still get stuttering issues in WoW? If so, there's a reasonable chance that it's simply GPU power that's lacking rather than RAM - or perhaps GPU RAM would help?

    (Note: I'm not a WoW player, so I'm just shooting from the hip.)
  • EODetroit - Wednesday, July 27, 2005 - link

    There are at least 3 seperate data files in the WoW installation that are 1 GB in size each. A bunch of smaller but still over 100 MB files as well. All told as he said its about 4.6GB, and its more than 4GB in that one folder alone. So yeah, the game would go over 1GB in memory use if it was written well enough.

    I play WoW a lot, and loading into highly populated areas sucks. You hard drive thrashes and you have no control of your character until everything is loaded. I'm assuming its busy loading the textures of the equipment that all the player charactes around you are wearing.

    This I-Ram thing might help out a lot, seeing as consumer motherboards don't support over 4GB of memory and the data files alone for WoW totals over 4GB. The problem again is that you'd need to raid two of the I-Ram devices together to get that much storage, and we don't even know if it would result in a tangible benefit.

    As others have mentioned, for all fast action games, it isn't the load times that Anand should be focusing on... its the in-game stutters when something suddenly has to get loaded from disk. Those are killer, and even if the initial game load times only decrease by 5%, if the stutters are eliminated, this might just be worth the cash, more than a new $600 video card certainly.
  • JarredWalton - Thursday, July 28, 2005 - link

    My point wasn't that WoW doesn't ever exceed 1GB, but that it doesn't exceed 2GB of RAM use. Actually, we should have probably mentioned that point as well: no single application under 32-bit Windows (not counting PAE/NUMA setups) can use more than 2GB of RAM. The 32-bit memory space is partitioned into 2GB for applications and 2GB for the OS, if I have my information right. Basically, you need to try out WoW with a 2GB setup before you can say that i-RAM would or wouldn't be able to help.

    Going back to the earlier statements, though, i-RAM is still nowhere near as fast as system RAM. The delay of PC3200 is around 140ns worst case, and bandwidth is still 3.2 GBps or 6.4 GBps dual-channel. i-RAM seems to be somewhere in the microseconds range for access times, and it's limited to 150 MBps bandwidth. If you can add RAM to your PC, that would be the first step to improving performance.
  • phonon - Wednesday, July 27, 2005 - link

    If you have Windows XP Pro, you should be able to make a volume that includes the I-RAM and a regular disk. Then you can make a hard links on the I-RAM that point to the additional 600 Megabytes or so on the regular disk that won't fit on the I-RAM. I've never done anything like this myself, but I think it should work. Any comments?
  • johnsonx - Tuesday, July 26, 2005 - link

    someone's probably said all this, but i don't feel like reading all 80-odd comments:

    First, this strikes me more as a proof-of-concept effort. Sure, they'll sell you the engineering samples, for $150. Rev 2 will be the real product.

    Second, I did see several people suggest that interfacing the board to the SATA interface rather than directly to the PCI bus makes it slower. Why? Standard 32-bit 33Mhz PCI only has 133MB/s of bandwidth, and that's often shared by other devices as well. SATA has 150MB/s of bandwidth, and in most cases is connected to the system by at least a 66Mhz PCI link, or more often some other high-speed chipset link.

    Interfacing to SATA also means that Gigabyte doesn't have to write drivers for 32- and 64-bit flavors of Windows and various Linux distributions, MAC, and more obscure but definitely presents OSes like BSD, NetWare and Solaris (/me wonders about putting the boot partition and SYS volume of a NetWare server on an iRam... probably no real benefit, but you never know).

    Third, I might imagine that Rev 2 will support SATA II with 300MB/s transfer speeds, ECC, and perhaps 8 DDR slots.
  • rbabiak - Tuesday, July 26, 2005 - link

    Would have been nice to see some info on what it performed like as the temp folder for windows. all that internet web browser cache and other stuff that windows sticks off in the temp while it does stuff.

    this is data that you don't usally mind if it just disapears everyone in a while :)
  • UrQuan3 - Tuesday, July 26, 2005 - link

    I remember five or six years ago there were products that would plug into a PCI slot and use PC133 RAM to do this same job. They would show up as a harddrive controller and windows would use default drivers unless you needed something different. This was when programs didn't expect you to have enough RAM to keep a scratch file in RAM, so they'd write out files after every action. A PCI card with a gig of RAM for accepting these scratch files made a huge difference. There's just less need now.

    Then there's the other problem. SATA may be 150MB/s, but the PCI bus it's attached to is only 133MB/s. This certainly explains why everything runs at DDR200. If they'd made a PCI-X card there might be a bigger improvement. The bright side is that they used an FPGA. If next week they decide to implement SATA2, they can issue an update and everyone can upgrade their cards. Companies like Cisco do this several times a year in telecom products.
  • EODetroit - Tuesday, July 26, 2005 - link

    #82:

    You can buy these still. Check out this ebay auction: http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&...">http://cgi.ebay.com/ws/eBayISAPI.dll?Vi...egory=16...

    I'd hope and pray this thing is a lot faster than the iRam for all the extra cost. But the fact that it sits in a PCI card slot (I'm talking about the QikDrive linked above, not the iRam) makes me question that.

Log in

Don't have an account? Sign up now