Saturday, July 27, 2013

whats hot 4.3 jelly beans

As expected, Google officially confirmed Android 4.3 at its event on Wednesday with Android chief Sundar Pichai. Rolling out the updates to its pet devices, user like me are now able to see 4.3 in action in our devices since this friday. Among the new features/improvements in the update are a redesigned camera interface, Bluetooth Low Energy support, performance improvements such as smoother animations, and multi-user restricted profiles. But there’s apparently something else that Google didn’t talk about. Android Police has unearthed a hidden app permissions manager that allows users to selectively disable certain permissions for apps.


New Camera UI


Android 4.3 also offers a new updated Camera app that features a new arch based menu which makes it easier to control and switch camera settings.

Bluetooth Low Energy support



You may not know it, but a whole new family of Bluetooth devices have been arriving. What makes them different from their predecessors is Bluetooth Smart Ready. These are designed as sensors. So, for example, one might check if all windows are locked, while another might measure your heart rate. You get the idea.

Android 4.3  features some Bluetooth updates that let you pair an Android device with low-power gadgets like these sensors. During Google's presentation, we saw an Android device connecting with a Bluetooth Smart-enabled heart-rate monitor that was being powered by the popular Runtastic fitness app.

The update also came with Bluetooth AVRCP 1.3 support, which lets your device now transmit metadata, like a song's title and artist, to Bluetooth controllers.

In Android 4.3, with application programming interface (API) support for Bluetooth Generic Attribute Profile (GATT) services, you can create Android apps that will support these devices. This represents a new and potentially very profitable market for Android developers and their Bluetooth hardware partners.



Multi-user restricted profiles

The biggest addition to Android 4.3 is the Multi-User Restricted Profiles feature, which lets you control the usage of apps and other content on a user level. Multiple user profiles were already available in 4.2.2, but the ability to create restrictions has long been requested, so it's sure to be a big hit.
This feature is for users who have kids. Android has allowed you to have multiple users for some time now, but with this version you can finally have restricted profiles. Technically, it means that you can set up separate environments for each user with fine-grained restrictions in the apps that are available in those environments. Keep junior out of your, ah, questionable apps or Web sites. 
Each restricted profile offers an isolated and secure space with its own local storage, home screens, widgets, and settings. Unlike with users, profiles are created from the tablet owner’s environment, based on the owner’s installed apps and system accounts. The owner controls which installed apps are enabled in the new profile, and access to the owner’s accounts is disabled by default

 Open GL ES 3.0

A big deal for gamers, Open GL ES 3.0 makes the new version of Android more efficient and just plain better at displaying graphics. Google's demo showed us impressive textures, lens flares, and reflections that the older OS would have had trouble displaying. While the upgraded graphics might be indiscernible to the average user, Open GL ES support is still important because of the new possibilities it opens up for developers. Game developers can now take advantage of OpenGL ES 3.0 and EGL extensions as standard features of Android, with access from either framework or native APIs.

New media capabilities

A modular DRM framework enables media application developers to more easily integrate DRM into their own streaming protocols such as MPEG DASH. Apps can also access a built-in VP8 encoder from framework or native APIs for high-quality video capture.

Notification access

Your apps can now access and interact with the stream of status bar notifications as they are posted. You can display them in any way you want, including routing them to nearby Bluetooth devices, and you can update and dismiss notifications as needed.

Improved profiling tools


 New tags in the Systrace tool and on-screen GPU profiling give you new ways to build great performance into your app.

Permission Manager

There is an app available in the Google Play Store called “Permission Manager” and installing this will grant you access to the App Ops functionality. The real question will be whether you want and/or need access to App Ops. For that, read on to see just what can be done using it. In short, App Ops will allow you to set permissions based on individual apps.


