[Tig] St. Diig

[timothy norman huber]

On Oct 18, 2007, at 7:26 PM, Bob Friesenhahn wrote:

> Speaking of I/O bottleneck, since DRAM is volatile, how long does  
> it take to load data into that 1/2 TB of DRAM from traditional disk  
> or tape so that actual work can be started?  How long does it take  
> to copy the finished work from 1/2 TB of DRAM to backing disk?

That can depend on the source device.

The Violin 1010 reads at 1.4GB/s, writes at 1.0GB/s -  linear or  
random access


> How many times may the type of FLASH memory used for such large   
> storage be repeatedly written before failures start to occur?

100k writes for commodity NAND FLASH modules before they wear out.   
Reads don't generate wear.   Application churn rate calculations  
roughly predict how long a module will last.


> What is the MTBF per field replaceable component, MTBF for a full  
> 2U unit,

The VIMM modules. use commodity DDR2 DIMMs.   ~ 4000+ modules per  
appliance.  10 FIT = 10 failures per Billion hours per memory  
module.  Est 1 failure per 3 years per appliance.   Est 1 failure per  
2 months per rack

> and how difficult is the device to repair?  Can the device continue  
> operating while a failing component is replaced?

The switched topology means there is no more than 4 hops to any VIMM,  
and provides multiple paths available should a failure occur.    
Several VIMMs can fail without losing data.   There are up to 4 hot- 
standby VIMMs waiting for failures, otherwise known as fail-in-place.

When a failure does occur,  the software displays a notification and  
the failing VIMM will display a red LED.   Using the CLI, power down  
the failed VIMM, slide the appliance out on its rails, open the top,  
yank the failed VIMM, and pop in a new one.  Your app stays up and  
running, and the raid rebuilds in about 2 minutes.

If the wrong VIMM is yanked, it won't  do damage and you won't lose  
data.  The contact design cuts power to the VIMM before the data  
connection contacts separate.


> ...most post-production/DI tasks do hardly  any random I/O at all.   
> Most accesses are sequential and use the full block size.   
> Sequential throughput drives performance for DI work.

As a (recently) former DP and colorist, I'm fully aware of that.    
When the Flash technology ships, intermixing both FLASH and DRAM on  
the same appliance will provide a better DI solution.


> Random I/O performance is vital for database storage.

and for swap disk, VOD, IPTV, CG renderfarm I/O, large scale caches,  
snapshot deltas, etc.

T


Timothy Norman Huber
Violin Memory, Inc
33 Wood Ave South
Iselin, NJ, 08830


http://www.violin-memory.com/index.cfm
timothyhuber at violin-memory.com


(Los Angeles)
640 Woodlawn Ave
Venice, CA 90291

310 795-6599 Cell