Moto G and Moto E : snapdragon 400 vs 200 Round2

A while ago we discussed about S200 vs S400 using the Old CPU Benchmark tool called "Linpack For Android", an app that had not been updated since ages. It was convenient for one reason : no update = no artificial MFLOPS increase due to app optimization ... but with CM11,12 and 12.1 i noticed huge performance drops in Linpack whereas i didn't feel any. It was time to try something else

Linpack for Android
A dead Benchmark app...

Linpack vs RgbenchMM on MotoE and MotoG:

RgbenchMM	1190MHz
	Moto E (S200)	Moto G (S400)
1	270	290
2	611	641
4	587	1280

Linpack	1190MHz
	Moto E (S200)	Moto G (S400)
Single	79	55
Multi	145	150
Per Core	72,5	50

Why is there so much disparity? the way the app make the CPU work and the way the workload has been set are different and so are results.
2 disparities :

• In Linpack Single Core results for MotoE (S200, stock rooted KK) and MotoG (S400, CM12.1) are not similar although they should regarding the Core frequency and the similar architecture. (results Are similar with RgbenchMM)
• MultiThread results are strange on Linpack : How a QuadCore CPU couldn't perform better than a DualCore one??
  • Linpack cannot handle more than 3 Threads
  • MotoG with CM12.1 starts with about 20% less MFLOPS with one core, and that is still the case in the multithreaded run... Not expected

Let's see how RgbenchMM performs in similar situation!

RgbenchMM
A Great CPU Benchmark app!

What do we see here?

• Results for RgbenchMM are similar with MotoE and MotoG for single and dual threading benchmarks : this is expected in the way S200 and S400 are clocked at the same frequency.
• 4 Threads run give more than 4 times the score of Single Thread one with the QuadCore S400
• Results are strictly linear to the number of cores for S400 (r²=0.97, which is pretty good for Benchmarks results)
• 4 threads benchmarking is only suitable for MotoG (the S400 is a quad-core) and gives inconsistent results with S200 (only dual-core, so 4 threads handled by 2 cores cannot give good results)
• Little lower results with MotoE could be explained since the S200 has its 2 cores shared between Benchmark and System, whereas MotoG (S400) has still 3 and 2 cores left to handle system processes during single and dual threads (although 4 threads run is strictly twice higher than 2 threads ... so even with all the cores used S400 MFLOPS/Core results are better than S200?)

• On both devices, MFLOPS/Core results are slightly better in Dual Thread run and Single Thread one

RgbenchMM dev explains the following:

it does about 6 loads and 8 multiply-accumalates (or 16 flops) inside the loop. The load instructions (FLDD) are also VFP instructions as are the FMACD instructions. Thus, the benchmark is testing the VFP performance almost exclusively. One other detail about the code is that the threads are setup so that ideally they are reading the same columns of one of the input matrices. This will be beneficial on architectures with at least 1 level of shared cache and thus you may see more than 2x speedup on a dual-core processor.

• The Extremely lower MFLOPS/Core result for 4 threads run on the DualCore S200 shows how it would handle hard multitasking.

Is the Conclusion changed?
Compared to the previous S200 vs s400 article

• Does Changing the Benchmark app modifies the conclusion about the S200 vs S400 comparison? No, i doesn't
• Does it changes the "Pure CPU benchmarks: the limits" article conclusion? Not exactly, in fact the results can't be compared since my MotoG was running CM11 at that time, but it could explain the high gap between CM11 and stock KK : it was more a Linpack bias than a ROM issue, i'll be able to test Stock ROM on a S400 soon, then the final conclusion will come.

CT406 : proximity and light sensor on MotoG

The CT406 module is both an Ambient Light Sensor (ALS) and a proximity sensor.

There are not much documentation on this product so here is what i understood from my research:

the above picture is a macro-picture of the ALS/prox sensor of my MotoG (MotoE has exact same module, but on the left side of the screen)

• On the left we can see a InfraRed LED (near IR range since we can see a little reddish light in the dark, but my camera catches part of IR spectrum and displays some kind of purple)
• In the middle there is a black spacer.
• On the right this looks like to be the sensor itself (from here, we know that the sensor is only an ALS that works as proximity sensor when coupled to an external IR-LED)

Here is the TAOS TSL277x chip that seems to be the base of the CT406.
TAOS (Texas Advanced Optoelectronic Solutions) brand is now known as ams.