Notification Access
People love those notifications at the top of their Android display. I know I do. I'm constantly checking them. Until this new version of Android appeared developers couldn't access this data stream. Now they can. That is, if you, the user, allow them to.
What developers can do is register a notification listener service that, with your blessing, will receive all the data notifications when they're displayed in the status bar. Developers can then launch applications or services for a new class of "smart" apps.
Better Digital Rights Management (DRM)
Google has also added new media DRM framework APIs and improved the existing ones to provide  an integrated set of services for managing licensing and provisioning, accessing low-level codecs, and decoding encrypted media data.
The net effect of these changes is it will make DRM easier to manage and it should make video streams with DRM, which are pretty much all of them these days, look and play better. Like I said, Google is making the best of an annoying commercial video necessity.
OK, go ahead and boo. I know you want too. I hate DRM too. But, here's the painful truth, DRM is here to stay and we might as well try to make the best of it.
That's exactly what Google has done with its new modular DRM framework. This will enable developers to more easily integrate DRM into their own streaming protocols such as MPEG Dynamic Adaptive Streaming over HTTP (DASH) (PDF Link).

Keyboard & input

Android 4.3 comes with an upgraded algorithm for tap-typing recognition that makes text input easier while chatting via messages or even while composing emails. It also brings a new emoji keyboard, which we've previously seen in iOS. The update also adds lower latency input for gamepad buttons and joysticks.
















server performance improvemevt tweek

                                                              

Tickless System

Previously, the Linux kernel periodically interrupted each CPU on a system at a predetermined frequency — 100 Hz, 250 Hz, or 1000 Hz, depending on the platform. The kernel queried the CPU about the processes that it was executing, and used the results for process accounting and load balancing. Known as the timer tick, the kernel performed this interrupt regardless of the power state of the CPU. Therefore, even an idle CPU was responding to up to 1000 of these requests every second. On systems that implemented power saving measures for idle CPUs, the timer tick prevented the CPU from remaining idle long enough for the system to benefit from these power savings.

The tickless kernel feature allows for on-demand timer interrupts. This means that during idle periods, fewer timer interrupts will fire, which should lead to power savings, cooler running systems, and fewer useless context switches.

Kernel option: CONFIG_NO_HZ=y
To set kernel option change kernel option in /boot/config-x.x.x.x-generic

Timer Frequency

You can select the rate at which timer interrupts in the kernel will fire. When a timer interrupt fires on a CPU, the process running on that CPU is interrupted while the timer interrupt is handled. Reducing the rate at which the timer fires allows for fewer interruptions of your running processes. This option is particularly useful for servers with multiple CPUs where processes are not running interactively.
Kernel options: CONFIG_HZ_100=y and CONFIG_HZ=100

Connector

The connector module is a kernel module which reports process events such as forkexec, and exit to userland. This is extremely useful for process monitoring. You can build a simple system to watch mission-critical processes. If the processes die due to a signal (like SIGSEGV, or SIGBUS) or exit unexpectedly you’ll get an asynchronous notification from the kernel. The processes can then be restarted by your monitor keeping downtime to a minimum when unexpected events occur.
Applications that may find these events useful include accounting / auditing (for example, ELSA), system activity monitoring (for example, top), security, and resource management (for example, CKRM). Semantics provide the building blocks for features like per-user-namespace, "files as directories" and versioned file systems.
Kernel options: CONFIG_CONNECTOR=y and CONFIG_PROC_EVENTS=y

Networking

TCP segmentation offload (TSO)

A popular feature among newer NICs is TCP segmentation offload (TSO). This feature allows the kernel to offload the work of dividing large packets into smaller packets to the NIC. This frees up the CPU to do more useful work and reduces the amount of overhead that the CPU passes along the bus. If your NIC supports this feature. TCP offload engine or TOE is a technology used in network interface cards (NIC) to offload processing of the entire TCP/IP stack to the network controller. It is primarily used with high-speed network interfaces, such as gigabit Ethernet and 10 Gigabit Ethernet, where processing overhead of the network stack becomes significant.
sudo ethtool -K eth1 tso on
Data corruption on NFS file systems might be encountered on network adapters without support for error-correcting code (ECC) memory that also have TCP segmentation offloading (TSO) enabled in the driver. Note: data that might be corrupted by the sender still passes the checksum performed by the IP stack of the receiving machine A possible work around to this issue is to disable TSO on network adapters that do not support ECC memory. 
You can check  of it is working using
sudo ethtool -k eth1
netstat -nt | findstr /i offloaded
  TCP    10.100.44.52:49157     1.58.20.40:50442   ESTABLISHED     Offloaded
  TCP    10.100.44.52:49157     1.58.25.15:1191    ESTABLISHED     Offloaded
  TCP    10.100.44.52:49157     1.148.8.6:58308    ESTABLISHED     Offloaded
  TCP    10.100.44.52:49449     1.10.3.2:1025      ESTABLISHED     Offloaded


