Quick Review : Hybrid armor case for MotoG

Quick Review : Hybrid armor case for MotoG

>> Read part 2 if you didn't already <<

>> You may want to protect your screen too <<

What were my needs: 

• 2 material case (hard plastic and rubber)
• the screen being protected when in bag
• less than 20€

So i bought this for 5$

i won't use the belt clip or the kickstand features, so they won't be much reviewed here, refer to the seller description (that is pretty good)

Device 'in case' in Numbers:
w/o cover : 133*70*17mm for 180g
w/ cover (but no clip) : 135*75*18mm for 200g
nude device : 143g

What's in the box ? (device sold separately ofc)

<== face up

Face down ==> 












The case fits perfectly to the device : 

Features (useful ones ... or not : depends on you needs) :
The belt clip & the kickstand
The belt clip can be rotated by 180°, and can be use as a kickstand thanks to a small piece

(on the picture above, i had already removed the clip so the small part on the right is the piece that locks the cover and the clip together : i could be easy to re-assemble when needed)

buttons and holes : 

in hand : (you can see the embedded kickstand in the middle)

Pros: 

• Fits perfectly the device (which is linked to first 'con')
• The power and vol up/down buttons are well protected and still can be easily accessed
• Looks like it will correctly protect the device from falls
• Cheap (5$), but with a good quality feeling
• Belt clip that is well made and modular (quite easy to remove)
• The 2 microphones holes and the 3.5 hole are correctly placed and well sized
• Good grip in hand

Cons: 

