748 Sol/sec Zcash (equihash) teljesítmény egy GTX 1080 Ti kártyából

A korábbi Zcash cikkben már említettem, hogy egy eléggé ütött-kopott gamer géppel (4 éves szerzeményem) fogtam neki a Zcash bányászatnak. Hírtelen ötlettől vezérelve és némi költés/megtérülés számítás, plusz némi internetes utánajárás után úgy döntöttem, hogy megnézem mit lehet most kihozni a piacon elérhető legjobb nVidia asztali GPU-ból. Ez egyébként a Nvidia Geforce GTX 1080 Ti-ből a ROG STRIX verzió, amire rápakoltak 11Gb memóriát. A beruházás nem volt olcsó, ennyiből vetten anno a bitcoin ASIC minereimet is, viszont az előzetes kalkulációk alapján, ha tudja hozni a kártya az elvárásokat, akkor legkésőbb 4 hónapon belül visszatermeli a saját árát. Az eredményt már ellőttem a címben (748 Sol/s), de álljon itt akkor a screenshot is az első körös mérésekről:

Folytatás…

Zcash (ZEC) – praktikus tanácsok bányászathoz

Néhány éve követem a cryptocurrency bányász közösségeket és időszakosan bele-bele ugrok egy-egy konkrét coin farmolásába is. Most éppen a Zcash van a soron – akinek nem mond semmit a Zcash (ZEC), annak erről részletes cikk: [link], amivel kapcsolatban megosztanék néhány friss és nem annyira friss tapasztalatot.

Egyrészt a Zcash erősen ASIC mining ellen védett algoritmus, így várhatóan hosszú távon védett a folyamatos bányász erőforrás leértékelődéstől. Erről a témáról az előző cikkben már részletesen írtam, de gyakorlati szempontból azt prognosztizálom, hogy azok a bányász gépek, amik MA képesek profittal termelni, azok legalább egy évig képesek is lesznek ezt hozni. Optimális körülmények között ez akár még több ideig is fennállhat. A bányászati felezési idő a Zcash kapcsán is 4 év, hasonlóan a bitcoinhoz. (felezési idő: Az a pont amikortól már csak fele annyi jutalom jár egy block kibányászásáért). A jó hír, hogy a Zcash kapcsán még csak az első félévnél tartunk. 

Gyors kitekintés arról hogy mi is a bányászat: Ha most találkozol először ezzel a kifejezéssel, akkor minden bizonnyal értetlenül állsz az előtt, hogy mi is ez és miért is lehet ebből (crypto) pénzt keresni. A legtöbb crpyto pénz esetén maga a fizetőeszköz (legyen az akár bitcoin, LTC vagy akár Zcash) a bányász tevékenységért cserébe kerül ‘kifizetésre’ a bányászoknak. Ez az egyetlen módja annak, hogy új coin keletkezzen. Ezt kvázi fogadjátok úgy el mint a pénznyomtatást. A bányászok a munkájukért cserébe teljesen új addig ki nem adott cryptopénzt kapnak. A bányászat egy nagyon bonyolult számításigényes művelet, amit ráadásul egy algoritmus folyamatosan képes bonyolultabbá vagy éppen egyszerűbbé tenni, függően attól, hogy éppen mennyi aktív bányász van és mekkora sebeséggel tudnak bányászni. Ez az algoritmus szabályozza, hogy közel azonos ideig tartson egy block bányászata ma és egy év múlva is. A bányászat nem feltétlenül egy hobbi, amiért a munkaállomásunk erőforrásait csutkán kihajtva (crpyto) pénzt kapunk. Valójában ez a folyamat a tranzakciók hitelesítésében játszik szerepet. Nagyjából 2,5 percenként kerül kiadásra egy-egy újabb blokk, ami tartalmazza az éppen futó ZEC tranzakciókat is. Tehát a bányászok valójában a tranzakciók hitelesítésével foglalkoznak. A hitelesítés során kerül eldöntésre, hogy a Zcash blockchainből éppen utalni kíván darabka valóban a küldő tulajdonában van-e és jogosan rendelkezik felette. Ez kvázi azonos folyamat mint amit a bankod végez amikor egy utalásodnál elvégzi a fedezet vizsgálatot. Ahogy a bankszámlád teljes tartalmát nem tudod gyorsan elküldeni kétszer két különböző helyre (ezzel új pénzt generálva), ugyanígy nem tudod ezt eljátszani a blockchainben található Zcash coinokkal sem. Ezen folyamatot a bányászok biztosítják. 

Folytatás…

Zcash (ZEC) – újra bányászunk!