Intel I/OAT DMA Engine

This kernel option enables the Intel I/OAT DMA engine that is present in recent Xeon CPUs. This option increases network throughput as the DMA engine allows the kernel to offload network data copying from the CPU to the DMA engine. This frees up the CPU to do more useful work.
to check if it is enabled
dmesg | grep ioat
There’s also a sysfs interface where you can get some statistics about the DMA engine. Check the directories under/sys/class/dma/.

Kernel options: CONFIG_DMADEVICES=y and CONFIG_INTEL_IOATDMA=y and CONFIG_DMA_ENGINE=y and CONFIG_NET_DMA=y and CONFIG_ASYNC_TX_DMA=y



Direct Cache Access (DCA)

Intel’s I/OAT also includes a feature called Direct Cache Access (DCA). DCA allows a driver to warm a CPU cache. A few NICs support DCA, the most popular (to my knowledge) is the Intel 10GbE driver (ixgbe). Refer to your NIC driver documentation to see if your NIC supports DCA. To enable DCA, a switch in the BIOS must be flipped. Some vendors supply machines that support DCA, but don’t expose a switch for DCA.
If that is the case, see blog post for how to enable DCA manually.
dmesg | grep dca
dca service started, version 1.8

If DCA is possible on your system but disabled you’ll see:
ioatdma 0000:00:08.0: DCA is disabled in BIOS
Which means you’ll need to enable it in the BIOS or manually.
Kernel option: CONFIG_DCA=y


NAPI

New API (also referred to as NAPI) is an interface to use interrupt mitigation techniques for networking devices in the Linux kernel. Such an approach is intended to reduce the overhead of packet receiving. The idea is to defer incoming message handling until there is a sufficient amount of them so that it is worth handling them all at once.
High-speed networking can create thousands of interrupts per second, all of which tell the system something it already knew: it has lots of packets to process. NAPI allows drivers to run with (some) interrupts disabled during times of high traffic, with a corresponding decrease in system load.
When the system is overwhelmed and must drop packets, it’s better if those packets are disposed of before much effort goes into processing them. NAPI-compliant drivers can often cause packets to be dropped in the network adaptor itself, before the kernel sees them at all. 
NAPI was first incorporated in the 2.5/2.6 kernel but was also backported to the 2.4.20 kernel. Note that use of NAPI is entirely optional, drivers will work just fine (though perhaps a little more slowly) without it. A driver may continue using the old 2.4 technique for interfacing to the network stack and not benefit from the NAPI changes. NAPI additions to the kernel do not break backward compatibility.
Many recent NIC drivers automatically support NAPI, so you don’t need to do anything. Some drivers need you to explicitly specify NAPI in the kernel config or on the command line when compiling the driver.

To check your driver
# ethtool -i eth0
driver: e1000e
version: 2.1.4-k
firmware-version: 0.13-3
bus-info: 0000:00:19.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: no


Performance under high packet load

PsizeIppsTputRxintTxintDoneNdone
60890000409362172762276823
128758150464364219301107738
25644563277464642155072112906
512232666994445241292191472411921062
10241190611000003872519192588725110
1440851931000003946576195059465690


A driver may continue using the old 2.4 technique for interfacing to the network stack and not benefit from the NAPI changes. NAPI additions to the kernel do not break backward compatibility.

Enable NAPI

Downolad the latest driver version by visting the following url:
  1. Linux kernel driver for the Intel(R) PRO/100 Ethernet devices, Intel(R) PRO/1000 gigabit Ethernet devices, and Intel(R) PRO/10GbE devices.
To enable NAPI, compile the driver module, passing in a configuration option:
make CFLAGS_EXTRA=-DE1000_NAPI install
Once done simply install new drivers.
See Intel e1000 documentation for more information 

