All about SD CARDS

Unknown

About, Tips

02/05/2013

8 Komentar

COMMONLY USED CARD TYPES

The most commonly used card type for mobile phones is the SD (Secure Digital) card. It includes 4 families available in different form factors. The four families are the original Standard-Capacity (SDSC), the High-Capacity (SDHC), the eXtended-Capacity (SDXC), and the SDIO, which combines input/output functions with data storage. The three form factors are the original size, the "mini" size, and the "micro" size. There are many combinations of form factors and device families.


DEFINING BASIC CARD SPEED

SD memory card manufacturers use different types of flash memory to create cards, so actual transfer speeds can vary. Varying speeds make it difficult to determine which card will provide reliable recording of streaming content (which is what most manufacturers seem to be concerned with these days).

The two primary classifications are Speed Class and UHS Speed Class.

"Speed Class" has been used by many as a guide to their performance. The Class of a card is a general indication of the read/write speed. Unfortunately things are not that simple in real life. A card's speed depends on many factors, a few of which are:

The likelihood of soft errors that the card's controller must re-try. Writing data requires the controller to read and erase a larger region, then rewrite that entire region with the desired part changed.

Buffers used by the operating system which, in combination with the card's format, sector size and even the device's card bus speed can impact performance.

The possibility of fragmentation - that a body of information the host views as a unit is written to non-contiguous regions of memory. This does not cause rotational or head-movement delays as with magnetic media, but it does vary the amount of computation the card's controller must do.

Speed Classes 2, 4, and 6 assert that the card supports the respective number of MB/s as a minimum sustained write speed for a card in a fragmented state. Class 10 asserts that the card supports 10 MB/s as a minimum non-fragmented sequential write speed.

The following speed classes are defined:

Class 2 - 2 MB/sec
Class 4- 4 MB/sec
Class 6- 6 MB/sec
Class 10 - 10 MB/sec
UHS-I (UHS class 1) - a theoretical 50 MB/sec
USH-II - a theoretical 312 MB/sec

The Ultra-High Speed (UHS) designation is available on some SDHC and SDXC cards. UHS rated cards support a clock frequency of 100 MHz (a quadrupling of the original "Default Speed"), which in four-bit transfer mode could transfer 50 MB/s or a clock frequency of 208 MHz, which could transfer 104 MB/s. Double data rate operation at 50 MHz (DDR50) is mandatory for microSDHC and microSDXC cards labeled as UHS-I. In this mode, four bits are transferred when the clock signal rises and another four bits when it falls, transferring an entire byte on each full clock cycle. UHS-II cards further raise the data transfer rate to a theoretical maximum of 312 MB/s.

It should be noted that it is quite possible for a good Class 4 card to outperform a not so good Class 10 card in various devices (including the HTC HD2 which is what I am using at the time of this writing) as a result of various factors, including card quality, buffers, read/write errors, operating system and application software methodology used.

So, in theory Class 10 is faster than Class 4. As an example, recording video requires a constant minimum write speed while random access (such as our phones mostly use) does not rely on the same type of access. This is really great if you are often recording long videos but I suspect most of us use our phones a little differently.

Often you can get higher speeds from a card than it is rated for. For example, my Class 4 32 GB SanDisk card reads much faster than one might expect it and all too often it is the read speed that makes the device "snappy" (like loading an app).


RANDOM TESTS

It should be noted that these tests were not done by myself. There are many places where tests are described and many methodologies used for them. Benchmarking card performance is not a simple task.

Some of the cards tested include Sandisk 16G class 4, Memorystar 8 G class 10, Memorystar 16 G Class 10, Kingston 8 G class 10, Kingston 16 G class 10, Lexar HS Mobile 32 G class 10, Lexar HS Mobile 16 G class 10, Patriot LX 16 G Class 10, Adata 8 G class 6, Samsung plus 8 G class 6, Sandisk 32G class 4.

Quote:

Quote: Random reads of 512 KB blocks show the SanDisk Mobile Ultra microSDHC to be the fastest card at 21.8 MB/s. Reducing the block size for the random read test to 4 KB significantly impacts performance, which tops out at a mere 3.4 MB/s, achieved by the Samsung and Adata Class 6 cards. There is almost no difference between queue depths of one and 32 when it comes to memory cards.

You can review the entire test and the results here.

The random tests and results, which impact mobile phones more, are located here.


BENCHMARKING YOUR CARD

Benchmarks are a rather elusive science since there are too many variables that can impact the results, not the least of which is the card itself. Anyone who has worked with SD cards in the real world has probably noticed that the brand of card can make a dramatic difference in performance. Tests have shown as much as a 12x difference in performance between best and worst cards in real world tasks. As already noted, the "class" ratings used by manufacturers as a measure of performance are not reliable indicators of performance either. In fact, some manufacturer's class 2 and class 4 rated cards routinely outperform cards rated as class 6 or class 10!

Consistency of testing is important since different devices and bottlenecks, such as bus speeds, buffers, file systems and activity can all impact and alter the results. This is why a card that has performed extremely well on a test may turn out to be a dog in your device. Short of testing all cards in a lab environment under exacting circumstances may well yield inconsistent results.

There are a lot of apps available for benchmarking, for Android, as well as Windows and Linux. The following short list is not a recommendation of any software.

HD Tune is a hard disk utility with many functions. It can be used to measure the drive's performance, scan for errors, check the health status (S.M.A.R.T.), securely erase all data and much more. It was designed for hard disks and it has not been updated in recent times. While it could be used for SD Cards (and has been) it is not the ideal tool for it.

More info is available here.

AndroBench is a popular and up to date benchmark application that measures the storage performance of Android devices. It includes Micro benchmarks, SQLite benchmarks and Macro-benchmarks (see screenshot below).

More info is available here.

Crystal Disk Mark is another hard disk test utility which is also somewhat dated (last revision dates back to 2010 as far as I know). It runs under various versions of Windows and Internet Explorer.

More info is available here.

AnTuTu Benchmark is Android Benchmarking tool for Android devices. It can run a full test, through the "Memory Performance","CPU Integer Performance","CPU Floating point Performance","2D 3D Graphics Performance","SD card reading/writing speed","Database IO" performance", etc. The many tests it can perform and the frequent updates make it a viable tool for benchmarking.

More info is available here.

Vellamo is a reasonably easy-to-use suite of system-level benchmarks for devices based on Android 2.3 and later. Some of the functions it offers include CPU subsystem performance, scrolling and zooming, 3D graphics, video performance, memory read/write and peak bandwidth performance.

More info is available here.

SD Tools is probably one of the most often used tools to check microSD cards (Name, Date, MID, OEMID). You can check if your card is fake. (Check serial number and MID and OEMID). You can also benchmark sd card writing and reading speeds. It is fast and easy to use. See screenshot below.

More info is available here.

Here's my 32GB Sandisk Class 4 card on the Android speed test:

And here is the same card as seen through Androbench:

FILE SYSTEMS FOR SD CARDS

The traditional view has been that storage is not a huge factor for performance on mobile devices. Flash storage (the type most commonly used today) draws little power, and its performance is thought to exceed that of the network subsystem. Yet, oddly enough, just by varying the flash storage, performance over WiFi can typically vary between 100% to 300% across applications; in one extreme scenario the variation jumped to over 2000%. The relationship between storage and application performance seems to be a combination of flash device performance, random I/O from application databases, and use of synchronous writes. Changes to the storage subsystem can significantly improve user experience.

The three primary (not sole) factors impacting device performance as it relates to storage seem to be the media (the card itself), the file system used and the quality of the applications used.