Korábban már írtam, hogy aktívan foglalkozom cryptocurrency – akkoriban ugye Bitcoin (BTC) – bányászattal. Három Antminer dualblade-S1-essel farmoltam a bitcoint még 2014-2015-ben, amik jó fél év alatt behozták az árukat és az akkori BTC árfolyamon még némi profitot is termeltek. A bitcoinok egy részét eladtam, a nagyobb része viszont a mai napig megvan. Vettem is hozzá 250USD körül, így a mai 1300-1400USD-s árával bőségesen jó befektetésnek bizonyult beszállni ebbe az üzletbe. Hanem ugye kb két éve ezek az ASIC miner célhardverek elérték az ár/érték köszübüket, amikor is a folyamatos difficulty emelés miatt már nem érte meg folytatni a BTC bányászatot, hiszen több áramot használtak a gépek, mint amennyit az akkori árfolyamon BTC-ben termeltek. Akkoriban komoly dilemmában voltam, hogy visszaforgassam-e a befektetést és vegyek erősebb ASIC miner gépeket. Végül  úgy döntöttem, hogy inkább kiszállok. Mindezzel párhuzamosan kezdett el komolyabb teret nyerni számos alternatív crypto fizetőeszköz is. Akkoriban főleg az LTC (LightCoin) pörgött aktívan.

Az LTC és számos további alternatív digitális fizetőeszköz is a Scrypt (és alternatívái) algoritmusra épült, ami a bonyolult számítási műveletek mellett még nagy mennyiségű memóriát is igényel. Ezen tulajdonsága miatt is nevezik ezeket az algoritmusokat “ASIC ellen védett”-nek, hiszen nem elég a számítási kapacitást párhuzamosítani pici cél processzorokkal (ugye ez a lényege az alkalmazás specifikus integráltáramköröknek), de mindehhez még tetemes mennyiségű memória is kellene, ami miatt nem igazán lehet hozzá hatékonyan gyártani bányász célhardvert.

Folytatás…

NumPy (Python) és a Sharpe ratio barátsága

Kissé nagy fába vágtam fejszémet a Machine Learning cikksorozatom kapcsán, amikor az előző fejezetben azt ígértem, hogy hamarosan konkrét alkalmazást fogok bemutatni a gépi tanuláshoz. Már persze nem az okozza fejtörőt, hogy élő példát mutassak az alkalmazásra, hanem, az hogy miként lehet ezt normálisan a blog keretei között bemutatni. Az ezzel kapcsolatos cikk vagy iszonyatosan hosszú lesz és szinte lehetetlen lesz követni, vagy pedig olyan tudásra kell hagyatkoznom, amivel az olvasó vagy rendelkezik, vagy nem. Ez utóbbi eléggé lutri. Ezért néhány kitekintő cikkel mutatom be a NumPy alapjait, ami egyébként lényegében az összes python alapú tudományos számítási és machine learning megoldás alapját is adja.

A numpy néhány alap funkcióját egy nagyon tipikus pénzügyi metóduson keresztül (Sharpe ratio számítás) mutatom be: Ennek lényege, hogy valamilyen ismert kockázatmentes portfolióhoz/termékhez képest kerül mérésre egy adott eszközalap vagy részvénypiaci termék teljesítményének szórását. Sharpe ratio lényegében egy referencia értéket ad meg, ami egységesen mutatja az adott eszközalap kockázat-hozam mutatóját.
Folytatás…

Machine Learning (ML) II. fejezet – lineáris regresszió

Ez a cikk egy több fejezetes gépi tanulásról szóló cikksorozat második fejezet. A jelenleg elérhető fejezetek:

  1. Machine Learning (ML) I. fejezet – ismerkedés az alapokkal

Miután az alapokkal megismerkedtünk ideje belecsapni a lecsóba. A Machine Learning (ML) egyik leggyakrabban használt és legszélesebb körben ismert interpretációja a regresszió és annak alternatívái közül is a lineáris regresszió. Sokan ezen szó hallatán gyomorgörcsöt kaphatnak és rémálomként idézhetik fel az egyetemi mat/gazd. stat. élményeiket. Igen, ez ugyanaz a regresszió, amiről ott is tanultatok.

Azon olvasóknak akiknek vagy már megkopott ez a tudása, vagy nem is tűnik számukra ismerősnek ez, azoknak egy kis gyorstalpaló:

Folytatás…

Machine Learning (ML) I. fejezet – ismerkedés az alapokkal –

Ez a cikk egy több fejezetes gépi tanulásról szóló cikksorozat első fejezet. A jelenleg elérhető fejezetek:

  1. Machine Learning (ML) I. fejezet – ismerkedés az alapokkal
  2. Machine Learning (ML) II. fejezet – lineáris regresszió