Some drivers allow the user to specify the rate at which the NIC will generate interrupts. The e1000e driver allows you to pass a command line option InterruptThrottleRate
when loading the module with insmod. For the e1000e there are two dynamic interrupt throttle mechanisms, specified on the command line as 1 (dynamic) and 3 (dynamic conservative). The adaptive algorithm traffic into different classes and adjusts the interrupt rate appropriately. The difference between dynamic and dynamic conservative is the the rate for the “Lowest Latency” traffic class, dynamic (1) has a much more aggressive interrupt rate for this traffic class.
insmod e1000e.o InterruptThrottleRate=1

oprofile

OProfile is a profiling system for Linux 2.6 and higher systems on a number of architectures. It is capable of profiling all parts of a running system, from the kernel (including modules and interrupt handlers) to shared libraries to binaries. OProfile can profile the whole system in the background, collecting information at a low overhead. These features make it ideal for profiling entire systems to determine bottle necks in real-world systems.
Many CPUs provide "performance counters", hardware registers that can count "events"; for example, cache misses, or CPU cycles. OProfile provides profiles of code based on the number of these occurring events: repeatedly, every time a certain (configurable) number of events has occurred, the PC value is recorded. This information is aggregated into profiles for each binary image.
oprofile is a system wide profiler that can profile both kernel and application level code. There is a kernel driver for oprofile which generates collects data in the x86′s Model Specific Registers (MSRs) to give very detailed information about the performance of running code. oprofile can also annotate source code with performance information to make fixing bottlenecks easy. See oprofile’s homepage for more information.
Kernel options: CONFIG_OPROFILE=y and CONFIG_HAVE_OPROFILE=y

epoll

epoll(7) is useful for applications which must watch for events on large numbers of file descriptors. The epollinterface is designed to easily scale to large numbers of file descriptors. epoll is already enabled in most recent kernels, but some strange distributions (which will remain nameless) have this feature disabled.
Kernel option: CONFIG_EPOLL=y







Sunday, July 21, 2013

Coding pratice Under the hood

Normal programming practice most of us focus on  improving efficiency of code by optimizing our algorithm, which is 'Yes very important , But equally important is underling system you are gonna run your application on. A better understanding of this will let you touch the limits. 
t is normal , conventional an good practice variables in "memory" and move data to and from "disk". But sometimes it becomes necessary to keep your data also in memory for fast access, specially when you are making a real time response systems, which most of the operating systems do very perfectly  without even letting you know about it.

And those are the times you need malloc to allocate memory faster than usual, some of us implement our own  memory pool spend inordinate amounts of time keeping track of what objects need to be in RAM and which are on disk and it will move them forth and back depending on needs.
you create a object in "RAM" and it gets used some times rapidly after creation. Then after some time it get no more hits and the kernel notices this. Then somebody tries to get memory from the kernel for something and the kernel decides to push those unused pages of memory out to swap space and use the (cache-RAM) more sensibly for some data which is actually used by a program. This however, is done without you knowing about it. Your application still thinks that these objects are in RAM, and they will be, the very second it tries to access them, but until then, the RAM is used for something productive.
This is what Virtual Memory is all about.
After some time, you will also notice that some of your objects are unused, and you decide to move them to disk so the RAM can be used for more busy objects. So you  create a file and then it writes the objects to the file.(if u do ';-)')
Lets see what actually happened under the hood, your application calls write(2), the address it gives is a "virtual address" and the kernel has it marked as not available.
So the CPU hardware's paging unit will raise a trap, a sort of interrupt to the operating system telling it "fix the memory please".
The kernel tries to find a free page, if there are none, it will take a little used page from somewhere, likely another little used application object, write it to the swap area, when that write completes, it will read from another place in the paging pool the data it "paged out" into the now unused RAM page, fix up the paging tables, and retry the instruction which failed.
your application knows nothing about this, for your application it was just a single normal memory acces.
So now you have the object in a page in RAM and written to the disk two places: one copy in the operating systems paging space and one copy in the filesystem.
Application now uses this RAM for something else but after some time, when application need it back, first you needs some RAM, so it may decide to push another object out to disk (repeat above), then it reads the filesystem file back into RAM, Uff hell lot of work.

A smart guy would have done it like this 

