Tuesday, June 17, 2014

Quick Review : Hybrid armor case for MotoG

Quick Review : Hybrid armor case for MotoG


Hybrid armor case for MotoG


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)
Hybrid armor case for MotoG





<== face up













Hybrid armor case for MotoG






Face down ==> 












The case fits perfectly to the device : 
Hybrid armor case for MotoG



Hybrid armor case for MotoG





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
Hybrid armor case for MotoG

Hybrid armor case for MotoG

(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)


Hybrid armor case for MotoG




buttons and holes
Hybrid armor case for MotoG

Hybrid armor case for MotoG

Hybrid armor case for MotoG

Hybrid armor case for MotoG

in hand : (you can see the embedded kickstand in the middle)
Hybrid armor case for MotoG
Hybrid armor case for MotoG

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 : 
Hybrid armor case for MotoG
Modifications:

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

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

Hybrid armor case for MotoG






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 ... '-_-

Thursday, June 12, 2014

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 


Thursday, June 5, 2014

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)