Sokszor hallottam, olvastam már, hogy a Machine Learning (ML), magyarul: Gépi tanulás, lényegében egy olyan szintje az informatikának és az adatelemzésnek, amely már sokkal inkább tudományos tapasztalatokat igényel, mintsem programozói ismereteket. Sok esetben valamiféle mesterséges intelligenciának tekintik a ML-t (nem alaptalanul), amely abból a szempontból igaz is lehet, hogy a hétköznapi életben ismert és használt gépi tanuláson alapuló megoldások (pl. beszédfelismerés, képeken arcfelismerés, stb.) valóban mesterséges intelligenciára és gépi tanulásra épülne. Ettől függetlenül a gépi tanulás egyébként közel sem annyira nagy ördöngösség ami miatt tudományos fokozat kellene a megértéséhez és használatához.

Folytatás…

Hybrid + Napelem: Tapasztalatok 4 év után

A blog minden bizonnyal egyik leginkább keresett bejegyzése a mai napig a hasonló címmel megjelent írásom ami 10 hónap fényében mutatta be a korábbi saját beruházásból megvalósított fűtés korszerűsítést, mely során a fűtést un. hybrid gázkazán és levegős hőszívattyús rendszerrel oldottam meg, amihez az áramot napelemmel termelem. A konstrukció részleteit az eredeti cikkben fejtettem ki.

A cikkben az első 10 hónapos eredmények alapján azt prognosztizáltam, hogy a korábbi fűtési rendszerhez képest évi 669ezer forintos megtakarítást tudok elérni, amivel alig 4,5 év alatt pozitívba fog tudni fordulni a beruházás. Most, hogy lassan véget és a negyedik fűtési szezon is (bár ennek némileg ellent mond az időjárás) itt az ideje, hogy visszamérésre kerüljön a prognózis.

Folytatás…

Timeseries vizualizáció: Kibana Timelion

Jelenlegi post még a timelion funkcionalitására épül, azonban itt jegyezném meg, hogy az 5.4-es főverzió kapcsán kiadott közlemény alapján ezek a funkciók (vagy legalábbis nagy részük) már elérhető lesz közvetlenül a beépített Kibana vizualizációs eszközökkel is. Addig is amíg nem kerül kiadásra az 5.4, viszont marad a timelion. A timelion eredetileg egy függetlenül fejlesztett Kibana plugin volt, ami az 5.0-ás főverziótól kezdődően beépült az alap Kibana funkciók közül (a Sense pluginnal együtt).

A timelion talán legfontosabb funkciója az összehasonlítható és vizuálisan részletgazdagabb chartok képessége. Mindemellett a timelionban készített vizualizációk minden gond nélkül rárakhatók tetszőleges dashboardra vegyesen akármilyen más Kibanás vizualizációval együtt.

Folytatás…

Elasticsearch Index és a performancia

Az Elasticsearch alapértelmezetten nem spórol az indexekben tárolt dokumentumok kapcsán az erőforrásokkal. Ha az adott index nem rendelkezik egy jól felépített és átgondolt mappinggel, akkor az ES gyakorlatilag “szabadfolyást” tart, minden szöveges típust analizál, minden olyan adatot ami rendezhető vagy aggregálható azt inmemory bufferbe lapoz, ráadásul menedzsel egy csomó olyan virtuális fieldet is mint pl az: _all.

Ezzel az ES egy végtelen rugalmasságot és könnyed felhasználást teszt lehetővé, ami a legtöbb projekt esetén egyébként nagyon pozitívan értékelhető hozzáadott érték. Azonban ennek megvan az ára, ez pedig a performancia. Egy tetszőleges ES installment esetén elmondható, hogy néhány millió dokumentumig nem nagyon kell foglalkozni a mappingekkel, hiszen itt még bőven érvényesül az a fajta distributed processing hozzáállás, hogy ha kezd lassulni az indexelés vagy a keresés, akkor bővíteni kell a clustert egy-két extra node-dal (már persze ha az index shard beállításainál ügyeltünk arra, hogy ennek legyen értelme…) és máris normalizálódik a performancia.

Folytatás…

Passzív irodaház, megtapasztalva…

Az elmúlt években volt szerencsém nagyon sok ‘green’ filozófiában megihletett irodaházban járni, sőt büszke vagyok arra, hogy én is egy olyan irodaházban dolgozhatom, aminek a kialakítása során arra ügyeltek, hogy az irodaház alapterületével azonos mennyiségű zöld felületet alakítsanak ki az épületen belül, ezzel persze “hasznos irodaterületet” vesztettek el, de mégis egy sokkal élhetőbb környezetet varázsoltak, hiszen még az irodaház belső tereiben is van lehetőség az ablakokon kinézve gondos munkával ápolt kerteket látni. Na ezt az élményt sikerült a múlt heti brüsszeli látogatásom során überelni, amiről gondoltam írnék azért néhány gondolatot, csak hogy ne merüljön fel bárkiben is, hogy a nagy Elasticsearch és big data kalandozásom során megfeledkezem az ökolábnyom témakörről…

Folytatás…