Wednesday, January 28, 2015

Google Cardboard - virtuaalitodellisuutta kymmenellä eurolla

Google julkaisi viime kesänä Google Cardboard "virtuaalitodellisuuslasit". En oikein tiedä miksi kirjoitin tuon hipsuilla mutta keksintö on niin yksinkertaisen nerokas ettei se oikein tunnu todelliselta. Eihän kukaan keksi mitään noin hyödyllistä ja samalla noin halpaa. Kyseessä on siis pahvista rakennettavat lasit, johon lisätään vain kaksi linssiä, kuminauhaa ja pari magnettia...sekä se tärkein eli oma älypuhelin.

Älypuhelimissa on nykyään tarkat näytöt, riittävästi tehoja sekä sensorit jotka tunnistavat kallistukset ja suunnan. Lopputulos ei ole aivan yhtä hyvä kuin kalliimmissa virtuaalitodellisuuslaseissa mutta jos askartelupaketin saa alle 10 euron hintaan niin kokeileminen ei tule paljoa maksamaan. 


Todellisuudessa idea ei ole tullut ihan kokonaan Googlelta vaan jo vuosi sitten ilmestyivät Durovisin OpenDive-lasit.
Durovis Opendive


Duroviksen lasit kuitenkin ovat muoviset mikä nostaa hintaa hieman. Googlen lasit voi visuimmat leikata itse pahvista. Linssit pitää tietenkin ostaa silloinkin.

Näin jälkikäteen harmittaa ettei omassa puhelimessa ole kuin täys-hd-näyttö. Näiden lasien myötä nimittäin Retina-tason näytöistä todella on hyötyä. Omassa puhelimessani (S4 Active) ei toiminut laseissa kytkimenä toimivat magneetit mikä haittasi käyttöä.

Googlen Play:stä löytyy ilmainen Cardboard-sovellus sekä lukuisia demoja. Mercedeksen demo kilparadoilta oli hienoa katsottavaa. Kuva siis näkyy 3d:nä sekä päätä kääntämällä näet joka puolellesi. Esimerkiksi tulevan Kaiju-hirviöelokuvan demossa sai päätään käännellä kunnolla jotta sai selville mistä päin hirviö tulee.

Toivottavasti nopeasti saadaan standardi tapa näyttää myös elokuvia. Esimerkiksi levitystapana voisi käyttää normaaleja 3d-täys-hd tai 3d-4k-standardeja. Levitystapana kun tuon kuvan voisi helposti laajentaa kamerassa 360-asteen kuvaksi käyttäen vaikkapa Mercatorin karttaprojektiota:
 Tällöin 360-elokuva siis muunnettaisiin ylläolevaan projektioon ja puheliin muuntaisi sen takaisin 360-muotoon.

Google tukee laseja jo Google Earth ja Streetview sovelluksissa mutta itse en löytänyt omasta puhelimestani näitä ominaisuuksia.

Olisi melkoinen kokemus seurata vaikkapa SuperBowlia livenä Cardboardilla. Tekniikka alkaa olla siihen valmiina. Videokuvan streamaus kännykkään, ja voit vapaasti katsella kuin olisit paikan päällä. Näyttöjen tarkkuus kuitenkaan ei vielä ole riittävä aivan  kaiken urheilun seuraamiseen. Koripallon seuraamiseen ensimmäiseltä penkkiriviltä tarkkuus saattaa riittää.

Googlen pahvilaatikon ansioista kuitenkin käyttäjäkuntaa voidaan saada nopeasti ja kriittinen massa sovellusten ja videotuotannon tuottamiseen saavutetaan.

Sunday, January 25, 2015

Osram Lightify: Color gamut and spectrum


Osram Lightify is a wirelessly controlled lighting system using Zigbee Lightlink open source protocol.  Philips Hue uses the same protocol so these products should work together.

I have a Osram's Starter pack with one RGBW dimmable LED lightbulb (Lightify Classic A RGBW).  I could not find any measurements from internet about Lightify's or Hue's color gamut when I bought Osram so I did the measurements myself.