Allocate some virtual memory, it tell the operating system to back this memory with space from a disk file (memory mapped files). When it needs to access object, it simply refers to that piece of virtual memory and leaves the rest to the kernel.
If/when the kernel decides it needs to use RAM for something else, the page will get written to the backing file and the RAM page reused elsewhere.
When application next time refers to the virtual memory, the operating system will find a RAM page, possibly freeing one, and read the contents in from the backing file.
Andthat's it. application doesn't really need to control what is cached in RAM and what is not, the kernel has code and hardware support to do a good job at that, and it does a good job.
The  objects are not needed as filesystem objects, so there is no point in wasting time in the filesystem name space (directories, filenames and all that) for each object, all we need to have in memory is a pointer into virtual memory and a length, the kernel does the rest.
Virtual memory was meant to make it easier to program when data was larger than the physical memory, but people have still not caught on.

Multi-cpu designs have become the fancy of the world, despite the fact that they suck as a programming model. Multiple layer of cache makes it even more/less difficult to cope in optimal programing 

To read a memory location means to check if we have it in the CPUs level 1 cache. It is unlikely to be unless it is very frequently used. Next check the level two cache, and let us assume that is a miss as well.
If this is a single CPU system, the game ends here, we pick it out of RAM and move on. On a Multi-CPU system, and it doesn't matter if the CPUs share a socket or have their own, we first have to check if any of the other CPUs have a modified copy of variable stored in their caches, so a special bus-transaction goes out to find this out, if some cpu comes back and says "yeah, I have it" that cpu gets to write it to RAM. On good hardware designs, our CPU will listen in on the bus during that write operation, on bad designs it will have to do a memory read afterwards.
Now the CPU can increment the value of variable, and write it back. But it is unlikely to go directly back to memory, we might need it again quickly, so the modified value gets stored in our own L1 cache and then at some point, it will end up in RAM.
Now imagine that another CPU wants to increment variable at the same time, can it do that ? No. Caches operate not on bytes but on some "linesize"(smaller than page size) of bytes, typically from 8 to 128 bytes in each line. So since the first cpu was busy dealing with one variable, the second CPU will be trying to grab the same cache-line, so it will have to wait, even through it is a different variable.
To do that, it read the variable and then write that variable back. It may or may not involve a load into a CPU register, but that is not important.

This is a place where pointers help. If you make a application where you need to process some kind of  message. Allocate virtual memory to it and store pointers to this application and try to reuse these objects. this model of programming avoid unnecessary malloc and free calls. Zero copy model of programming  also help in  this case.

Sunday, July 7, 2013

Transferable TCP connection

There are a number of situations in which the migration of TCP/IP connections can be useful. For instance, when there are requirements of load balancing, quality of service, fault tolerance, security. The visible increased performance in cluster based  applications are asking for attention of developers. Most commonly  transport layer mobility scheme is implemented by using a split-connection proxy architecture and a technique called TCP Splice that gives split-connection proxy systems the same end-to-end semantics as normal TCP connections. The TCP connection endpoint migration allows arbitrary server-side connection endpoint assignments to server nodes in cluster-based servers. The mechanism is client transparent and supports back-end level request dispatching. It has been implemented in the Linux kernel and can be used as part of a policy-based software architecture for request distribution. We show that the TCP connection end point migration can be successfully used for request distribution in cluster-based Web servers, both for persistent and non-persistent HTTP  connections

TCP handoff is a technique to handoff one TCP socket endpoint from one node to the other seamlessly, which is to migrate the established TCP state from the original node to the new node, so that the new node can send packets to the other TCP endpoint directly. TCPHA (TCP HAndoff) implements an architecture for scalable content-aware request distribution in cluster-base servers. It implements Kernel layer-7 switching based on TCP Handoff protocol for the Linux operating system. Since the overhead of layer-7 switching in user-space is very high, it is good to implement it inside the kernel in order to avoid the overhead of context switching and memory copying between user-space and kernel-space. Furthermore, the responses are sent directly back to clients without passing through the dispatcher, which can greatly improve the performance of cluster.

 SockMi is a solution for the migration of TCP/IP connections between Linux systems. Only the migrating peer of  the connection needs to reside on a Linux system. The migration is completely transparent to the other peer that can reside on a system running any operating system. This solution does not require changes to existing Linux kernel data structures and algorithms and can be activated in any phase of the connection. Both 2.4 and 2.6 versions of the Linux kernel are supported. With respect to other solutions, SockMi
 i) is able to migrate both ends of a connection;
