Changes

|{{oldid|15868|2.0.1}}

To verify the implementation of the TRACE32-based method, a specific test was run. In essence, the testbed was configured in order to run TRACE32 and <code>ftrace</code> tracing — more details in the following section — simultaneously for analyzing the same workload. The logs produced by the two methods were then compared to ensure they match. To this end,  These logs

[[File:MISC-TN-017-eMMC-chart1.png|center|thumb|600x600px800x800px|e.MMC accesses over time]]

[[File:MISC-TN-017-eMMC-chart3-latency.png|center|thumb|600x600px800x800px|Latency]]

[[File:MISC-TN-017-eMMC-chart2-chunk-size.png|center|thumb|600x600px800x800px|Chunk size distribution]]To interpret the result, one needs to take into account how the workload was implemented. In the example under discussion, the workload basically makes use of two applications: <code>[https://man7.org/linux/man-pages/man1/dd.1.html dd]</code> and <code>stressapptest</code>. <code>dd</code> was specified to use 4-kByte data chunks (<code>bs=4k</code>). <code>stressapptest</code> uses 512-byte chunks instead because the <code>--write-block-size</code> parameter was not used (for more details please refer to the [https://github.com/stressapptest/stressapptest/blob/e6c56d20c0fd16b07130d6e628d0dd6dcf1fe162/src/worker.cc#L2615 source code]). As a result, one would expect that the majority of accesses are 512 bytes and 4 kByte. The charts clearly show that this is not the case. Most of the accesses are 512kB instead. This is a blatant example of how the algorithms of the file systems and the kernel block driver can alter the accesses issued at application levels level for optimization purposes.

As explained [[#Device's built-in advanced functionalities|here]], the health status registers can be exploited to implement a monitoring mechanism. For example, a user-space application may poll periodically the status of the device and take actions accordingly if the wear-out exceeds predefined thresholds.  As explained in [[#Embedded Linux systems with eMMC or SD cards|this section]], e.MMC's feature specific registers for monitoring the health of the device. Following is a dump of the standard such registers of the target's e.MMC regarding the wear-out status of the device, namely <code>DEVICE_LIFE_TIME_EST_TYP_B</code>, <code>DEVICE_LIFE_TIME_EST_TYP_B</code>, and <code>PRE_EOL_INFO</code>: <pre class="board-terminal">

</pre>This dump refers to the same testbed described here. Some manufacturers use additional proprietary registers also for providing information about the amount of data that have been actually written onto the device. If available, this number allows to calculate the WAF as given that the amount of data written by the applications of the test workload is known too. The health status registers can be exploited to implement a monitoring mechanism as well. For example, a user-space application can poll periodically the status of the device and take actions accordingly if the wear-out exceeds predefined thresholds.

Last but not least, it is worth remembering that advanced, proprietary off-line tools may also be available for health monitoring. For instance, Western Digital provides such tools for its devices. For more information, please contact our [mailto:sales@dave.eu Sales Department].