Speed Class is largely irrelevant as it is not necessarily indicative of application performance; although the class rating is meant for sequential performance, there are several cases in which higher-class SD cards performed worse than lower-class ones overall. If not addressed, lower performing storage not only makes the application run slower, it also increases the energy consumption of the device. This part is intended to deal with file systems used in mobile devices and will not address media or application quality (sorry, no tutorial on proper programming techniques) in great detail although they both have a significant impact on performance.



Briefly, Android (as it pertains to storage) consists of flash storage, operating system and Java middleware, and applications; the OS itself is based on Linux and contains low-level drivers (e.g., flash memory, network, and power management), Dalvik virtual machine for application isolation and memory management, several libraries (e.g., SQLite, libc), and an application framework for development of new applications using system services and hardware.

The Dalvik VM is a fast register-based VM providing a small memory footprint; each application runs as its own process, with its own instance of the Dalvik VM. Android also supports true multitasking and several applications usually run as background processes; processes continue running in the background when you leave an application (e.g., a browser downloading web pages).

Android uses SQLite database as the primary means for storage of structured data. SQLite is a transactional database engine that is lightweight, occupying a small amount of storage and memory; it is thus popular on embedded and mobile operating systems. Applications are provided a well defined interface to create, query, and manage their databases; one or more SQLite databases are stored per application on the data partition.

The YAFFS2 file system, managing raw NAND flash was traditionally the file system of choice for the various internal partitions including /system and /data; it is lightweight and optimized for flash storage. Recently, Android transitioned to Ext4 as the default file system for these partitions. Several other files systems have been implemented with varying success in Android devices.

More than 50 file systems have been documented for Linux alone and attempting to document all of them here is simply not possible for me. So many file systems, such little time! You can find plenty of information on all them by doing only a few internet searches. I will concentrate on relatively few of them here. Note that not all attributes of a given file system may be implemented in a given Android system. The omission of a file system from this post should not reflect negatively on it, but rather on my time, or lack thereof.

YAFFS (Yet Another Flash File System) was designed and written by Charles Manning. It is a log-structured file system that holds data integrity as a high priority. Yaffs1 works on NAND chips that have 512 byte pages + 16 byte spare areas. Newer NAND flash chips have larger pages (2048 bytes + 64 bytes spare areas) and stricter write requirements. Each page within an erase block (128 kilobytes) must be written to in sequential order, and each page must be written only once. YAFFS2 was designed to accommodate these newer chips.

YAFFS has been used on Linux, WinCE, pSOS, eCos, ThreadX, and various special-purpose OSes. YAFFS initialization simply erases flash memory. When a bad block is encountered, it follows the smart media scheme of marking the fifth byte of the block's spare area. Blocks marked as such remain unallocated from then on. To write file data, YAFFS initially writes a whole page (chunk in YAFFS terminology) that describes the file metadata, such as timestamps, name, path, etc. The new file is assigned a unique object ID number; every data chunk within the file will contain this unique object ID within the spare area. YAFFS maintains a tree structure in RAM memory of the physical location of these chunks. When a chunk is no longer valid (the file is deleted, or parts of the file are overwritten), YAFFS marks a particular byte in the spare area of the chunk as ‘dirty’. When an entire block (32 pages) is marked as dirty, YAFFS can erase the block and reclaim the space. When the filesystem's free space is low, YAFFS consolidates a group of good pages onto a new block. YAFFS then reclaims the space used by dirty pages within each of the original blocks.

When a YAFFS system mounts a NAND flash device, it must visit each block to check for valid data by scanning its spare area. With this information it then reconstitutes the memory-resident tree data structure.

The extended file system, or ext, was implemented in 1992 as the first file system created specifically for the Linux kernel. It has metadata structure inspired by the traditional Unix File System and was designed by Rémy Card. It was the first implementation that used the virtual file system and it could handle file systems up to 2 gigabytes in size.

The ext2, ext3 and ext4 file systems were all derived from this one. Most ext discussions center around ext3 and ext4 in the Android world.