ii) does not require cooperation on both ends;
iii) may be used by a stream socket in any state;
iv) does not require proxy systems;
v) may be activated via the standard sysctl command



The latest of  transport protocol TSMP, which seeks to support data transfer for the emerging usage paradigm of ”single user, multiple devices” in a TCP compatible manner. Through its novel naming and proxy-based designs, TSMP is able to retain the current client and server protocol operations of the legacy TCP protocol and TCP-based applications while placing new functions at the proxy.

Reliable sockets (ROCKS) and reliable packets(RACKS) are two systems that provide transparent network connection mobility and protect sockets-based applications from network failures. ROCKS does not require kernel modifications and work at user-level. Each system can detect failure within seconds of its occurrence, preserve the endpoint of a failed connection in a suspended state for an arbitrary period of time, and automatically reconnect, even when one end of the connection changes IP address, without loss of inflight data. ROCKS are transparent to applications but they must be present at both ends of the connection

As mentioned in here,  the operation of a server wishing to migrate one of its connection endpoints is described in following figure . As soon asa migration request is issued (i.e., a migration SYN is sent to the remote server), the connection moves to a wait state.While in the wait state, any incoming packet is stored in a connection checkpoint.
Upon receiving a migration SYN, a server targeted by a migration will duplicate locally the endpoint of the initiator of the migration. Packets flowing between the client and the new server have to respect the
sequence numbers agreed upon with the old server by the time of the migration. Since the new server-side endpoint is set up by relying on the TCP connection setup protocol, the migration requester has to choose a proper “client” ISN. Additionally, it also has to impose the ISN that the target node will use as its own ISN during the connection setup protocol. Letting the target server choose its own ISN would
not permit matching the server sequence numbers currently in use.

Make a Redis Cluster (An Idea) :: Twemproxy + Redis

Redis Cluster is on its way. To check the progress on project and future of redis visit http://redis.io/topics/cluster-spec . For the time being, lets have a work around with the insane traffic handled by twemproxy + redis combination. This has proven to be a successful arch, atleast to me, in cases where you can design a combiner function.
 By a Combiner function I mean even if u get multiple copy of same  key from  Cluster you going to make reading this blog, this function should allow either to choose one or combine all.
Since you dont know  if one of the redis instance fails, to which the twemproxy will write data, you need to read all redis  instances and merge the data collected from each of the instances hence i put in requirements Combiner function
If you  have machine having multiple cores,

  • choose to run multiple instances of redis on same machine.
  • chose to run multiple such machines.  (this makes architecture more fault tolerant )
  • its better to  run master slave replication with each redis instance, i.e half of them wil be slaves and half of them will be master. 
  • it is better to keep configuration  such that master and slave are not on same machine.
  • it is advisable to even keep slaves of same machine redis instances on different machine if you can. to minimize loss of data
  • make masters non persistent, and slave persistent.
  • choose to run multiple  instances of twemproxy and shard your writes on them, if you feel you have  higher traffic than a twemproxy can handle. Multiple instances are good to make system more fault tolerant, just in case one twemprozy dies for some or other reason
  • Configure all twemproxy to write to all redis masters instances and with same deterministic technique, consistent hash, and hashing algorithm.
If somthing bad can happen, it will happen 



Here are few advantages that I find using this configuration.

  • You can pin  masters to some core, this will make your system look like each core listen to a port.

Saturday, July 6, 2013

SSD Why and How to use


A high-end SSD is the pinnacle of computer storage today. SSD read times are insanely fast. SSDs can produce a four- or fivefold jump in speed, meaning using one will make your boot times and application launches super short. SSDs are the perfect storage medium—until things go pear-shaped. Or until you seek hard information about the technologies involved. According to cnet "One reason you hear so much fuzzy information about SSDs is that the companies that design and build one of the key components—the memory controller—guard their technology secrets more carefully than Coca-Cola protects its soda formula. It's a very competitive and lucrative market". 