Superposing my picture and that artwork: Pretty identical, right?

The pins are arranged this way (scheme is rotated 90° right compared to my picture):

How does the proximity sensor works? IR reflection...

The IR-LED emits Red-InfraRed lights and the right part detects if it is reflected or not (reflected == near; non-reflected == far)

To test this, it would be nice to use an external IR-LED and hide the embedded one to see if the sensor still say "far" when under IR light and "near" when IR light is turned OFF.

On our devices, the ALS sensor can only response a "high/low" output, but without the glass panel (that filter some IR) and a reworked program it could be used as presence detection (longuer range) [Source]

How does the ALS sensor works? Wide range light detection, IR detection, and human sight.

The chip features 2 photodiodes (one responds to wide range light: ch0; the other only gets IR: ch1)

In the above diagram we see ch0 respond to light from 300 (near UV) to about 1000nm (IR)
Humans see light from 390nm to 700nm (about, this means from deep-blue/ultra-violet to deep red/infrared), 

Humans don't see IR, therefore, light emitted from 700 to 1000nm produces a response from the light sensor (ch0) but Humans are actually in the dark, that would scale up light intensity of the device screen for no "human understandable reason".

That's what the IR sensor (ch1) is used for: the chip calculates something like ch0-ch1= actual human visible light intensity. Actually this is more complicated than this [Source, page 8&9]
The ALS operations have for duty to calculate what a real human would see (so, a spectrum without IR) in order to light the screen at the right human friendly level.

Luxmeter ALS outputs Lux that are then used by the device

The ch0 could give directly the light intensity with no real calculation if the system was open (no glass, whatsoever), and if there were no IR sensor. [See more page 10]

Real Life How does it work inside the MotoG?

Basically, the CT406 contains the following components :

• a sensor that is made of 2 photodiodes, one is wide range and reacts to human visible spectrum + IR; the second one reacts to IR only.
• an Infrared Light Emitting Diode (IR-LED)

The light sensor "reacts" to visible spectrum by using the signal coming from the wide range photodiode minus the IR one.

The proximity sensor is basically the IR photodiode reacting to IR light emitted by the IR-LED and reflected by a near surface.

The module speaks to the device using i2c protocol.


Proximity sensor has two states : 

• near (what the devices call "3cm") and 
• far (what the device calls "100cm")

The ALS has the following working range: 

• 2 lux (the light intensity is lower than sensor threshold)
• 65535 lux (fully saturated)

"The device can saturate if the light is brighter than can be accumulated with the light−to−frequency conversion. The full scale value for saturation will depend upon the integration time programmed into the device. In saturation, the device accumulates 1024 counts for each 2.72 ms of integration time programmed. For each ATIME programmed, the maximum count (saturation level) is the lesser of (1024 * (256 − ATIME)) or 65,535."


This explains a few things about why the screen is not at the intended brightness level.

• If the light isn't a wide range one; like a "white LED" which is actually a blue led with phosphor coating == the blue shift will saturate the sensor despite the "real" (== human felt) brightness is much lower.
• If the light is PWM controlled == is being lighten ON/OFF at high frequency to get desired "global" intensity : it would saturate the sensor  regarding sampling.
• if the light is a fluorescent light (same as for PWM controlled ones)

MotoG : Pure CPU Benchmarks, the limits

To point out pure CPU Benchmark flaws, we'll observe how does a moto G (Falcon or Peregrine, this has no relevance) behaves with Linpack Benchmark when running on Stock 4.4.4 Motorola ROM or CM11-20141124-nightly (4.4.4).

We have seen previously that Linpack didn't use all cores and was limited to 3 threads in multi-thread benchmarking (when comparing s200 and s400 SoC).

Now, we will compare MFLOPS performance between two ROMs that has similar user experience (smoothness mostly)

Stock 4.4.4 Motorola ROM vs CM11

both @1190MHz, Interactive governor.

Stock Motorola features a nearly doubled score for both Single and Multi-Thread, but does that mean it is really better optimized?

• In a way, yes, CM11 is made to be compatible with most devices, so we encounter similar problem seen with Windows against iOS : 
• An OS that fits all against a fully optimized one made for a few specific hardware. Motorola obviously optimized their software to get the best of this great device
• If you compare with the MotoG vs MotoE test, you'll see that the MotoG running CM11 has lower results than MotoE running stock ROM ...