I simply used the Osram's Android App and did a full circle with hue slider. Then I selected the measurements that were the best representatives for primary colors from gamut corners. For measurements I used Colormunki Phone spectrophotometer and ArgyllCMS software.


Seems Osram can produce fairly deep blue and red but green might be better. The gamut for Philips Hue I picked from AvsForum. The blue line is not a line between measurements. It's a straight line between primary colors I picked and as you can see, the measurements follow that line well. 

The primaries I picked were :

x y
Red 0,683924 0,315904
Green 0,391678 0,501414
Blue 0,13699 0,051035


Here's the spectra for primary colors.


Here are the measurements when I selected 6500K as a color temperature from Android App:
                           CCT = 6377K (Delta E 2.747025)
 Closest Planckian temperature = 6260K (Delta E 2.419812)
 Closest Daylight temperature  = 6422K (Delta E 0.892155)
 Color Rendering Index (Ra) = 87.6
Color Rendering Index is good but could also be better, >90. For Philips Hue the CRI is claimed to be 91.

Sunday, January 18, 2015

Airwheel - tulevaisuuden kulkumuoto, osa 2


Airwheelillä on takana nyt n. 15 ajokertaa kiitos etelän "talven".

Ostin oman laitteen Kevytilmailu.com:sta. Olin valinnut X5 version koska halusin suuremman 170Wh:n akun mutta joulukuussa huomasin että toimitettu versio olikin 130Wh:n akku. Kevytilmailu.com toimi asiassa hyvin ja vaihtaa kaikille väärän mallin saaneille oikein mallin kunhan ne saapuvat varastoon. Tämän takia juuri tilasinkin mieluummin suomalaiselta eli ongelmatilanteissa homma hoituu oikein.

Kantama ei oikein vastaa kuitenkaan odotuksia eli minulla 86kg:n painoisena se on n. 4,5km. Olen kuitenkin ajanut nyt lähimmä kylmillä ilmoilla ja pehmeillä alustoilla mikä varmasti vaikuttaa kantamaan. Lisäksi on varmaan selvää että valmistajan ilmoittamat kantamamittaukset on tehty asfaltilla, kovilla rengaspaineilla ja kevyellä kuskilla. Uskoisin että 170Wh:n akulla kantama samoissa olosuhteissa lähenee 6km:ia. Tällä videolla kuitenkin kantamaksi on saatu 19km optimaalisissa olosuhteissa ja ihan ilmeisesti aikuisen painolla:


Kaikki ei ole aivan vielä selkäytimessä mutta opettelussa on se hieno piirre että vaikka edellisestä ajosta on pari viikkoa niin silti seuraavalla kerralla huomaa jonkin osa-alueen menevän sulavammin. Tärkeää on samoin kuin pyörällä ajossakin että muiden sekaan ei voi mennä ennenkuin osaa jo niin hyvin että pystyy myös seuraamaan muuta liikennettä. Jalkojen oikea paikka on myös hyvin tärkeä jos haluaa ajaa pitempiä matkoja jalkojen rasittumatta.
Metsätiet ja -polut ovat hyviä treenipaikkoja etenkin jos joutuu väistelemään puita samalla. Tässä pätkässä kaaduin lumessa mutta todellisuudessa ajoin saman kohdan varmaan kuutisen kertaa ja tämä oli ainoa kerta kun ajauduin pehmeällä lumelle mikä ei enää Airwheeliä kantanut.


Lainsäädäntö on vain vielä ikävän rajaava:
Koulupojan yksipyörätreeni katkesi poliisin komennosta
"Poliisin mukaan yksipyöräisessä tulisi olla jarrut ja ohjaustanko sekä lamppu."
Vuodenvaihteessa sentään laki muuttui niin että polkupyörässä ei tarvitse enää olla kiinteää lamppua. Ilmeisesti laissa ei erikseen vaadita että pyörässä pitää olla kaksi rengasta mutta ohjaustanko pitää olla.



Lainsäädäntö ei kyllä pysy näiden perässä jos jokainen kulkulaite vaatii oman lainsäändäntönsä.
Kuten tämä:

Tuo varmaan on helpommin opittavissa mutta tuo vie jalkakäytävällä hieman enemmän tilaa sekä renkaat ovat pienemmät mikä tarkoittaa että jalkakäytävien reunat ovat ongelma.Tuonkin paino on 10kg eli mikään kevyt laite ei ole kyseessä.

Aiemmin ajattelin että akku veisi suurimman osan painosta ja akkutekniikan parantuessa Airwheelin painoa saataisiin alas mutta todellisuudessa akku painaa vain 10% koko painosta, suurin osa painosta menee pyörään ja moottoriin. Näihin ei ole ilmeisesti tulossa parannuksia joten laitteiden paino tulee pitkän aikaa olemaan yli 10kg.

Www.wheelgo.com : Component weights

On varmaan vielä tarpeen sanoa että Airwheel ei ole kuntoilumuoto eikä sitä varmaan kukaan sellaiseksi haekaan. Lihaskunto varmaan alussa paranee kun tasapainon saavuttamiseen menee aikaa mutta päällimmäsenä syynä minulla tuohon on nopeus eli tuolla voi kulkea parhaimmillaan juoksunopeutta mikä tarkoittaa että kaupungin kartta taas meni hieman pienemmäksi ja paikat ovat lähempänä toisiaan. Melko nopeasti alkoi tulla vastaan Airwheelin huippunopeus mikä on 12km/h mistä se varoittaa piippaamalla.

Löytyy kuitenkin myös nopeampia yksipyöräisiä. Tämän huippunopeus on n. 30km/h mutta niissä nopeuksissa kaatuminen alkaa olla aika vaarallista. Yksipyöräisissä ero kaksipyöräisiin on myös siinä että yksipyöräisellä törmättäessä kuski kärsii myös eli itsesuojeluvaihto saanee ajamaan keskimäärin varovaisemmin.



Yksipyöräisellä on vaikea ajaa hiljaa ja liikennevaloissa pitää pistää toinen jalka maahan mutta sama tilannehan on myös polkupyörällä.

Englannissa TNT:n kuriireilla on kokeiluprojekti Airwheelin käytössä jakelussa:
Posties trial delivery by electric unicycle


Toivotaan että Suomessakin pian uudistetaan lainsäädäntöä nykyaikaiseksi jotta yhteiskunnan kilpailukyky säilyy.

Saturday, December 6, 2014

Airwheel - tulevaisuuden kulkumuoto, täällä, tänään!


AirWheel on automaattisesti tasapainottuva pyörä. Samanlainen kuin Segway. Paitsi että Airwheelissä on vain yksi rengas ja koko laite on käytännössä pelkkää pyörää, mukana moottori, jalkatuet, akut ja hieman elektroniikkaa. Koko paketti on minimalistin ihanne.




Kun näin laitteesta videoita ensimmäistä kertaa, oli samalla kertaa myyty. Tämä tulee mullistamaan ainakin minun työmatkaliikkumiseni.

Keksintö on itse asiassa tehty jo pari vuotta sitten amerikkalaisen Solowheel yrityksen toimesta. Solowheel vain markkinoi omaa pyöräänsä yli 1000e hinnalla joten ei mikään ihme ettei se ole saanut ilmaa siipiensä alle. Nyt kuitenkin on tullut kiinalainen kilpailija Airwheel joka on puolittanut kulkuneuvon hinnan ja tällöin se on saanut jo huomattavan paljon suuremman potentiaalisen asiakaskunnan.

Kyseessä on siis yksipyöräinen mikä tarkoittaa että tasapainotaitoa tarvitaan enemmän kuin polkupyörässä. Kaikille jo pyöräilyn jo oppineille "aikuisille" ongelma on tietenkin siinä että pitää nöyrtyä opettelemaan pyörälläajo uudestaan. En usko että se ihan kaikille sopiikaan. Toisaalta kuinka harva ei koskaan opi ajamaan polkupyörällä? Minulla taustalla on esim. leijasurffausta joten tasapainon löytymisen tiesin olevan vain ajan kysymys. Ei kuitenkaan olla vielä lähelläkään sitä sujuvuutta mitä löytyy esimerkiksi Youtubesta löytyvistä videoista. Tässä kaksi suosikkiani:




Maksimivauhti on 18km/h vaikka normaali matkanopeus on alle 12km/h. Se on kuitenkin yli tuplasti enemmän kuin kävelynopeus. Tämä muuttaa kaupunkikulkemisen "maantiedettä" kun kaikki bussinvaihtojen väliset matkat voi tehdä tällä ja jättää jopa bussit kokonaan väliin. Airwheelin paino on n. 10kg joten kovin pitkiä matkoja sitä ei viitsi/jaksa kanniskella vaikka netin videoissa neitoset sitä kevyenoloisesti nostelevatkin. Uskonkin että tulevaisuudessa kun käyttäjäkunta kasvaa, painoa saadaan vielä hilattua alemmas. Löytyy kuitenkin jo käyttäjien itse-tekemiä "kantokahvoja" joilla Airwheeliä voidaan vetää perässä tai työntää edessä kuin matkalaukkua. Kehitys on vasta alussa.

Suomessa Airwheeliä markkinoi esimerkiksi teinitähti Robin. Toivoisin kumminkin ettei Airwheel identifiotuisi pelkästään nuorison temppulaitteeksi. Silti Robin osaa omissa videoissaan käyttää Airwheeliä paljon näppärämmin kuin minä.

Minun laitteessani on 170Wh:n akku jolla pääsee n. 23km:n matkan. Kun matkanopeus on 12km/h niin se tarkoittaa n. kahden tunnin käyttöaikaa ja n. 90W:n kulutusta(arvio). Kun sähköauto vie n. 23kW niin tämä 90W:n kulutuksella on varmaan se kaikkein tehokkain moottorikulkuneuvo.

Akkupaketti ei ole vaihdettava ts. mitään vaihtoakkuja ei ole myynnissä mutta toivottavasti akut voi vaihtaa myöhemmin ruuvimeisseliä käyttäen. Akkujen pitäisi kestää 1800 latausta joten päivittäisellä käytöllä kysymys tulee eteen vasta viiden vuoden päästä. Kilometreinä tuo tekee 40 000 kilometriä.

Tietenkään tätä ei ole vielä hyväksytty tieliikennekäyttöön. Suomen lainsäätäjät kun ovat näissä asioissa niin nopealiikkeisiä ja turvaallisuustietoisia ettei Suomessa saa vielä käyttää edes Segwaytä kun se on niin vaarallinen. Mainittakoon tässä että esim. Barcelonassa ja Berliinissä järjestetään turisteille Segwayllä turistikierroksia ts. turisteille pieni koulutus ja sitten normaalin liikenteen sekaan jonoon ajamaan. Ja Suomessa esim. poliisi ei saa ajaa omalla Segwayllaan koska se on laitonta...

Ehkä tässä kuitenkin on toivetta lainsäädännön muutoksesta, kun Liikenne -ja viestintäministeriössä on asiaa taas pohdittu:
LVM: Kevytajoneuvot: Yhteenveto työpajoista ja pienpalavereista
Iltasanomat : Uuteen tieliikennelakiin tulossa koko joukko aiemmin tuntemattomia ajoneuvoja

Itse rinnastaisin tuon polkupyörään painon perusteella. Itsekseen se ei lähde ajelemaan eikä painoa tosiaan ole enempää kuin 10kg.

Sain oman laitteeni viime viikon alussa ja ensimmäisen opettelu oli jo keskiviikkona. Minulla ei ole apupyöriä ja päätellen oppimisen nopeudesta ne ovatkin aika turhia. Mukana oli hihna jolla voin tukea Airwheeliä liikkeessä mistä oli hyötyä alussa.

Ensimmäisiä opetteluita: ota tukea jostain ja nouse pyörän päälle. Tässä vaiheessa on paras että pyrit pistämään jalat jalustojen keskelle. Pitäen tuesta kiinni liikuttele pyörää edestakaisin jotta saat tuntuman siitä miten kiihdytys, jarrutus ja takaperin ajo sujuu. Muista että nämä pitää mennä lihasmuistiin, joten älä katso pyörää vaan katso eteenpäin ja mieti enemmän sitä miltä pyörä tuntuu. Silmistäsi ei oikeastaan ole tässä hyötyä, tärkeintä on lihasmuisti ja tasapainon oppiminen. Voit toisella kädellä ottaa tukea ja toisella pitää pyörän tukihihnaa.