the gist is that SSDs are more reliable than hard disks, and should last a good 20 years at least not counting performance degradation.

Consider the read/write longevity of SLC (Single-Level Cell) and consumer-grade MLC (Multi-Level Cell) NAND memory, the storage media used to build SSDs: The former is typically rated to last 100,000 cycles, but the latter is rated for only 10,000. Relax—you’d need to write the entire capacity of the drive every day for 25 years or so to wear out all the cells. The latest TLC (Triple-Level Cell) NAND that Samsung is shipping is rated for only a few thousand writes, but you’d still need to write the entire drive’s capacity for something less than ten years to use up the drive. An SSD failure typically goes like this: One minute it's working, the next second it's bricked. The latest drives are supposed to alert you when they’re nearing the end of their useful life span, but what happens if the warning pops up and you’re not there to see it? The solution, of course, is to back up your SSD in advance. 

All NAND chips have more memory than their stated capacity—about 4 percent. This is used by the controller for operations, and to take the place of worn out and defective cells. If you've ever wondered why some SSDs come in rounded sizes such as 120GB and 240GB, when other SSDs and memory in general is sold in capacities that are powers of two (128-, 256-, 512GB, etc.), it's because many vendors set aside even more NAND to extend the drive's useful lifespan. For example, a 240GB drive is really a 256GB drive with 16GB set aside for over-provisioning.

You should place things that really require to load faster on your SSD. This includes mostly your programs and games. Placing a video from your SSD will not give a noticeable speed-up in comparison with your HDD, nor will other personal documents result in faster performance.

Some final SSD tips

All SSDs have a limited number of writes before they wear out. As we've pointed out, mostmodern SSDs will become outdated before they die, but that doesn't mean you can't make a few adjustments to maximize the life of your SSD

  • Buy the highest capacity you can afford. You’ll get better performance, although the benefit declines rapidly beyond 256GB.
  • If you’re running an OS that doesn’t have native  TRIM ;a command [that] allows an operating system to inform a solid-state drive (SSD) which blocks of data are no longer considered in use and can be wiped internally"; support, check the manufacturer’s website for a driver that will force garbage collection. You might also look for a utility that you can run occasionally to perform the same task. The easiest way to learn if your SSD supports TRIM is to run an application like CrystalDiskInfo (Windows). It will tell you if your SSD supports TRIM.
  • No SWAP Partition, Journaling Filesystems, … on a SSD. Our operating system has some features that write to the disk when the memory can't hold it for some reason(SWAP memory), alongside tricks that speed up your computer in case you have a HDD but are no longer necessary on an SSD
  • Windows' built-in hibernation feature can be a pain for your SSD. If you really don't need this feature, consider using sleep or shutdown instead, because hibernate writes your memory to the hibernation file every time you hibernate. If u really want this feature add a HDD and make OS write hibernate content to HDD instead.
  • Disable Disk Defragmentation. SSD manufacturers suggest that you turn off both SuperFetch and Defrag features for your drive, as your SSD doesn't need defragmentation at all and it's excellent speed makes SuperFetch useless. Both of those features make small, excessive writes to your drive, which are unnecessary.
  • Most people find Windows' built-in search indexer necessary, because it speeds searching up a lot for data that's on your hard drive.If you only have an SSD, you might want to consider disabling the Search Indexer. If you have both an SSD and regular HDD, you should move the Search Indexer cache to your HDD. This will spare out a lot of writes so that whenever a file is being saved in one of your indexed locations the search cache is no longer updated.
  • There are a lot of temporary files, caches and logs on your computer. These also result in a lot of excessive writes! However, if you'd like to try moving these, the method depends on which browser and what software you use.
  •  Hunt down more applications that frequently write to your disk and  try disabling them. Built-in Resource Monitor in the newer versions of Windows come handy in such cases or use junction points. Junction points tell the system that when it's accessing path X that it should access path Y instead.
  • Use your SSD for the computer’s operating system and application software. Store your movies and most of your other data on a mechanical hard drive. Hard drives stream media just fine, and they’re often better suited for simultaneous recording and playback. They're also at least ten times cheaper per gigabyte.