1 Jan, 2009

Solid State Drives vs Hard disk drives

Posted by Bhavin Turakhia | (10) Comments

Intro

• A solid state drive stores its data in solid-state memory (Flash / SRAM / DRAM)
• Flash does not require constant power and is non-volatile while SRAM and DRAM are volatile

Speeds

• Flash maybe slower than even tradition HDDs on big file access
• Flash is considerably slower than conventional disks for small writes. This is partly due to their large erase block size of 0.5-1 MB
• SSDs are faster than HDDs for small random reads due to negligible seek time (no moving parts)
• Check the comparison table at http://www.storagesearch.com/ssd-ram-v-flash.html.  When Flash based SSDs are used for equal reads and writes they are actually slower than HDDs. However if small random reads far outweigh writes, the performance gains can be upto 100x!!?
• Download the paper – Comparison of Drive Technologies for High-Transaction Databases. Findings below -
  • HDDs: Small reads – 175 iops/s, Small writes – 280 iops/s
  • Flash SSDs: Small reads – 1075 iops/s (6x), Small writes – 21 iops/s (0.1x)
  • DRAM SSDs: Small reads – 4091 iops/s (23x), Small writes – 4184 iops/s (14x)
• Another whitepaper on Flash vs HDDs is Understanding Flash SSD Performance. Findings below -
  • Read performance: Flash outperforms hdds by a large magnitude for small block size
  • It is with write performance that Flash SSDs become problematic. The issue here is the internal structure used within the Flash storage array. This structure includes a collection of bytes called an “erase block”. When you write to a Flash SSD, the drive itself cannot just update the sectors you are changing, but must merge your changes with existing data to update a complete erase block. As Flash SSDs have gotten faster and larger, erase blocks have grown as well. Flash erase blocks used to be 16K in length. Now they are 1 Megabyte for small SSDs extending up to as large as 4 Megabytes for some models.
  • If you are doing pure reads, a Flash SSD will typically be 20x faster than a hard disk for small random reads. If you are doing pure random writes, the same drive might be 15x slower than a hard disk
  • Of pertinence is the table which shows how a small % of writes can destroy Flash SSD Performance. It is for this reason alone that Flash SSDs, by themselves, are not very effective with random update applications like on-line databases, mail queues, and other environments that involve a lot of small updates
    
• One can improve write performance of a Flash SSD using the following methods -
  • OS Write caching – OS buffers writes which eventually get written to disk making the writes appear faster
  • File systems optimized to minimize random writes – YAFFS, JFFS2.
  • Managed Flash Technology – a patent pending technology by easyco which enables Flash Drives to write clusters of random data in linear streams

Costs

• As of mid-2008, SSD prices are still considerably higher per gigabyte than are comparable conventional hard drives: consumer grade drives are typically US$2.00 to US$3.45 per GB for flash drives and over US$80.00 per GB for RAM-based compared to about US$0.12 per gigabyte for hard drives
• DRAM based SSD require more power than hard disks when operating, and need continuous power when not in use if the data needs to be persistent
• Check article Flash vs DRAM Price Projections – for SSD Buyers
  • In the first half of 2007 the difference in user price between a RAM versus Flash SSD was about 45 to 1. A year later in the first half of 2008 that ratio had changed to 25 to 1
  • However NAND has been on a steeper price decline than DRAM for its entire existence. The price of a gigabyte of DRAM declines (on average) 32% per year. There are indications that this decline may slow. Meanwhile, NAND’s price per gigabyte declines faster, at an average of 50% per year

My Conclusions

• DRAM based SSDs are crazy expensive. They serve best for volatile caches (eg, memcached pools etc). If you have servers dedicated to serve in-memory cache data, it may reduce your cost to add DRAM SSDs to these clusters since they are likely not going to bottle-neck on CPU anyways
• Flash based SSDs would work in an environment where the % of writes is low. As can be seen in some of the above benchmarks, a flash based SSD starts degrading in performance in comparison to HDDs in environments with just 5% writes. If one wants to use Flash based SSDs in environments with substantial writes, one should use special filesystems (YAFFS / JFFS2)  and/or use Managed Flash Technology
• Flash based SSDs work like a charm in a read-only or mostly read environment