Ilman tukea pyörälle nousu oli sitten niitä vaikeimpia opeteltavia kun alussa oli hyvin tarkkaa että sain jalat oikeaan kohtaan. Vaikka neuvottiinkin että on paras että jalat ovat tuen keskellä niin minusta oli parempi että olin hieman etupainoinen ts. päkiä oli tuen reunalla. Tällöin jo heti pyörälle noustessa se hieman lähti menemään eteenpäin ja hyrrävoima auttoi pystyssä pysymisessä. Sitten kun nousun oppii niin kaikki tulee jo selkäytimestä eikä näitä tarvitse erikseen miettiä ja kiihdytys toimii kuin ajatus. Opetteluvaiheessa viivettä oli vain liikaa pyörälle nousu - eteenpäin lähtö. Tästä päivästä jäi myös kunnon mustelmat kumpaankin jalkaan nousuharjoituksista. Keskiviikkona meni opetteluun n. 2 tuntia ja en päässyt kuin maksimissaan ehkä viitisen metriä kerrallaan.

Torstaina sitten tajusin vasta puolivälissä kahden tunnin treeniäni että itse asiassa tässä vaiheessa tukihihna vain haittaa asiaa kun en voi käyttää kumpaakin kättä tasapainotteluun joten jätin hihnan pois ja kummatkin kädet lentokoneasentoon. Tämän jälkeen pääsinkin heti 50 metriä eli parkkipaikan päästä päähän. Torstain toinen puolisko menikin sitten pitempiin ajoihin ja kääntymisen opetteluun. Otin myös silmälasit pois mikä helpotti sitä että pystyi keskittymään ajamaan "fiiliksellä". Näen joka tapauksessa muutoin riittävän hyvin mutta jokaisen pikkukiven ja oksan näkeminen ei muuta kuin haitannut keskittymistä. Vasta nyt loppui akku ensimmäisen kerran kesken ts. opetteluvaiheessa se kesti nelisen tuntia.

Perjantaina sitten kun sain taas palautettua edellisen päivän opit muistista, ajoinkin melkein koko kahden tunnin. Keskeytyksiä tuli varmaan vain kymmenisen kertaa. Opettelussa oli käsien käytön vähentäminen, käännökset ja pujottelu. Pyrkimys oli ajaa mahdollisimman vähän suoraan koska siinä oppii vähiten. Muun liikenteen eli jalankulkijoiden seassa en pysty vielä ajamaan joten parkkipaikkaharjoittelua ja hiljaisempia pyöräteitä. Ja tosiaan, pyöräteillä ajetaan yleensä suoraan joten mieluummin pysyin parkkipaikalla opettelemassa kääntymisiä.

Talvi tulee joten yksipyöräisen käyttö jäänee vähemmälle mutta etelän talvet eivät ole pitkiä joten eiköhän keväällä Airwheel ole hyvinkin pian taas käytössä.

Sunday, November 30, 2014

About benchmarking Hadoop systems and scalability

I've been reading a lot of benchmarks for Hadoop technologies lately and these benchmarks that software companies make should always be taken with a grain of salt. Every new version or software is 10-100 times faster than the others.


IBM did a benchmark with Big SQL 3.0 against Cloudera Impala and Hortonworks Hive. The results were very good and I'm not claiming the results are false. But there was one claim that caught my attention.

There were some charts about scalability when the same 99 test queries were run with 1 user vs. 4 users. The 4 concurrent users test took only 1,8 times longer than 1 user test and it was said it is a sign of good scalability.

Blistering Fast SQL Access to Hadoop using IBM BigInsights 3.0 with Big SQL 3.0

Of particular note is the fact that 4 concurrent query streams (and therefore 4 times more queries) only takes 1.8x longer than a single query stream at 30TB. Once again highlighting Big SQL’s impressive multi-user scalability – this time at 30TB.


Serialized vs. parallelized execution 

 