• On the other hand, that's not all a matter of optimization :
• CM11 features KSM, zRAM, and many things that use CPU cycles to compress memory (zRAM) or merging merge-able things (KSM) ==> this reduces CPU pure performance but increase multi-tasking ability.
• The war of versatility and customization against slickness and stability...
• Honestly i can't see difference in user-felt performances...

Actually, i don't see any issues by using CM11 as a daily driver on my XT1032 (Falcon), it is not because a Benchmark say something that it is true in "real life"...

• Don't use CM11 on Moto G if you want to show off with high CPU benchmark results ...
• Stock Motorola ROM is close enough to AOSP to be acceptable as daily driver
• Xposed helps you to get the best of stock ROM
• CM11 is great for end-user customization

The real conclusion is the following :

Don't trust Benchmarks as incontestable truth, they helps to compare devices and  ROMs, but never really tell you how good devices/ROMs are.

Moto G and Moto E : snapdragon 400 vs 200

Snapdragon 400 vs Snapdragon 200 based on msm8926/8226 vs msm8610

After we studied MFLOPS per MHz ...

It is now time to compare MotoE and MotoG:

Moto G and E features a Snapdragon 400 and 200 (respectively a Quad-core Cortex A7 @1.19GHz and a Dual-core Cortex A7 @1.19GHz)

