Posts Tagged ‘reliability’

Datalight Chosen for Blackboard Campus Card Reader Systems

Blackboard is the standard-bearer for student ID systems around the world. Their contactless cards serve as campus ID, building access, and point-of-sale accounts for meals and other services, and are rapidly replacing the old magnetic stripe systems. The cards and readers use a Windows Embedded CE-based platform. When Blackboard’s BSP provider learned that the systems would be responsible for keeping track of sensitive financial transactions, they recommended Datalight software to make certain that the system will function with bullet-proof reliability. To read more about our work with Blackboard, check out the full success story.

Reliance and Reliance Nitro

Ever since we announced our high performance file system Reliance Nitro, we have been getting questions on how it compares to the original Reliance file system. Below is a quick-reference table noting some of the differences between the two. For a more detailed comparison (including performance benchmarks), please contact us.

Attributes Reliance Reliance Nitro Recommendation
High performance on large number of files  (100+)   If your device stores a large number of files in a single directory, Nitro will perform much faster than Reliance.
High performance on large files   Nitro’s extent based design allows it to perform faster on larger files. For sake of this comparison, files can be considered large if they are 10+ times the block size of the device
Frequent transaction points   Nitro introduces a new structure called Delta transactions which speed up the time taken to conduct transaction points. Depending on how often you conduct transactions points, Nitro can provide significant advantage
Random I/O performance most critical Reliance’s block based design provides an advantage on random I/O on small files. On large files both Reliance and Nitro perform equally well on this metric
Sequential I/O  performance most critical   Nitro outperforms Reliance on sequential I/O due to its extent based design
Support for Windows Mobile   FlashFX Pro 4.0 for Windows Mobile enables a new discard interface that allows Nitro to have much faster write speeds on flash memory
File-size limit 32-bit 64-bit Nitro uses 64-bit variables for file size limits allowing for very large file sizes.
Read-only version   Reliance currently provides a read-only version called Reliance Reader. Nitro currently does not provide a reader application – this is scheduled for v2

I HEART Reliance Nitro

With the release of our new file system this week, Reliance Nitro, we asked our Account Managers what they liked most about our new product. Their answers of course included reliability and high performance. Wes Johns and Phillip Allison were so excited they decided to make a video…  watch the youtube video

Reliance Nitro Demo Video

We’re totally psyched about Reliance Nitro, our newest file system (yes, we’re file geeks), and we’re always on the lookout for opportunities to show off the performance and reliability attributes it adds to Windows Mobile and Windows CE. When we discovered the relatively-new Beagle Board, it occurred to us that a small, low-cost platform might be just the thing to demonstrate Nitro’s amazing benefits. As you’ve probably heard, the Beagle is making waves with its low cost (around $150) and diminutive size. It uses an OMAP 3530 processor and 256MB of NAND. Though they are most commonly used with Linux, we lucked out in having a partner (MPC Data) who has already developed a Windows CE BSP for it. After a few phone calls, the wizards at MPC Data were able to develop a slick video playback demo app, and presto, the Reliance Nitro Beagle Demo was born! Amateur videographers that we are (ok, REALLY amateur), we recently videotaped John Burnham, who has been working on this project on the Datalight side (and who is a really good sport, btw) showing what happens when power is interrupted during a file write and the extra reliability factor of Reliance Nitro on Windows CE. Be sure to check it out here.

Why Raw NAND Flash with Hardware-based ECC is the Way to Go

5 Reasons for Ditching Managed NAND
Everyone knows that NAND has challenges: from factory bad blocks and spontaneous bit failures to endurance limits, etc. That’s why a few years ago managed NAND (NAND flash plus an integrated controller) seemed to be the answer, offering the density of raw NAND, while mitigating many of its inherent limitations. What many device manufacturers may not realize is that the management hardware comes with significant costs, both in terms of dollars per part as well as design limitations. In the world of tradeoffs in which every system designer lives, there are solid technical reasons to consider using raw NAND and leaving the management to software instead. While there are clear commercial advantages for Datalight (as a provider of vendor-neutral software-based flash management) to advocate this approach, we also believe that there are strong technical reasons that flash silicon vendors would do well to embed ECC capabilities into their NAND flash devices rather than relying on ‘total hardware’ solutions such as eMMC or other complex and costly controllers. Beyond the benefits outline below, this approach would allow the flash manufacturers the ability to continue to differentiate their products from others in the industry.

1.    Cost
The cost of managed NAND parts is coming down, but the stuff still sells at a premium over its raw NAND brethren. 