With parallel systems it is essential that the execution can be parallelized as evenly between all the nodes as possible. If in test system ( 17 nodes in IBM's test) only one node is used 100% and others are idle, that means the execution is serialized.

Even then the execution is serialized if the it uses multiple nodes, but only one node is used at a time. I've seen software that should be multi-threaded but it in fact behaves single-threaded, using many processors but only one at a time.



Here is an example of 20 second query that uses all 4 nodes but actually it is only using one node at a time. The execution in the next node does not start before the earlier node has finished. The execution is serialized.



Here is perfectly parallelized execution. It uses 20 seconds of CPU as the other one, but now it uses all nodes in parallel and the whole execution only lasts for 5 seconds. Normally these kind of executions exist only in computer labs. These have not been seen in wild. If you see, contact local authorities.

What can be parallelized?

 


In a Hadoop system the primary resources that can executed in parallel are CPU, memory, disk and network. Each of these resources is also finite and can be overloaded. Execution can also be parallel in that way that one thread uses CPU, one thread disk and one thread network without affecting each others performance.

When a resource is overloaded it might simply make every execution slower in a linear way but a resource might also be so overloaded that it cannot execute any more requests like what happened to Impala and Hive in the test with memory running out.

How parallel was Hadoops execution in test?


If the test query is evenly parallelized, then every node and every resource is used 100%. If you run 4 concurrent tests then if it's is evenly parallelized,  the minimal time it takes to execute is four times longer. If 4 concurrent tests take less time than that, then it wasn't evenly parallelized in the first place. Remember that this applies to every resource in every node: CPU should be used 100% and every disk should by used 100%.

If I'm doing a benchmark, of course I select that amount of concurrent users that gives the results that appear to show best parallel execution.

In an execution there are parts that are serialized and parts that are parallelized. Lets try to calculate how much there is serialized execution in this Hadoop test. Lets make highly simplified model.

S is the execution time for serialized part and P is the execution time for parallelized part. Single_time is test execution times for single user test and parallel_time is the time of one execution in multiple concurrent users time. Threads is the amount of concurrent users and nodes amount of nodes.

Lets make assumption in our model that the serialized parts always get one whole node because that would be the case if we want to show results that appear as best parallel execution. The parallel part has to divide nodes between concurrent users.

single_time = S + P/nodes
parallel_time = S + threads*P/nodes

Let do some math:
single_time = S + P/nodes
single_time - S = P/nodes
nodes(single_time - S) = P

parallel_time = S + threads*nodes(single_time - S)/nodes
parallel_time = S + threads*(single_time - S)
parallel_time = S + threads*single_time - threads*S
parallel_time - threads*single_time = S - threads*S
parallel_time - threads*single_time = (1 - threads)*S
(parallel_time - threads*single_time)/(1 - threads) = S
S = (parallel_time - threads*single_time)/(1 - threads)

P = nodes(single_time - (parallel_time - threads*single_time)/(1 - threads))

In IBM's test the 4 user test was 1,8 times longer then single user test so:
single_time = 1
parallel_time = 1,8
threads = 4
nodes = 17
=>
S = 0,733....
P = 4,533...
Whole execution time S+P = 5,266...
S% (serialized part percentage) = 13,9%


We can calculate how these figures change if we add or substract nodes:
          Nodes         S         P         S+P         S%
3 0,7333 0,8000 1,5333 47,8%
4 0,7333 1,0667 1,8000 40,7%
5 0,7333 1,3333 2,0667 35,5%
6 0,7333 1,6000 2,3333 31,4%
7 0,7333 1,8667 2,6000 28,2%
8 0,7333 2,1333 2,8667 25,6%
9 0,7333 2,4000 3,1333 23,4%
10 0,7333 2,6667 3,4000 21,6%
11 0,7333 2,9333 3,6667 20,0%
12 0,7333 3,2000 3,9333 18,6%
13 0,7333 3,4667 4,2000 17,5%
14 0,7333 3,7333 4,4667 16,4%
15 0,7333 4,0000 4,7333 15,5%
16 0,7333 4,2667 5,0000 14,7%
17 0,7333 4,5333 5,2667 13,9%
18 0,7333 4,8000 5,5333 13,3%
19 0,7333 5,0667 5,8000 12,6%
20 0,7333 5,3333 6,0667 12,1%
21 0,7333 5,6000 6,3333 11,6%
22 0,7333 5,8667 6,6000 11,1%
23 0,7333 6,1333 6,8667 10,7%
24 0,7333 6,4000 7,1333 10,3%
25 0,7333 6,6667 7,4000 9,9%
26 0,7333 6,9333 7,6667 9,6%

We can see that serialized part of time stays the same so amount of nodes does not affect it. The test had at least 17 nodes and as I said earlier the actual "node" count is higher because it should be the amount of individual resources(CPU & disk in each node) . But as we can see from the calculation, the S% does not change that much when node count is higher. (And you have to also understand this is only a simplified model )

The parallelized execution time P is the whole summed execution time of all nodes used. So actually the time it takes to execute the parallelized part is constant 0,266... I'm not saying it does not matter how many nodes you use in your test. I'm saying to get these kind of results (one thread 1, 4 threads 1,8x) it does not matter how many nodes you had in your test. It only matters how the execution was parallelized.

We can also see than when there are 17 nodes, the serialized part takes 73% of the execution time and parallized part 27%. 

How does it scale then? 


Let's make a simple example where the original test only had 4 nodes.

This is how a single thread executes:



First it executes the parallel part in 4 nodes and then continues with serialized part in one node. The reality is of course much more complex. As you can see, when the serialized part starts, three nodes are idle.

Here is what happens when 4 threads are run in 4 node system.




The serialized part executes as single thread test but parallelized part has to divide nodes between all threads. Then 4 thread execution is about 1,8 times slower than single thread execution. No nodes are idle. This is how 4 thread execution is only 1,8 times slower:in the single thread execution there are idle resources because it is not perfectly parallelized.

What happens when we add 5. thread?


We start to see normal behaviour in scaling. There are no idle nodes to utilize any more.

Conclusion


I don't have the test results of individual queries or data about resource consumption So I had to try to mathematically make a model about what is happening. There might also be other reasons like disk caches because all 4 threads execute the queries in the same order (actually that was not said in paper how it was run).

But I'm sure one of the reasons is also serialization. It is not a good thing to have serialized parts in executions because if you add more nodes to have faster executions, only the parallelized part gets faster. If it's true that 73% of execution time in test was serialized that is the part you will never get rid of by simple adding more nodes. This is why it's is good to have a proper benchmarking when you build your Hadoop system.

Tuesday, November 11, 2014

IoC ( Internet of Cigars) - enabled humidor!

The latest trend: IoC or Internet of Cigars is here! :)