Note that previous benchmarks were performed with ONDEMAND governor on CyangenMod11 ROM, but stock Moto ROM uses Interactive by default (i didn't expected that...) so the following has been made with interactive for both devices (needed to re-bench MotoG >_<)

to check above results are applicable despite governor modification : 

MFLOPS per governor on MotoG (Falcon, CM11) @1190MHz

No significant difference between ONDEMAND and Interactive governors for the specified test.

Moto G (Peregrine) vs Moto E (Condor) msm8926 vs msm8610

To improve accuracy, instead of using my Falcon (XT1032) running CM11, we will compare results obtained on a Peregrine (XT1039) running Stock Motorola ROM :

Both Benchmarks have been run on Motorola Stock 4.4.4 ROM on Moto G (Peregrine) and Moto E (Condor):

There is no differences between msm8226 (Falcon) and msm8926 (Peregrine) despite LTE capability of msm8926, that's why we will use a Peregrine for the following part.

MotoG (Peregrine) vs MotoE (Condor) @1190MHz, stock 4.4.4

We have quite similar results on Single Thread application for one simple reason, the number of cores does not have any impact. Since the clock speed is the same, the results are the one expected.

On Multi-thread the difference is quite huge between the quad-core and the dual-core, though we don't see a x2 ratio by doubling the cores number.

MFLOPS divided per the amount of cores

x/4 for msm8926 and x/2 for msm8610, Single Thread as control.

We should have observed a similar result between Single and Multi/nbCore...
Is the msm8926 really shitty at multithreading? i don't think so, looks more like if linpack or the system only uses 3 Threads...

If we apply a corrective divider (3 instead of 4) the results are perfect :

MFLOPS divided per the amount of threads used

x/3 for msm8926 and x/2 for msm8610, Single Thread as control.

Moto E (Condor) and Moto G (Peregrine or Falcon) should have similar performance in single threaded applications.

Though the 4 Cores may no be used at their full potential in some apps, multi-threaded applications should be better handled by the msm8926/8226 featured by moto G.

Moto G? or Moto E? Which one for What...

For moderate usage, Moto E is quite enough compared to Moto G : 

• It is not weaker on Single Threaded applications
• It has a smaller battery but both smaller CPU and half size Screen in pixels (960*540 vs 1280*720) will give it a great battery life.

Moto G is still the best quality/price in its category (prefer the Peregrine version and not the Moto G 2014 aka Titan)

• Multi-threaded applications will obviously run better on it
• The better Screen density improves user experience on long term usage
• A far better Camera...

A complete Moto G - Moto E versus is available on versus.com (note that Moto G Peregrine does not have 16GB of internal memory ... but only 8, and an SDcard slot.)

CPU Freq and Performances : Single and Multi Thread

Linpack Benchmarking for Moto G, Single and Multi-Threads...

Before we compare Moto G and E Snapdragon 400 and 200 (respectively a Quad-core Cortex A7 @1.19GHz and a Dual-core Cortex A7 @1.19GHz), let's see how the Moto G performs with ONDEMAND governor and increasing CPU Clock.

MFLOPS and CPU Clock speed On Moto G XT1032 aka Falcon, CM11

A MotoG XT1032, running CM11-20141124-NIGHTLY has been used for MFLOPS per MHz tests.

The CPU is downclocked at 787MHz, and then frequency is raised up to nominal Frequency that is 1190MHz. Here are Single and Multi-Thread MFLOPS results.

You can note that 998MHz had inconsistent results due to high standard deviation...

MFLOPS/MHz A closer look to the results

Multi-thread results raise quicker than Single Thread, let's explore this closer :

As we can see, 

• MFLOPS/MHz ratio does not increase much for Single Thread, but,
• For Multi-thread the ratio increases between 787 and 998MHz but then stagnates : This means that MFLOPS increases in a linear way as Frequency is raised.

This can be explained by the following fact : 

The OS needs some CPU cycles to stay ON, so under a certain frequency it conflicts with Linpack work and decreases performances more than expected.

Conclusion? As a conclusion, we can say that CPU clock increase is more effective on multi-threaded applications (in a quite linear manner) than on Single threaded ones.

Moto E and Moto G : 2 White LEDs

After my articles about the "Two LEDs" discovered on MotoE (and suspected on MotoG) i received a lot of questions about them : 

• Are there really Two LEDs there??
• Are they really White and not RGB "mis-configured"?

So i made non-destructive tests using a microscope on Moto E:

For some reason, MotoE LED hole is transparent and we can see through it (that's not the case for MotoG)

2 LEDs The proof that MotoE has 2 LEDs

Here is a picture taken at x100 of the notification LED ON (triggered through /sys/class/leds/white since the brighter one was too bright to allow me to take a pic of it lighten up with my set up)

Each "yellow" rectangle is a LED chip (you can see the two wires on the left one)

This is proof there is two LEDs, i was able to light them both using the following : 

echo 255 >/sys/class/leds/charging/brightness #to light the left and brighter one
echo 255 >/sys/class/leds/white/brightness #to light the one on the right

White LEDs The proof that Moto E has white only LEDs

On the above picture, you can see a closer view of the LED: its inner components and something interesting :

• there are 2 wires: this should correspond to +/- (proof of Single color LED)

[source : Wikipedia]

• The light emitted is white (that could be RGB set to 255:255:255) BUT, there is a Blue shift (the blue luminescence you can see around the center of the LED) which  corresponds to a Blue LED with a phosphor substract coated on it giving the White light.

[source : Wikipedia]

We now know that Moto E has 2 LEDs and that they are White only, 
I cannot prove it for motoG until complete teardown (the LED hole does not allow to see through it and observe the LEDs) but there are good chances that it also has 2 white LEDs regarding the behavior in previous tests.


Make sure you read these articles to understand how this started :

MotoG play with the LED

MotoE play with the LED

Moto E Playing with the LED

After we played with Moto G LED, it's time to do the same with MotoE's one :

Original source (for MotoG) 

It's always cool to know at a glance that your device is charging without the need of lighting the screen, here is how:

in /sys/class/leds/charging/trigger we have these triggers available : 

Code:

[none] bkl-trigger usb-online mmc0 mmc1 battery-charging-or-full battery-charging battery-full battery-charging-blink-full-solid bms-online

easy to change them using :

Code:

echo battery-charging >/sys/class/leds/charging/trigger

needs to set any value !=0 for brightness (LED is either ON or OFF on MotoE):

Code:

echo 1 >/sys/class/leds/charging/trigger

Moto E is quite different than Moto G :
If you pay attention, you can se that Moto E has Two little white LEDs soldered under the LED hole, the first one (left) is ruled by ./charging and the second one (less bright, ont the right) is ruled by the ./white.

/sys/class/leds/white/trigger, and /sys/class/leds/white/brightness configure the right LED and these settings are overridden has soon as a notification comes.

/sys/class/leds/charging/trigger and /sys/class/charging/brightness configure the left LED (the brighter one) and these settings are not overridden by notifications AND both can work toghether: 
You can see the left one kept ON while charging (using battery-charging trigger) and the right one Blinking with an incoming notification.


The above has only been tested on stock rooted ROM
Here is the XDA dedicated thread

Setting up Moto E (XT1022 aka Condor)

From Unlocking bootloader to greenifying... 
A kind of speedrun. 30 minutes are enough from unboxing to the result ;)

Unlocking Bootloader This voids warranty unless you live in EU

#include <std_disclaimer.h>
/*
* Unlocking bootloader wipes your device's data.
* You will loose anything stored in there.
* Backup your files if any.
*/

First of all, we need to set up adb environment, and then unlock bootloader,....

Adding the needed rule to /etc/udev/rules.d : 

create or edit 99-android.rules

#moto normal mode
SUBSYSTEM=="usb", ATTR{idVendor}=="22b8", ATTR{idProduct}==”2e82″, MODE="0666"
#moto debug mode
SUBSYSTEM=="usb", ATTR{idVendor}=="22b8", ATTR{idProduct}==”2e76″, MODE="0666"
#moto fastboot mode
SUBSYSTEM=="usb", ATTR{idVendor}=="22b8", ATTR{idProduct}==”2e80″, MODE="0666"
#moto global debug 
SUBSYSTEM=="usb", ATTR{idVendor}=="22b8", MODE="0666"

If you don't have adb or fastboot already installed, then install the android SDK

getting unlock code : 
Enable USB debugging on your Condor, and type

adb reboot bootloader

Once you are done, type 

fastboot oem get_unlock_data

You should get something like : 

$ fastboot oem get_unlock_data
 (bootloader) 0A40040192024205#4C4D3556313230
 (bootloader) 30373731363031303332323239#BD00
 (bootloader) 8A672BA4746C2CE02328A2AC0C39F95
 (bootloader) 1A3E5#1F53280002000000000000000
 (bootloader) 0000000

Turn it into something like :

0A40040192024205#4C4D355631323030373731363031303332323239#BD008A672BA4746C2CE02328A2AC0C39F951A3E5#1F532800020000000000000000000000

go to Motorola website, it's now time to check if the device is unlockable :

Agree, and request the key:

Get your email :

Unlocking for Real:

$ fastboot oem unlock UNIQUE_KEY

Wait your device to reboot, you should see this at startup:

Don't worry, first boot is really really slow.

Removing Unlock Warning Fed up with Unlock disclaimer at boot? It's time to fix it.

• Download this file
• Extract logo.bin
• Reboot to fastboot:

adb reboot bootloader



• Open terminal where you logo.bin has been extracted or cd to it.
• Type:

fastboot flash logo logo.bin



• Reboot:

fastboot reboot



• Enjoy!

Installing Recovery What's a device without any custom recovery?

Download CWM recovery from here

fastboot flash recovery FILENAMEtoFLASH.img

Rooting Unleash the Dragon sleeping in your device

• Download SuperSU zip from here
• Reboot to recovery:

adb reboot recovery

• choose install zip from sideload and type (from a terminal opened in folder that contains SuperSU zip):

adb sideload FILENAME.zip

• Reboot and enjoy RoOt Access!

Isn't that too easy?? 

The following is only there to give clues about how to take advantages of an unlocked/rooted device:

Xposed Framework Getting Xposed to fully play with your device

Want to learn more about Xposed ?
"Xposed is a framework for modules that can change the behavior of the system and apps without touching any APKs. That's great because it means that modules can work for different versions and even ROMs without any changes (as long as the original code was not changed too much). It's also easy to undo. As all changes are done in the memory, you just need to deactivate the module and reboot to get your original system back. There are many other advantages, but here is just one more: Multiple modules can do changes to the same part of the system or app. With modified APKs, you to decide for one. No way to combine them, unless the author builds multiple APKs with different combinations."

Download the installer from here, enable unknown sources and install the framework
==> try these modules to get the best out of your device ;)

  

Greenify your device! The best way to prevent unwanted background services

Simply install from the playstore

Playstore description : 
"Never should your phone or tablet become slower and battery hungrier after lots of apps installed. With Greenify, your device can run almost as smoothly and lastingly as it did the first day you had it!

Greenify help you identify and put the misbehaving apps into hibernation when you are not using them, to stop them from lagging your device and leeching the battery, in an unique way! They can do nothing without explicit launch by you or other apps, while still preserving full functionality when running in foreground, similar to iOS apps!"

Since Xposed is installed, don't forget to enable "boost" mode in Experimental features : it will use the power of Xposed Framework through a module to get better performances.

Sources of knowledge :

• RC-FAQ for Moto G [Collective work to get accurate knowledge]; 
• FAQ for Moto E [by FalconG, based on RC-FAQ for MotoG]; 
• How to Unlock BL for Moto G [by myself, now certified to be working for Moto E]; 
• How to Root by deej_roamer
• Motorola documentation