2.    Flash Optimization
There are many new features of NAND available to us today.  Performance features such as cached reads, multi-plane operations, concurrency, and others are becoming invaluable to keep performance at the ever-increasing demands of portable media. The Open NAND Flash Interface (ONFI) has defined a standard method to query the capabilities and characteristics of NAND flash which can be put to use by both software and hardware systems. A software media manager offers the flexibility to take advantage of the most current flash memory features and put them to use efficiently, or to avoid certain features that may be unproven or problematic. A software solution will allow a developer to take full advantage of the media’s characteristics and features unburdened by the indirection or inability for the hardware to expose them.

3.    Visibility/Flexibility
Software (in general) is easily inspected and validated. Features such as wear-leveling move data around the flash device to optimize its life expectancy. Without the ability to inspect source code, a managed NAND solution makes it difficult to validate wear-leveling operation and/or characterize its effect on performance and reliability.  Hardware implementations are often generalized to suit a majority of use cases, while a software solution is easily tailored to the specific use case during development.

4.    Performance
Speaking of use cases, there are many system features that are not available to hardware that may make a generalized hardware solution less advantageous to a specific use case.  For example, system idle time can be used to improve the media performance by scheduling background cache operations and compaction to occur then.  Coordination between the file system and flash media manager can further optimize operations by freeing space when it will no longer be needed and having the media manager code cache certain regions of the flash where meta data might be held. Migrating flash management features to hardware removes this ability to coordinate with other components of the software stack, such as file systems.

5.    Reliability
Lest you think we believe that everything is better left to software, consider error detection and correction (EDC). Error rates are increasing substantially as flash manufacturers push the limits of physics.  Errors can be introduced externally by heat or other radiation, during writes or reads of data, and even to data that was successfully written at a different time. Historically SLC NAND flash required only a single bit error detection and correction (a hamming code is usually sufficient), while MLC parts require minimally four bit EDC.  As the die sizes continue to shrink, error rates will continue to increase, even for SLC flash. 
Calculating the codes to detect and correct such errors is getting increasingly complex and solving such a solution in software for higher-bit EDCs (above 4-bit) is time consuming and often unacceptably slow.  Hardware ECC is a necessary requirement for systems with high EDC requirements and where performance is a concern.

Many of the processors on the market today are incorporating EDC in their NAND controllers. Choosing one of these processors (e.g. TI OMAP 35xx) in combination with raw NAND flash and software management can give you the high-performance EDC to handle next generation flash while maintaining the design flexibility that a software manager provides.

Flash manufacturers have much to gain by adding ECC code into their NAND flash parts.  They know better than anyone what kind of ECC is necessary for a specific part and by adding just that one piece of hardware to their offerings, rather than the jack of all trades, master of none approach of complete flash management, they will better serve the markets. 

In short, features should reside where they can be handled most efficiently; ECCs belong in hardware, other flash management functions belong in software.  While managed NAND certainly has its place and its appeal in the market, we believe the best combination of value, performance and flexibility lies in using a combination of raw NAND and hardware with built-in ECC capabilities.

Reliance Transactional File system demo

Demonstrating how system software work in a visual manner is an interesting problem, especially in embedded space. There is no UI or visual effects to WOW the audience. To evaluate the value system software components bring to an embedded design, the customer usually needs to configure our software on his embedded development board. This provides for comprehensive evaluation but can be a significant effort. . We run into this very often at Datalight since our primary products (FlashFX Pro and Reliance) are system level embedded software. One way we have attempted to demonstrate our software is to make a full-functional version of our software run on user’s desktop PC. This allows the customer to run the software without any special hardware in matter of minutes and understand the core working of our software. Once they believe there is value, the can request source code access and try it on the actual embedded hardware.

The first demonstration that we have built is for Datalight Reliance. This demo is available to all users who are registered for MyDatalight account. The video below shows how you can use this software on any Windows PC and understand how Reliance unique transactional design allows for 100% reliability against data corruption and how Dynamic Transaction Point technology allows developers to tune their file system even while the device is running.

Choosing NAND or NOR Flash Memory: Tradeoffs and Strategies

Consumer electronics and embedded software devices are using larger amounts of flash memory for nonvolatile storage than ever before. So what kind of flash memory should you use? The choice between using NAND and NOR Flash may not be a simple one for the complex embedded devices being developed today. While ever-larger media files are driving increased demand for inexpensive NAND, powerful new operating systems and intricate applications running on fast processors ask for the fast-executing code NOR can support.

Read Datalight whitepaper Choosing NAND or NOR Flash Memory: Tradeoffs and Strategies to Learn More

Consumer electronics and embedded software devices are using larger amounts of flash memory for nonvolatile storage than ever before. One important decision in designing such devices is what kind of flash memory to use: NAND or NOR?

NOR flash memory has traditionally been used to store relatively small amounts of executable code for embedded computing devices such as PDAs and cell phones. NOR is well suited to use for code storage because of its reliability, fast read operations, and random access capabilities. Because code can be directly executed in place, NOR is ideal for storing firmware, boot code, operating systems, and other data that changes infrequently.