26 May, 2008

AIR vs WPF: Show me the money!!

Posted by Bhavin Turakhia | (3) Comments

I was thinking about AIR vs WPF (or Flex vs Silverlight) from another perspective today. If I wear the Adobe hat and Microsoft hat, I have to ask where is the $$$ in all of this (for Adobe and Msft).

Well firstly, both Msft and Adobe are selling the IDEs (or as they call them XXX Development Studio). But seriously – selling IDEs cant be big business.

Another revenue stream could be licensing the runtime specification for others to build their own runtimes (JDK style). While I may be totally ignorant about this – I don’t think either Msft or Adobe is doing much of this as of today. Some of the specification seems open and free. There is potential to begin licensing the runtime specs for non-PC devices such as mobile phones and set top boxes etc. However, given the competition, runtimes will likely be free for all devices and vendors (in this case Adobe / Msft) will likely go out of their way to have device vendors bundle their respective runtimes.

One more revenue stream would be self-created applications. This is much like Microsoft’s strategy with MS Office which has always been their cash-cow due to the platform ubiquity of Windows. Adobe is building a slew of their own products around Flex and AIR, and an increased adoption of their platform can result in additional revenue from their own applications. Offcourse this is always a sensitive area, since by building these applications they compete with the very app developers they want to attract to the platform. However Adobe has an advantage over Msft in this area due to the platform neutrality of AIR/Flex. Any app built by them is more attractive to an enterprise which has a heterogenous Operating System environment within the enterprise.

This brings me to the last potential revenue stream – an indirect revenue stream through propagation of the platform. Something that Msft has been very good at in the past. They made their fortunes due to the plethora of applications built in VB / VC in the good old days. The more apps that got built the more copies of Windows (and as a result Office) were sold. Here Msft has a distinct advantage. Every WPF adopter creates an additional boost in sales of Windows licenses. Unless I am missing something Adobe has no such incentive.

This indirect revenue stream appears to be significantly larger in scope than selling the IDE or licensing revenues or currently even their respective home-grown apps. If that is the case, then Microsoft has significantly more to gain by becoming a RIA standard as oposed to Adobe. This would in turn mean that Microsoft can afford to invest significantly more resources and $$s in the development of RIA as opposed to Adobe. Greater investment *may* mean more features, greater adoption and eventually platform dominance.

The one way I see for Adobe to counter this is to open up the platform and have the IBMs, Google’s, Yahoo’s, Sun’s of the world involved in AIR/Flex direction and development. This strategy has been very successful with Java on the server side (though I am sure Sun would have liked to get a greater piece of the action than it has) and if AIR/Flex is to become a default option for desktops/RIA, partnership with the rest of the industry will create the momentum it needs.

12 May, 2008

Things I wish AIR and WPF had

Posted by Bhavin Turakhia | (8) Comments

This makes a great follow-up to my last post on the Paradox of Choice. Life would be simpler with a single platform . Before I start a flame war on that subject let me quickly turn your attention to the real topic of this post. I have been grappling with deciding between AIR and WPF for internal application development and in all honesty, I’d like to have them both. Here are my short list of gripes (or on a more positive note, my wishlist for AIR and WPF)

Missing in AIR

• Advanced socket manipulation functionality (ability to create UDP sockets, NIO etc)
• Talk to any RDBMS
• Multi-threading
• Decent server socket libraries for building server applications (yes I know AIR is a desktop client platform, but given the Web 2.0 world, the line between a client and a server is beginning to blur considerably)
• Accessing global keyboard shortcuts
• Accessing native libraries (the kind that I get with XPCOM on XUL)
• Ability to instantiate external applications
• Greater control on the installer and installation process

Missing in WPF

• Write once, run anywhere ie the ability to run on Mac/Linux (I have already confessed that this is a wish list)
• A full-fledged HTML rendering engine (as opposed to having to instantiate an IE control with limited flexibility)

Hopefully folks at Msft and Adobe are listening