I tried for a long time to keep humidity in my cigar humidor at constant level. No luck. I have humidity beads from Heartfelt Industries designed to keep 65% humidity but still there was too much fluctuation in humidity, one loss of all cigars because of mold and too much work to check the humidity levels often enough.

That was before my humidor was connected to the Internet of Cigars.

The sensor

My humidor has Zwave humidity sensor Everspring ST814 that sends report to my home automation system every time humidity changes 5% and temperature by 0,1C. I would like to have a sensor that reports humidity even more often but the market is small.

Home automation system itself doesn't do anything for data because it has limited capabilities for graphing the historical values so I've configured it that is only receives the Zwave reports. Home Automation software I use (OSA) has also RESTful interface so it's easy to make queries of current humidity in humidor.

The monitoring and graphing


For graphing and alerts I use Cacti, widely-used monitoring and graphing tool. Cacti is open-source which means it's not the user-friendliest software in the world but like many OS software it is powerful and versatile. It is easy to write scripts to Cacti that then acts as sensors. The Cacti is written in Perl so the native language for monitoring scripts is also Perl. The Cacti script for Zwave humidity sensor simply fetches the RESTful data in JSON and reads the temperature and humidity values to Cacti. With Perl it's only a 10-20 lines of code.

The database 


Cacti uses RRD database for sensor data and RRD stands for Round Robin Database. RRD saves values in pre-created constant-sized database files and when it reaches the end of file it starts over in Round Robin fashion. There can be many files in that way that one file contains data in week level, one in month level and one in year level each with different temporal resolutions.