NAND flash memory has become the preferred format for storing larger quantities of data on devices such as USB Flash drives, digital cameras and MP3 players. Higher density, lower cost, and faster write and erase times, and a longer re-write life expectancy make NAND especially well suited for consumer media applications in which large files of sequential data need to be loaded into memory quickly and replaced with new files repeatedly.

The choice between using NAND and NOR Flash may not be a simple one for the complex embedded devices being developed today. While ever-larger media files are driving increased demand for inexpensive NAND, powerful new operating systems and intricate applications running on fast processors call for the kind of fast-executing code NOR can support. An important example is a smart phone or PDA that combines a tremendous need for storage with a demanding set of application performance requirements. In some cases an optimal design might call for both types of flash memory in the same device.

Whichever type of flash is used in a device, there are certain negative performance characteristics that need to be mitigated. NOR is fast to read current data but markedly slower to erase it and write new data. NAND is fast to erase and write, but slow to read non-sequential data through its serial interface. NAND is also prone to single-bit errors, requiring rigorous algorithms for error detection and correction.

Well-designed software strategies can be very effective in increasing the performance and reliability of Flash hardware. The goals of flash memory management software include:

Avoid loss of data. Perhaps the most important goal in managing flash memory is to assure that no data is ever lost as a result of an interrupted operation or the failure of a memory block.  There are several ways that flash management software can achieve this goal. Rewrite operations, for example, can be managed in such a way that new data is written and verified before the old data is deleted, so that no power loss or other interruption can result in the loss of both old and new data. Bad block management is another important safeguard to prevent data being written to memory blocks that have failed. Software can check for bad blocks shipped from the factory, as is typical with NAND, and avoid writing to those blocks from the beginning. When blocks go bad over time they can be identified and managed so that they are no longer used. Finally, as the end of media life nears, good memory management software can implement a graceful strategy such as placing the entire flash unit in a read-only state, thereby avoiding data loss when the number of block errors exceeds a predefined number.

 

Improve effective performance. Two ways media management software can improve performance are background compaction and multithreading. Compaction reclaims space by identifying blocks that have obsolete data that can be erased, copying any valid data to a new location, then erasing the blocks to make them available for reuse. Such compaction increases the amount of usable space on the media and improves write performance. Compaction may also help to defragment noncontiguous data for improved performance on read operations. The space recovery is particularly valuable for the more costly NOR memory and the defragmentation benefits the slower-reading NAND. Compaction is best performed in the background during idle time, however, or it can interfere with critical operations and degrade performance. This is where a multithreading system becomes important. By allowing high-priority read requests to interrupt low-priority maintenance operations, a multithreading system can reduce read latency by orders of magnitude compared to a single-thread solution.

 

Maximize media lifespan. When some blocks of memory contain fixed content, such as binary code, the remaining blocks will experience increased demand for erase and write operations, leading to earlier failure. Wear-leveling algorithms can prevent overuse of memory blocks and prevent a “stalemate” scenario in which a small region of memory becomes locked in a pattern of repeated writing and compaction. Wear leveling software can monitor block usage to identify high-use areas and low-use areas containing static data, then swap the static data into the high use areas. It can also balance write operations across all available blocks by choosing the optimal location for each write operation.

The decision between NAND and NOR memory will ultimately depend on both technical and pricing requirements of the device being built. Whatever type or combination of flash is used, it is prudent to include memory management software to prevent data loss while improving the performance and maximizing the lifespan of the memory.

Welcome to “Data Matters”

Hi All:

Welcome to the Datalight blog on “Data Matters”.   It’s amazing to see the increase in size and value of data in devices over 25 years that Datalight has been in business.   In the old days, well the 80’s, Datalight worked with Flight Data recorders that held data on 3.5 inch floppies using the FAT file system and  similar non-reliable foundations.  Today, device data requirements are growing at a tremendous pace. These requirements include reliability, performance, size and flexibility in media, bootability and system field-update requirements.

Road Trip: San Francisco - Gadget list

Image by mr brown via Flickr

On the consumer front, the spectrum moves from the inexpensive GO Phone, up to the Feature phones (with multimedia capabilities) toward the Smartphones that can assume the role of a MP3 Player, a movie Player or an office management system for the road warrior.

The more demanding embedded devices hold data that is much more valuable, sensitive, and mission critical.  These devices succeed or fail based on how they handle, store and deliver the data to the final data consumer.

There many “Good Enough” solutions that, well, aren’t really “Good Enough”!     Datalight is committed to Risk Free Device Data, and that’s what this Blog is all about.   If you require more than “Good Enough” for your device data, then keep reading.

Thanks for joining us!

Roy Sherrill
President