• The Case is quite difficult to place on the device and need some time to do it properly ! (make sure the vol up/down and power buttons are well placed before clipsing the hard plastic piece.
• The case with the cover/belt clip is far too thick for me, since i only wanted to keep that cover to protect the screen i removed the belt clip.
• The device feels really heavy and bulky (but that also gives the 'good quality' feeling).
• Case embedded kickstand isn't really working (not centered enough to be stable).
• Cover Belt clip can be used as a kickstand too, but i don't see the use ...
• Dust sticks a lot on the rubber piece.
• the hole for µUSB port is a little too small for Motorola's original cable or my Sony, but i'll try to find a cable with a smaller male port. It doesn't matter that much : that's rubber : it just needs to be forced a little to plug and it will get it's place back after charging complete

• There is a very little flaw in the rubber piece : 

Modifications:

• Removed belt clip from the case cover to reduce thickness, and added an old bios sticker that i had under the hand :
  

• Finnally, i didn't kept that 'bios' sticker and put a glow-in-the-dark plastic piece instead: 

If you want to find it, it is available under different names on ebay : 

• Hybrid Kickstand Armor Impact Hard Holster Case Cover
• Future Armor Belt Clip Holster Kickstand Combo Case
• black rugged rubber tank case cover stand belt clip holster
• Hybrid Advanced Car Armor Case with Kickstand

[...]

• and many more ... '-_-

Installing Manjaro on a ASUS 1011PX netbook

Installing Manjaro Linux on a ASUS 1011PX netbook

If install process itself is quite easy thanks to a noob-proof installer, setting up power saving is more difficult (for an Arch noob as i am) : here is what i found that could fit to my specific needs.


First simply follow Optimized power settings explained in Manjaro's wiki :

- install 3.14.x kernel
- enabling Intel Microcode
- adding some advanced flags to grub : 
pcie_aspm=force acpi_osi=Linux acpi=force acpi_enforce_resources=lax i915.i915_enable_rc6=1 i915.i915_enable_fbc=1 i915.lvds_downclock=1 i915.semaphores=1

- installing TLP (more about TLP) [Don't forget to remove laptop-mode-tools first!]
- installing Linux Thermal Daemon



Then add a few optimizations to TLP : 
the ASUS 1011PX has an Atom n570 @1.66GHz
(available freq : 1667000, 1333000, 1000000kHz)

- Change CPU governor : 
CPU_SCALING_GOVERNOR_ON_AC=ondemand
CPU_SCALING_GOVERNOR_ON_BAT=conservative
(Atom CPU are really too slow using powersave governor [CPU will be stuck @1.0GHz]

- enable MAX freq (keeping default for min : don't uncomment the line):
#CPU_SCALING_MIN_FREQ_ON_AC=0
CPU_SCALING_MAX_FREQ_ON_AC=1667000
#CPU_SCALING_MIN_FREQ_ON_BAT=0

CPU_SCALING_MAX_FREQ_ON_BAT=1333000
(to save a little more juice so that conservative governor will only switch between 1.0 and 1.33GHz when on battery)

I didn't touched the other settings yet.


To see if TLP is doing is job : 
enter the following in terminal (once on AC, once on battery):
sudo tlp-stat | grep cpu 

Various conditions and I/O Performance

Various conditions and I/O Performance

For previos studies on I/O performances, refer to [1],[2] and [3]

My current set-up : 

It slightly changed ... 

• Motorola MotoG
• memory chipset : emmc: 8GB Sandisk REV=06 PRV=07 TYPE=17
• CM11-20140603-Nightly 
• RenderKernel r23
• 192-1190MHz
• I/O scheduler : fiops
• gov : is part of the tested conditions!
• sdcard read-ahead : is part of the tested conditions!

 Benchmark used : AndroBench v3.4

What is being tested?

• Sequential Read (MB/s)
• Sequential Write (MB/s)
• Random Read (IOPS)
• Random Write (IOPS)
• SQlite insert (TPS)
• SQlite update (TPS)
• SQlite delete (TPS)

Regarding the following modifications :

• CPU governor (Interactive, intelliactive, intellidemand and ondemand), with fixed sdcard read ahead : 128kB
• sdcard read ahead (128, 256,512,1024 and 2048kB), with fixed CPU governor (Interactive)

Results : 

Changing CPU Governor : 

governor	seq read (MB/s)	seq write (MB/s)	rd read (IOPS)	rd write (IOPS)	SQlite insert (TPS)	SQlite update (TPS)	SQlite delete (TPS)
interactive	65,28	15,84	1849,93	393,33	51,58	57,72	58,85
stdev	0,77	0,46	11,03	12,96	1,47	0,93	0,58
intellidemand	54,81	13,45	1117,70	219,32	31,73	34,04	34,22
stdev	2,47	0,66	60,30	11,87	1,02	0,37	0,61
intelliactive	67,56	15,77	1984,63	386,10	53,27	56,90	59,65
stdev	1,36	0,23	64,20	22,67	1,87	1,56	0,36
ondemand	65,47	16,06	1777,45	278,06	46,93	49,73	53,84
stdev	4,43	2,36	63,01	42,24	3,11	3,56	1,20

 The following graph shows a delta% against median (100%), that way a little difference looks big (mostly because of the chosen scale)

Changing sdcard read ahead : 

sd read ahead (kB)	seq read (MB/s)	seq write (MB/s)	rd read (IOPS)	rd write (IOPS)	SQlite insert (TPS)	SQlite update (TPS)	SQlite delete (TPS)
128	65,28	15,84	1849,93	393,33	51,58	57,72	58,85
stdev	0,77	0,46	11,03	12,96	1,47	0,93	0,58
256	66,37	15,93	1844,57	397,16	51,53	56,78	59,33
stdev	2,61	2,09	17,24	28,20	1,06	1,01	0,13
512	67,04	17,22	1828,12	385,42	51,52	57,14	57,81
stdev	2,19	3,94	30,43	21,74	1,29	0,80	0,34
1024	65,90	18,50	1999,54	384,88	51,37	55,92	58,42
stdev	5,59	1,04	25,79	3,23	1,54	2,43	0,46
2048	69,01	16,47	1962,58	383,69	51,32	56,91	58,84
stdev	4,82	1,10	20,62	4,66	0,72	1,69	1,22

The following graph shows a delta% against median (100%), that way a little difference looks big (mostly because of the chosen scale)

What does that show?

• Regarding governors we can say interactive and intelliactive are pretty similar and that intellidemand is far behind. (stdev are not really good, but differences between averages are higher than standard deviations)
• Regarding cache size (sdcard read ahead), results are totally inconsistent (look at stdev/averages!), a 'No Conclusion' conclusion is safe since differences don't look significant.
• I remember that in the X10mini ages (2010), any size higher than 128kB created hiccups during music playback ... Worth the risk?

==> What we can say is that I/O performances aren't only linked to IO-schedulers but to many other critical points such as CPU governor, (maybe) sdcard cache size, and other untested conditions.

What are the limits?
same as before ...

• Lack of accuracy with only 3 test per condition (and high results dispersion)

• These results are at least device dependent, kernel dependent, ROM dependent AND emmc type dependent (MotoG could be built with at least 4 different memory chips)
• CPU governors are highly tunable, so one that is bad here could be better in other conditions ...

• Delta% against median is not the best to compare but was the easiest here (i could not put IOPS and MB/s in the same chart because of scaling)

Don't forget to read other I/O performances related posts : 

I/O schedulers and performance

I/O schedulers and performance -2-

I/O schedulers and performance -3-