Here's a hourly view.


Daily view, same straight line so let's skip the Weekly and Monthly views and go straight to Yearly view.


The notifications


Cacti has a plugin architecture and it being open source, it has lots of plugins. Plugin I use to alert me is Threshold. When the humidor humidity is too high(>75%) or too low(<60%), the Threshold plugin sends me an email every four hours. As you can see from the yearly view I have to add some water to humidor once in a month. I could tighten the warning levels a little bit but this is not too much work for a lazy smoker I am. The alerts are send with sendmail so some additional configuration was needed that Cygwin environment was able to send mails via SSMTP.


 
My Internet of Cigars keeps a constant watch of my cigars well-being and gives orders to water boy (me) to refill the beads with water. Now I can enjoy my cigars with no stress and wait for IoC to appear in Gartner reports :)


Sunday, November 9, 2014

Reason why Donetsk People's Republic's elections held in 2.11.2014 are fraud


First you should read the blog post I use as a reference.

Elections in Donets - anatomy of a fraud.
I think this needs more publicity. I try to explain how this kind of results of elections in East Ukraine are impossible.

First the official results:
Zaharchenko     : 765 340 / 969 644
Kofman             : 111 024 / 969 644
Sivokonenko      :  93 280 / 969 644
Discarded votes : 43 039 / (969 644+43 039)

Everything seems to be ok?

Then we calculate the percentages:
Zaharchenko     : 765 340 / 969 644 = 78,92999905119820000%
Kofman             : 111 024 / 969 644 = 11,44997545490920000%
Sivokonenko      :  93 280 / 969 644 = 9,62002549389260000%
Discarded votes :  43 039 / (969 644+43039) = 4,24999728444143000%

The problem with these figures is that the first two decimals are ok, but then at least the next two decimals are either 00 or 99 which means they are very close to two-decimal numbers. All of them.

Lets take Zaharchenko's votes for further examination:
Zaharchenko: 765 340 / 969 644 = 78,92999905119820000%
That is really close to 78,93%
In fact it is not possible to get percentage to 78,93% because you would not get whole votes:
969 644 * 78,93% = 765340,0092000 votes
So if you first "invented" the two decimal percentage as voting result and then calculate the vote count, you would have to truncate to 765340.

There were 969 644 accepted votes. That means there are 969 644 possible results for Zaharchenko and probability of any result is 1/969644.

There are 10000 possible percentages with two decimals. Because the accurate two decimals results are not possible and it's almost always between two votes, lets take the both upper and lower vote counts. So possible vote counts for two decimal percentage are ~20000.

The probability that Zaharchenko's vote count is one vote near the two decimal percentage is 20000/969644 ~ 1/50. That is 2% probability. That is not impossible, that could happen. It means that if you held elections anywhere in the world and you pick 50 candidates, at least one of them is propable to have two decimal percentage.

Let's then get the two decimal percentages for all the candidates:
Zaharchenko     : 765 340 / 969 644 = 78,93%
Kofman             : 111 024 / 969 644 = 11,45%
Sivokonenko     :   93 280 / 969 644 = 9,62%
Discarded votes :  43 039 / (969 644+43 039) = 4,25%

It's here when things get highly improbable.
Zaharchenko's probability 1/50
Kofman's probability 1/50
Sivokonenko probability 1/50
Discarded votes probability 1/50.

Because sum of candidates votes is 100% it is not possible that two candidates have two decimal percentages and the third to have more decimals. So we only use probabilities of the candidates because the third one's probability is "tied" to two first ones probability and therefore his probability is 1/1 meaning it always happens. The probability that the three candidates all have two decimal percentages is therefore 1/50 * 1/50 * 1 = 1/2500.

Then we add the discarded votes and the probability that all the percentages have two decimals is 1/2500 * 1/50 = 1/125 000 or 0,0008% probability . That's the smoking gun. That means DNR should have 125 000 elections and get one result like this. Of course, it is still possible. At least in Donetsk People's Republic. 

PS. The elections held in May 2014 in DNR and LNR had only one decimal percentages.