ext3 is a journaled file system that is commonly used by the Linux kernel. Its main advantage over ext2 is journaling, which improves reliability and eliminates the need to check the file system after an unclean shutdown. Generally, ext3 is slower than competing Linux filesystems, such as ext4, JFS, ReiserFS and XFS, but it has a significant advantage in that it allows in-place upgrades from ext2 without having to back up and restore data. Benchmarks suggest that ext3 also uses less CPU power than ReiserFS and XFS. It is also considered safer than the other Linux file systems, due to its relative simplicity and wider testing base. ext3 does not do checksumming when writing to the journal and if the hardware is doing out-of-order write caching, you run the risk of severe filesystem corruption during a crash.

ext4 was created as a series of backward compatible extensions to ext3. In January 2010, Google announced that it would upgrade its storage infrastructure from ext2 to ext4. In December 2010, they also announced they would use ext4, instead of YAFFS, on Android. The ext4 advantages include large file system support, extents, persistent pre-allocation and journal checksumming.

NILFS (New Implementation of a Log-structured File System) is a log-structured file system for Linux. It is being developed by Nippon Telegraph and Telephone Corporation (NTT) CyberSpace Laboratories. It uses a copy-on-write technique known as "nothing in life is free", NILFS records all data in a continuous log-like format that is only appended to, never overwritten, a design intended to reduce seek times, as well as minimize the kind of data loss that occurs after a crash with conventional file systems. For example, data loss occurs on ext3 file systems when the system crashes during a write operation. When the system reboots, the journal notes that the write did not complete, and any partial data writes are lost. NILFS also includes fast write and recovery times, minimal damage to file data and system consistency on hardware failure, 32-bit checksums, etc.

Android kernels do not routinely include NILFS although mods to make it available can be found.

F2FS (Flash-Friendly File System) was created by Kim Jaegeuk at Samsung for the Linux operating system kernel. The motivation for it was to build a file system that from the start takes into account the characteristics of NAND flash memory-based storage devices, which have been widely used in computer systems ranging from mobile devices to servers. Samsung chose a log-structured file system approach, which it adapted to newer forms of storage. F2FS also remedies some known issues of the older log structured file systems, such as the snowball effect of wandering trees and high cleaning overhead. Because a NAND-based storage device shows different characteristics according to its internal geometry or flash memory management scheme (such as the Flash Translation Layer), Samsung also added various parameters not only for configuring on-disk layout, but also for selecting allocation and cleaning algorithms. Introduced in the second half of 2012 this new file system shows promise but is not yet generally available in any Kernels that I have seen. Samsung has submitted these patches for integration into the Linux kernel, which means it’s likely to appear on Android releases in the future.

Today's predominant file system, YAFFS2, will likely be replaced in the future by the likes of ext4, nilfs or f2fs. In order to do a fair comparison one must compare I/O throughput, user data access latency, application execution latency and data safety. Not a simple task.

If you ever want to get Linux techies arguing just talk about which file systems are the best.

Google, which knows a thing or two about fast systems, has decided, for their purposes anyway, that Ext4 is the best and close to the fastest file system of all. Google also hired Ted T'so, who also happens to be the leading Ext4 programmer. In a note to the Ext4 developer mailing list, Google's Michael Rubin, a senior staff engineer, wrote, "Google is currently in the middle of upgrading from ext2 to a more up to date file system. We ended up choosing ext4." So, if you are using an Android phone and you are not a kernel developer you may want to take Google's word for it, at least for now, and go with the ext4 file system on your SD Card.

In all fairness, the numerous tests that have been ran over the years will prove different winners. Some show ext2 to slightly outperform ext4 but we must also consider data safety and journaling. While not many of us will have vital, enterprise data on our mobile devices, reconfiguring and restoring a device can be tedious, at best. Some will argue for NILFS, others for ext4, and yet others.. well, you get the idea.


I cannot tell you which is the best or fastest or safest. What I can tell you is that, based on my experience, I am staying mostly with ext4 for the time being - reasonable speed and safety combination for my needs.