1 / 12

FAWN: A Fast Array of Wimpy Nodes

FAWN: A Fast Array of Wimpy Nodes. Authors: David G. Andersen et al. Offence: Jaime Espinosa Chunjing Xiao. Why FAWN Not. Increasing CPU-I/O Gap CPU power consumption grows super-linearly with speed.

rad
Télécharger la présentation

FAWN: A Fast Array of Wimpy Nodes

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. FAWN: A Fast Array of Wimpy Nodes Authors: David G. Andersen et al. Offence: Jaime Espinosa Chunjing Xiao

  2. Why FAWN Not • Increasing CPU-I/O Gap • CPU power consumption grows super-linearly with speed. • Dynamic power scaling on traditional systems is surprisingly inefficient • A lot of research in parallel I/O • They focus on workloads that are I/O, not computation, intensive. • Electric cars consumes less power, but why you don’t buy it?

  3. Poor scaling characteristics • The system includes a number of relatively high powered front-end systems • Analysis has shown that for data-intensive workloads, large wimpy node clusters suffer from poor scaleup effects, • Because they are more affected by a diminishing return scaleup effect than a smaller traditional cluster* *Wimpy Node Clusters: What About Non-Wimpy Workloads (3.5.4 Discussion) 3

  4. Limitations(1) Only focus on read-mostly workloads (simple key-value workloads). They can not provide complex processing workload and it is bad for write-most workloads. 4

  5. Limitations(2) Works only for small data and small CPU work-loads Conclusions from author: not going to replace current data-center, does not work for real-time applications (ie. gaming) Does not have ACID property that is desired in data bases (Atomicity Consistency Isolation Durability) 5

  6. Reliability problems • More nodes & hardware components leads to more failures • less memory per node than traditional systems • conversely more nodes are required for the same capacity. • Communication, link and switch failure not considered

  7. Flash Problems (cost) *http://www.genomeweb.com/informatics/no-flash-pan **RETHINKING FLASHIN THE DATA CENTER • Why did they only examine 3-year total cost of ownership (TCO) in Section 5? • flash storage has short lifetime • Flash is 15-20 times more expensive than HDD.* • the smaller flash cells are less reliable and less durable.**

  8. Flash Problems (Size) *RETHINKING FLASHIN THE DATA CENTER • The amount of physical space per megabyte is a problem • Thermodynamically requires more energy • It takes longer to heat a large room than a small one • Environmental foot-print is relative to area needed

  9. Flash Problems (translation layer) *RETHINKING FLASHIN THE DATA CENTER • Through heroic engineering and daunting complexity, the flash translation layer masks these problems, but its performance impact can be significant. • Intel’s Extreme SSDs have a read latency of 85 ms, but the flash chips the drive uses internally have a read latency of just 25 to 35 ms.* • Flash translation layer is part of the flash controller and is embedded in flash chips and drives

  10. Race Conditions • Another study* from CMU found that the system leads to race conditions *dBug: Systematic evaluation of Distributed Systems

  11. Conclusion It is a great system for quickly finding tiny amounts of data provided you have a lot of real-estate and don’t mind the high probability of failure.

  12. Thank You

More Related