backtop


Print 32 comment(s) - last by fteoath64.. on Feb 9 at 8:15 AM

DailyTech chats with JMicron about its controllers used in the majority of today's mainstream SSDs

AnandTech’s Anand Lal Shimpi investigated the performance of Intel's X25-M MLC (Multi Level Cell) SSD, and compared it to OCZ Technology's first generation Core SSD, which used Samsung NAND flash along with a JMicron controller. He found that random write performance was abysmal, due to extremely high write latencies.  This was a problem attributed to the JMicron controller, which was problematic since many other SSD manufacturers used JMicron's controller as well.

JMicron has not been too happy about the negative buzz surrounding its controller around the internet. They have been working on the problem but it is hard to change perceptions once first impressions have been made. In the following interview we asked a few questions and gave JMicron the opportunity to tell their side of the story.

Tell us a little bit about JMicron.

JMicron was founded in 2001 and our headquarters are located in Hsinchu Science Park, Taiwan. As a fabless IC design house, JMicron focuses on high speed serial link technology such as Serial ATA, PCI-Express, USB, RAID and Storage applications. Our products are widely adopted by major motherboard and notebook vendors such as ASUS, Gigabyte, ACER, HP, Dell, Toshiba, Lenovo, etc. JMicron is also the first fabless company in Taiwan that can mass produce SATA II application products.


When did you first find out about the write latency issue?

We have been developing SSD technology since 2006 and launched our first generation SSD controller, JMF601A/602A at the end of 2007. It soon attracted the attention of SSD makers because of the feature set and high performance. We found the write latency issue around March, 2008. The issue only happens under a special condition, when the system data is close to full and the host keeps writing data on it. It takes time to do internal garbage collection, data merge and housekeeping.


What did you do to solve it?

We revised the hardware architecture and launched JMF601B/602B in June 2008.  JMF601A/602A was the old version after B version was available. Currently, all JMicron customers are using latest version, including ASUS NB/EeePC, OCZ, Super Talent, Transcend, etc. The B version improves the write latency a lot. Besides, JMicron also can reserve more spare blocks to alleviate the issue. Because more spare blocks reservation would decrease the drive capacity, most SSD makers tend to not enlarge the spare size.

Note by author: This is part of the reason why OCZ Technology's drives are labeled as 30, 60, 120, and 250 GB instead of the regular 32, 64, 128, 256 GB. Almost all SSDs make use of spare blocks; it is not a feature specific to JMicron.

It should also be noted that AnandTech's testing used OCZ's Core V1 , the Core V2 was meant to address deficiencies and integrate some improvements.

OCZ created a new design that uses up to 64MB of cache to eliminate the write latency issue in their Vertex series of SSDs.

What is the current status of JMicron's controllers?

The JMF601/602 is designed for netbooks and portable applications. They are not so good for servers and  heavy access loading (for example, multi-task access at the same time). We think that's why most users have good performance but some don't. We strove to solve the write latency issue after the AnandTech article was published. And we made some progress in the new firmware versions.

Note by author: Each SSD vendor has the ability to use JMicron's own firmware, or to use their own version. The firmware used can make a big difference. More on this in a future article.

What do you have planned for the future?

Some customers have introduced high speed SSDs with JMicron's RAID controller JMB390, plus two JMF602B controllers. The target performance is 233MB/sec on sequential read and 166MB/sec on sequential write. Moving forward, JMicron is developing SSD controllers with DRAM cache and it is expected to be available in Q3 2009. That will totally solve the random read/write performance issue.

DailyTech will present highlights from JMicron's roadmap in a future article.



Comments     Threshold


This article is over a month old, voting and posting comments is disabled

RE: I'm not buying it
By piroroadkill on 1/22/2009 9:10:26 AM , Rating: 1
I'll nitpick more.

I thought that OCZ's reasons for reporting the capacity as less was because of the disparity between binary and decimal, gigabytes vs gibibytes, and never heard anything about extra blocks being reserved.

I'd like that be clarified..


RE: I'm not buying it
By Brandon Hill (blog) on 1/22/2009 9:19:27 AM , Rating: 4
Here's your clarification:

quote:
*Consumers may see a discrepancy between reported capacity and actual capacity; the storage industry standard is to display capacity in decimal. However, the operating system usually calculates capacity in binary format, causing traditional HDD and SSD to show a lower capacity in Windows. In the case of SSDs, some of the capacity is reserved for formatting and redundancy for wear leveling. These reserved areas on an SSD may occupy up to 5% of the drive’s storage capacity. On the Core V2 Series the new naming convention reflects this and the 30 is equivalent to 32GB, the 60 is equivalent to the 64GB and so on.


http://www.ocztechnology.com/products/flash_drives...


RE: I'm not buying it
By JKflipflop98 on 1/22/2009 9:30:51 PM , Rating: 2
This is a "twofer". One, it is true that blocks are reserved for write leveling and page failure. Secondly, this is a chance for the industry to realign something that has never made a lick of sense into something you can understand. No more "Help! I can only use 109 gigs of my new 120 gig drive!" posts on forums around the world.

Win-win both ways if you ask me.


"Young lady, in this house we obey the laws of thermodynamics!" -- Homer Simpson

Related Articles
OCZ Vertex SSDs Delayed
January 13, 2009, 9:43 AM













botimage
Copyright 2014 DailyTech LLC. - RSS Feed | Advertise | About Us | Ethics | FAQ | Terms, Conditions & Privacy Information | Kristopher Kubicki