2017-05-20 20:59:32

Nová základní škola

Naše holky chodí od dubna do nové základní školy. Spoustu lidí se nás ptá, proč jsme to udělali a v čem je nová škola lepší. Zde je - poněkud obsáhlejší - odpověď.

Předně musím říct, že téměř žádná škola není asi úplně špatná. Ani ta naše bývalá není špatná. Děti dokáží vyrůst a vzdělat se i různým systémům navzdory. Ale také existují školy, které jsou lepší. A také existují různé školy a každému vyhovuje něco jiného - viz zápisek o škole Michaela. A na prvním stupni základní školy více než jinde záleží na učiteli. Takže pokud máte výbornou učitelku tak se jí držte a na zbytek nehleďte.

A ta úplně nejdůležitější věc je aktivní rodič. Pokud se spolehnete, že tato škola "je údajně výborná" a dáte tam děti a za devět let je vyzvednete a budete čekat že vám je někdo vzdělal, tak to je úplně špatně. Získat si informace o školách v okolí je práce. Hodně práce.

Jak poznat dobrou školu?

  • Má škola vizi? - děkan pedagogické fakulty MU Jiří Němec definuje kvalitní školu takto: "Kvalitní škola je ta, která umí dobře popsat své vize, hodnoty, procesy apod., které jsou ve vzdělávání klíčové, a v praxi se snaží je naplnit." Pokud vaše škola nemá vizi, tak nemá za čím jít. Jenom bude plnit zákonné povinosti. Ale to mi přijde jako sakra málo. Vize můžou být různé: "Sounáležitost s přírodou", "Změna je kontinuální stav", "Výuka experimenty". Ovšem být "spádová škola" není žádná vize.
  • Chodí učitelé na kurzy? - zlé jazyky tvrdí, že školství se nezměnilo od dob Komenského. Něco na tom sice je, ale i tak je ve školství mnoho novinek. Já osobně se snažím jít každý rok alespoň na jeden kurz tvrdých znalostí a jeden kurz soft dovedností. Od dobrého učitele bych čekal něco podobného.
  • Prověřujte si "fakta". - Třeba naše původní škola se chlubí takovýmto certifikátem: Aktivní škola Což vypadá velmi dobře. Každý je rád, když je jeho škola aktivní. Ale když se budete snažit zjistit co to vlastně znamená, tak nejdřív zkusíte AktivniSkoly.cz, což po přečtení už není tak skvělé. Ale pak zjistíte, že certifikát od nich není, ale je od ProSkoly.cz, která ten certifikát dá každému, kdo si od nich koupí testy. Což špatné není, ale úplně cool taky ne.
  • Kolik je dětí ve třídě? - Samozřejmě platí, že čím méně dětí tím lépe. A také jak se učitel a ředitel staví k asistentům pedagoga ve třídě. Protože integrovaných dětí s různými specifickými vzdělávacími potřebami ve třídách přibývá a pokud se tato situace neřeší, podepisuje se to na všech zúčastněných.

Kde získat informace o školách?

Tak na to je dost těžká odpověď. V Brně se v Lužánkách pořádá Veletrh základních škol. Ale prezentace je jedna věc a realita druhá. Vlaďka (moje žena) na mnoha školách učila a s některými školami, jejichž prezentace byla výborná, měla negativní zkušenost. Ale rozhodně to může být jeden z faktorů pro rozhodování.

Běžte se do školy podívat. Pokud to nejde a nikdo na vás nemá čas, tak se zřejmě jedná o "spádovou školu".

Proč jsme přestupovali v průběhu roku?

Tak tohle rozhodnutí bylo úplně pragmatické. Hledali jsme vhodnou školu několik měsíců. V jedné škole měli místo jenom pro jednu naši holku a pro druhou neměli otevřenou třídu. Ve druhé škole měli místo pro obě, ale škola byla nově otevřená a bylo vidět že přestupů ve vyšších třídách je tam docela dost. Takže reálně hrozila možnost, že pokud budeme vyčkávat až do září, tak už nebude volné místo. Což se ukázalo být pravda, protože starší dceru brali do třídy jako poslední. Opozdit se o pár dní, tak hledáme dál.

Jak to děti nesly?

Starší dcera (3. třída) neměla nejmenší problém a z nové školy je úplně nadšená. Mladší dcera (1. třída) to nesla hůře a dost jsme se trápili. Ze školy jako takové byla taky nadšená, ale změna samotná byl problém. Ale snad to nezakřiknu, když řeknu že po měsíci a půl už to vypadá dobře.

Scio škola

My jsme nakonec zakotvili ve Scio škole. Nebudu rozebírat proč jsme se rozhodli pro tuto školu. Ale popíšu ty očividné odlišnosti:

  • Škola začíná v 8:30. Což částečně kompenzuje to, že více času spotřebujeme na dojezd. A tak vstáváme dokonce o 15 minut později. Což je sakra znát. Kurz je asi takový že 15 minut ráno se rovná jedné hodině večerního času :)
  • Nejsou domácí úkoly. Učit se mají ve škole. Doma dělají jiné aktivity.
  • Důsledkem předchozího bodu je, že si mohou nechávat všechny věci ve škole. Do školy chodí jenom se svačinou a občas s tělocvikem. Jednou za čas donesou pouzdro a ukázat co udělaly.
  • Ve škole mají předmět "Svět v souvislostech", kde probírají věci, které nejsou zařaditelné.
  • Několikrát měsíčně se vyjíždí mimo školu. Z poslední doby: zvířecí útulek, různá sportoviště...
  • Děti mají vlastní samosprávu. Pokud doloží životaschopnost myšlenky (neboli business plán), tak mohou své projekty realizovat. Z poslední doby: školní morče, bufet provozovaný dětmi...
  • Nezvykle velký počet mužů mezi učiteli.
  • Slovní hodnocení.
  • Velká míra samostatnosti. Děti mají předmět Trivium a samy si určují, zda se budou učit počty, češtinu a v jaké formě (čtení, psaní, sloh). Plus mají povinné úlohy a nepovinné úlohy a samy si volí jaké problémy a příklady budou řešit.
  • Na Facebooku máme uzavřenou skupinu, kam průvodci (tj. učitelé) dávají několikrát týdně statusy a fotky toho na čem děti pracují a co se chystá. V elektronickém rozvrhu je vidět co děti probíraly (až do úrovně každé hodiny).
  • neformální a přátelská atmosféra ve škole - všichni si mezi sebou tykají - tedy i žáci průvodcům

Placená škola

Scio škola je placená škola. Platí se 5000 Kč měsíčně na žáka. Což vypadá jako hodně peněz a že ta škola na tom dost rejžuje. Ale pokud si zjistíte, kolik stát proplácí peněz státním a soukromých školám, tak zjistíte, že pouze doplácíte oč stát platí méně. Plus za to, že ve třídě je menší počet žáků (12 žáků).

Co dělat, když se nedostanete do školy?

Kamarádům se stala nepříjemná věc. Přihlásili dítě na blízkou školu (ale nikoliv na spádovou), ale dítě tam nevzali. Což se vám může lehce stát i u soukromé školy, kde školné platíte. Šli pak na svoji spádovou školu, ale tam se jim paní ředitelka vysmála. Něco ve stylu: "tak to máte smůlu a to máte za to, že jste námi zpočátku pohrdli." Hlavním argumentem bylo, že se nedostavili k nim do školy na zápis. Vaší poviností je dostavit se k zápisu. Kamkoliv. Pokud vás nevezmou, tak byste měli jít na váš obecní úřad/úřad městské části a tam vám musí zajistit školu a v případě nedostupnosti MHD také dopravu do té školy. Bohužel to klidně může znamenat i školu na druhé straně města.

Jiné zajímavé školy v Brně:

  • Labyrinth - úžasná škola; zatím jenom pár tříd; dost drahé školné (až 8000 Kč).
  • ZŠ Žebětín - rodinná škola; škola co se snaží; pouze první stupeň.

Posted by Miroslav Suchý | Permanent link
Comments

2017-05-16 15:51:35

DistGit 1.0

This is host post. Written by Michal "clime" Novotný.

Prolog

If you are just looking for an immediate hands-on experience, skip to "Okay, I want to try the DistGit package out. How?". Everything else is an interesting background.

Introduction

Almost everyone in the programming world knows Git. It's an alpha and omega of Source Content Management in the Linux environment and most of the programmers there cannot live without it. Everything is being tracked and code is being distributed all around the world to be built upon by more and more well-defined units of human work called Git commits.

As opposed to that, nobody knows DistGit. Well...almost nobody. There are a few humanoids in Delta quadrant called "packagers" that collect all the work of the primarily application-focused programmers and make neat packages out of them that serve as a basis of any Linux operating system. These people create an operating system so they should not be taken lightly even though their work is probably less creative than of the people creating these cool Vims, Gimps, and Sims.

For those few humanoids and their work, Git is actually not the most suitable tool. Well...it is...but not without a few tweaks. And Git with those tweaks included is nothing else than DistGit.

Why not Git?

We have said that Git is not the weapon of choice for packagers but why exactly? Well, the reason is that a packager does not actually care all that much about the actual application sources (even though he needs to know them well in the end). What he cares most about are meta-data about the package such as build or run-time dependencies on other packages or installation steps that make it possible for the package to be installed and actually used by the end user.

Therefore, in a package, sources are usually packed into a nice little (or huge) tarball with a file next to it called .spec file containing all those additional package information that are needed for a package to be a useful piece of the target Linux distribution. Note that here we are talking about so-called "source packages" and not about "binary packages" that are created from the source packages by a building process.

So why not Git on its own? It's just because the tarballs (containing the source files) are not suitable to be tracked for content changes. They are binary and any small change in the original source might cause huge (and binary) changes in the resulting tarball. Packagers are interested in the .spec files and other optional files called "downstream patches", which are all in human-readable text and, hence, their diffs against their older version are comprehensible and useful.

So what to do with that (big) dirty binary blob that cannot be put into our tiny, neat package Git repo...that's where DistGit comes in!

Why DistGit?

DistGit alias "Distributed Git" solves the problem by storing the source tarball outside of the Git repository in the so-called lookaside cache, while keeping a "link" in the Git repository next to the .spec and patches (if any). This "link" literally called "sources" is nothing else than another text file with an information about location of the tarball. This location is represented in a very specific way as you can see in the following example "sources" file:

$ cd somerepo
$ cat sources
SHA512 (prunerepo-1.10.tar.gz) = e8335bada83cc8c77050ece3b0f23871941c39a4bc8d2d7b320fac3cda32fda22d64292bcd51b0e994fcc0ae0c7ddc2ed1e249b91fe995b71e6e78699e26e66b

The format might seem a bit cryptic but the hash is really nothing more than a part of an otherwise known file-system path and the "lookaside cache" is then nothing more than a directory at a predetermined path in that filesystem.

There is not much else to be seen around here and really, in its gist, DistGit is just Git with few additional helper scripts for setting up new (Dist)Git repos and maintaining tarballs in the lookaside cache.

Why so much fuss around it then?

DistGit was not always this simple. The previous version 0.13 available in Fedora distribution contained a lot more including an ssh-based ACL system called Gitolite and also an integration with a Fedora Package database. It was quite tightly bound to a specific use-case deployed in Fedora while also being outdated with respect to the wildly volatile scripts it was originally packaged from.

DistGit 1.0, now released for Fedora and EPEL7, attempts to take much smaller bite by employing only the most fundamental parts that makes DistGit what it is while trimming off all the rest. Both Gitolite and integration with a package db can be added back easily if needed and that's because DistGit 1.0 is a really very simple package consisting of just a few scripts and configuration files. What matters the most are the data being maintained (Git repos + tarballs) and here you are completely free to:

  • use a fancier tool for Git authorization than just default ssh (e.g. gitolite)
  • init and maintain Git repos according to remote db records
  • use Kerberos for uploading tarballs into the lookaside cache
  • do anything else upon the data and the access to them

I am talking about these possibilities because they are essential for the DistGit package to be a preferred option for maintaining large package collections. Currently, it's being integrated into Fedora package collection system and we hope, the labor will be successful in the end (looks like it will).

Fedora basically uses DistGit already (at least scripts and the configs are all very similar to the ones in the actual DistGit package) but in a non-packaged and highly one-purposed manner. Extraction of the essential and general DistGit's parts into a standalone package can be useful because other distributions may then start using it as well.

Is DistGit 1.0 already used somewhere?

Yes, it is used on copr-dist-git machine in COPR build system stack.

Are there alternatives?

There are. One of them is Git-Annex that enables storage of the binaries in multiple locations as oppossed to DistGit where they are stored in a single place only. Another difference is in client-side tooling. With Git-Annex, a well-known git command line tool is used as a client to manage the local repositories (with git annex subcommand to handle the binaries) and there is really not a difference between a client and server. All nodes working with the data are essentially the same. In DistGit world, there is a difference between a client pulling/pushing by using git and uplading/downloading using rpkg (or a derived tool like fedpkg) and a server on which the initial repository setup and authorization takes place.

Then, there is also Git-LFS working in a similar spirit to Git-Annex.

The main advantage of the DistGit package that we develop is in its focus on package collections. The rpkg client tool provides lots of useful subcommands such as rpkg container-build, rpkg copr-build that enables packagers to immediately send the new package content to a build system to obtain a final installable binary package and there is more (see man rpkg for other useful commands like rpkg lint or rpkg compile).

Okay, I want to try the DistGit package out. How?

Normally, you would need a server machine and a client machine but for playing around, you can just use localhost for both.

First, install the dist-git package on the DistGit server (=localhost):

$ sudo dnf install dist-git

or on CentOS, RHEL with EPEL7 enabled:

$ sudo yum install dist-git

Then, you need to setup Apache on the server (=localhost) for uploading source tarballs. There is /etc/httpd/conf.d/dist-git/lookaside-upload.conf.example provided by the package for ssl uploading with client certificates for authentication but we will use something more simple for the demonstration. Put the following into /etc/httpd/conf.d/dist-git/lookaside-upload.conf:

<VirtualHost _default_:80>
    # This alias must come before the /repo/ one to avoid being overridden.
    ScriptAlias /repo/pkgs/upload.cgi /var/lib/dist-git/web/upload.cgi

    Alias /repo/ /srv/cache/lookaside/

    ServerName pkgs02.stg.phx2.fedoraproject.org
    ServerAdmin webmaster@fedoraproject.org

    LogLevel trace8

    # provide this manually for upload.cgi
    SetEnv SSL_CLIENT_S_DN_CN distgit_user

    <Location /repo/pkgs/upload.cgi>
        Options +ExecCGI
        Require all granted
    </Location>

</VirtualHost>

and reload the httpd server. Note that we fake ssl authentication purely for demonstration purposes here because the upload.cgi script (central core of DistGit) needs some authentication (SSL or Kerberos).

Then you also need to create the distgit_user and add it to packager group on the server.

$ sudo useradd distgit_user -G packager

Then on the client install the rpkg package and put the following configuration into /etc/rpkg/rpkg.conf:

[rpkg]
lookaside = http://localhost/repo/pkgs
lookasidehash = sha512
lookaside_cgi = http://localhost/repo/pkgs/upload.cgi
gitbaseurl = ssh://%(user)s@localhost/var/lib/dist-git/git/%(module)s
anongiturl = git://localhost/%(module)s
branchre = f\d$|f\d\d$|el\d$|olpc\d$|master$
kojiconfig = /etc/koji.conf
build_client = koji
clone_config = bz.default-component %(module)s

If the DistGit server is different from 'localhost', change it appropriately.

Finally, you need to create distgit_user on the client for the test purpose (note that you don't need to do this if you use localhost for both DistGit server and a client):

$ sudo useradd distgit_user

An example DistGit workflow might then look like this:

root@server $ /usr/share/dist-git/setup_git_package foo # creates Git repo on the server
root@server $ ls /var/lib/dist-git/git
foo.git

distgit_user@client $ rpkg clone foo # clones remote foo.git repo
distgit_user@client $ cd foo
distgit_user@client $ rpkg import foo.src.rpm # uploads src.rpm into dist-git and modifies local repo accordingly
distgit_user@client $ git commit -m "DistGit test update" -a # commit changes to the local Git repo
distgit_user@client $ git push # push changes to the Git repos on the DistGit server

You don't need to use root user for the repository creation at the server. Any user in the packager group is suitable.

Anything else?

The DistGit upstream is hosted at https://github.com/release-engineering/dist-git. Please, send us patches and requests there.


Posted by Miroslav Suchý | Permanent link
Comments

2016-10-31 16:15:31

How to replace deprecated platform.distro()

The Python method platform.distro() have been deprecated since Python 3.5. And it will be removed in Python 3.7. So it is about time to really replace it in your (and my) code.

Fortunately there is a new python module "distro". I packaged it for Fedora and EPEL so it should be available in main repository now. It is available as python2-distro and python3-distro.

The replacement is quite easy. Instead of:

import platform
platform.dist()

you just put there:

import distro
distro.linux_distribution(full_distribution_name=False)

and that's all.


Posted by Miroslav Suchý | Permanent link
Comments

2016-10-31 16:14:09

Dům na baterku

Před půl rokem jsme se rozhodli si pořídit soláry. A nyní už je to více než měsíc co nám plně fungují. Jelikož se mě hodně lidí na to ptá, tak to hodím i sem.

Tak předně si ujasněme termíny, protože není solár jako solár. Existují soláry na ohřev teplé vody (odborně kolektory). Těmi proudí kapalina a s elektřinou nemají nic společného. Ty sice máme taky (už čtyři roky) a jsou výhodnější než elektrika, ale o těch teď nechci psát. Pak jsou soláry, které vyrábějí elektriku - fotovoltalická elektrárna (FE). Ty pak mohou být dvojího druhu. Buď se vyrobená elektřina prodává distribučním firmám za regulovanou (rozuměj dotovanou) cenu - to jsou ty elektrárny na které se tak nadává. Nebo se vyrobená elektřina ukládá do baterek a z baterek se potom čerpá večer a v noci, když slunce nesvítí. Tomu se říká "Ostrovní systém" nebo "Hybridní fotovoltalická elektrárna (HFVE)". A přesně takovou máme. Tj. do sítě nic nedodáváme, takže nijak nebohatneme, ale neprojídáme žádné dotace. Přes den elektřinu ukládáme do velké baterky a v noci jede celý dům z baterky.

Nejčastější dotaz: kolik ta sranda stála? Stála 459 tisíc Kč. Ale tady platí víc než u jiného zboží, že se vyplatí zjistit: co kupujete, proč to kupujete a k čemu to bude. Měl jse i nabídku na HFVE za 271 tis. Kč. Ale když jsem to parametrově porovnával, tak jsem zjistil že tam je méně panelů, menší kapacity baterek, měniče. Takže ta levná nabídka je vlastně docela drahá.

Máme na střeše 18 panelů Solet 280Wp. Každý panel má 1,6 m2, takže dohromady pokrývají cca 29 m2. Panely samotné ale nejsou nejvýraznější položkou. A to ani cenovou ani co se týče problémů. Nám se panely vešly na střechu od garáže (kde už byly dva kolektory na ohřev teplé vody). A stále nám zbýva místo na střeše domu, kdybychom někdy chtěli zvýšit kapacitu. Větším oříškem je baterka.

Baterky mají tří základní parametry: cenu, velikost, kapacitu. Vybrat si můžete dva parametry. Ten třetí pak vždy hodně ustřelí. Já jsem nakonec zvolil variantu olověných akumulátorů. Mají příznivou cenu a kapacitu, ale jsou velké. Celá baterka váží tunu a měří 1219 x 352 x 782 mm (dělají se i více krychlovité, ale já potřeboval úzkou baterku). Naše baterka se skládá z 24 článků (ne nepodobné autobaterii), které jsou v jedné velké vaně a zapojené do série, takže dohromady vytváří napětí 48V a kapacitu 625 Ah. Kdybych chtěl Li-Fe baterky, tak ta stojí 1500 Euro a má kapacitu jenom 250 Ah. Obdobná cena a kapacita platí i pro slavnou Tesla Powerwall, ale o té se navíc jenom mluví a do dneška se reálně nedá koupit. Největší nevýhodou naší olověné baterky je, že se musí každý týden dolévat destilka (asi tak 0.5l týdně) do elektrolytu (pokud nechci aby klesla životnost). A že se z baterky při dobíjení odpařuje kyselina sírová a vodík. Ne moc, ale příjemné to není a místnost by měla být odvětrávaná. Pokud jste teď vystrašení (vodík přece vybuchuje!), tak vodík vybuchuje při koncentraci 4%. A v našem malém kumbálu (2x3 metry) by to znamenalo že bych ho musel hermeticky uzavřít na celý týden aby tam takové množství vodíku vzniklo. Což rozhodně nehrozí. Vývoj baterií se ovšem dere rychle ku předu a za rok budou parametry a ceny baterek zase jinde. Takže počítám s tím, že o tuto baterku budu pečovat a až ji skončí životnost (tak za 6 let), tak si pořídím nějakou jinou co nebude potřebovat takovou údržbu. O životnosti baterie a co na ni má vliv se můžete dočíst např. zde.

Když jsme elektrárnu zprovoznili, tak jsem si myslel, že přes den nebudeme spotřebovávat žádný proud z distribuční sítě. K mému překvapení tomu tak nebylo. Celý systém si neustále bere tak 10 % elektřiny ze sítě! Proč? Elektřina z panelů jde přes měnič který je převádí z DC na AC. My máme měnič XTM 4000-48. Ten zvládne dodávat 4kVA po dobu 30 minut. Nebo 3,5kVA trvale. Jakmile bych tedy zapnul počítač, myčku a vysavač - tak jsem přes kapacitu tohoto měniče. On si sice umí inteligentně dobrat elektřinu ze sítě, ale na to potřebuje být synchroní s distribuční sítí a proto neustále odebírá trochu proudu ze sítě. Pokud bych chtěl odebírát nulu z distribuční sítě, tak bych si nemohl užívat luxus neomezené elektřiny. A buď musel myslet na to, že nesmím zapnout příliš mnoho spořebičů nebo koupit další měnič.

Co mě naopak velmi příjemně překvapilo - že se celý systém chová jako velká UPSka. Pokud vypadne distribuční síť (což se u nás na venkově děje více než je mi milé), tak HFVE okamžitě přepne na baterky. A to tak rychle že se počítače doma neresetují.

Jak je to s třífázovým rozvodem? Naše HFVE je jednofázová. V domě jsou sice třífázové rozvody. Ale funguje na ně jenom trouba a sporák. A 3fázová zásuvka v garáži, která za 4 roky nebyla použita ani jednou. HFVE sice zásobuje všechny fázové rozvody, ale není mezi nimi fázový posun. Což třeba troubě nevadí. Ale vadilo by to třeba míchačce - a obecně rotačním motorům, které by to asi zavařilo. Takže pokud někdy budu chtít připojit míchačku, tak musím otočit jedním knoflíkem, který přepne dům na distribuční síť (a odstaví HFVE). Pokud by někdo potřeboval nutně tři fáze, tak to lze spravit dokoupením dvou dalších měničů. Ale v mém případě by to byli vyhozené peníze.

Jak dlouho vydrží jet dům na baterku? Naše baterka má 625 Ah. Při normálním provozu její kapacita přes noc klesne maximálně na 80 %. Přes den se stihne krásně dobit a ještě hodně proudu zbývá a pouštíme ho do zdi. Včera večer jsme měli zapnuto hodně spotřebičů (trouba, myčka, počítač, půl baráku svítilo a možná ještě něco) a displej ukazoval že spotřeba je 15 A a že tímto tempem by to vydrželo ještě 50 hodin. Takže v případě nouze bycho m na baterce vydrželi skoro měsíc. Ale v normálním provozu (např. v zimě) to nechcete huntovat až na nulu, protože to razantně snižuje životnost baterky.

Návratnost? Já momentálně platím cca 2 tisíce měsíčně za elektřinu (protože mám hodně počitačů, holt jsem IT exot). Takže za 20 let ušetřím cca 430 tisíc. Což je plus mínus cena celé sestavy. Samozřejmě je potřeba započíst obnovu ba terky. Ale řekněme, že se to nyní tak tak zaplatí. Takže taková záporná nula. Trochu nejistá. Ale počítám, že během pár let si pořídím čistý elektromobil, a pak by to mohlo být i zajímavější. Na elektrárnu naší velikosti se dá i sehnat jednorázová dotace 100 tisíc. Což momentálně zkouším (je to stále v procesu). Uvidím jak to dopadne.

Proč to dělám? Když pominu ty zřejmé důvody (nezávislost, ekologie) tak pro zkušenost. Před pár lety byl HFVE ekonomický nesmysl. Dneska to je na hraně. A za pár let to bude jasně ekonomicky výhodnější. Ale stále je tu dost lidí, kteří si myslí, že to nikdy nebude fungovat a že to je celý nesmysl (ahoj tati). A druhý zbytek lidí je zdravě skeptický, protože o tom nic neví (ještě před rokem i já). Takže chci nabrat zkušenosti a pak skeptikům vyvracet jejich názory. Ale už podložené daty a zkušenostmi z provozu. Například tím, že dnes už existuje technologie MPPT, která docela dost zvyšuje učínost.

A nakonec nějaké fotky.


Posted by Miroslav Suchý | Permanent link
Comments

2016-10-31 16:09:05

Flock 2016 Report

I spent previous week in Kraków at Flock. It is a conference of Fedora developers and users. I really liked it - hmm this is not enough - It was awesome!

For me the best part was those social events. Every single event there was prepared some social event and I met a lots of people I never met before and learn about interesting things they are doing. I was at FUDcon in Zürich, Flock in Prague, but Kraków done really best job so far. And the town is sooo beautiful. I have to admit that I had a lot of prejudice about Poland and Polish cities, but I was really overhelmed. And I do plan to return there with my family for some holidays.

City bus full of Flock

Probably the best talk for me was by Radosław Krowiak about Akademia Programowania. It is a company in Poland and they are trying to learn programming 5+ years old kids. Exactly the same what I am doing in Czech! The presentation itself was nothing new to me, but the follow up discussion in lobby was very informative. For example I was surprised that they are successful with programming in pairs.

The most surprising talk for me was "I contributed! but, what now?" by Bee Padalkar. She done some data mining and shown us that we are loosing a lots of people as contributors. That means they join, do some contributions, but within 3 months they are gone. Most of them. We - the senior contributors - should definitely do better to mentor the newcomers. I took this talk very personally and I will try to focus on this area in near future.

"Fedora's MirrorManager - now and the future" by Adrian Reber. I learn some background of MirrorManager. I was taken by surprise that in background there is lots of crawler which pro-actively monitor health of the mirrors.

Definitely the most important talk was "Modularity: Why, where we are, and how to get involved", because that may be the future of Fedora. Langdon was able to do (live) demo of modules installation. The idea is that you will have some core modules (think about it as stripped down Cloud/Server/Workstation spin) and you will install modules. Modules are group of packages which works together. Something like comps, but each of them has own repository and there is some more logic behind. This will allow you to have e.g. newest Fedora and some old stable httpd. Or vice versa - old Fedora (or maybe RHEL in future) and newest PHP.

On Thursday I attended "Fedora Badges Workshop". I expected that I will just watch others as I have no talent for drawing and painting. But ... at the end I draw a brand new badge!

I voted badge

And yes - I had two talk. One was together with Clime about state of Copr (slides and the other was about Fedora Sponsors (slides. We had very nice discussion there and there was great ideas how to improve the process. You can follow up it on devel mailing list.

Was there some drawback? Unfortunaly yes. I participated in one morning run, which Vít arranged and I ran bare foot and ripped off one nail.


Posted by Miroslav Suchý | Permanent link
Comments

2016-04-21 12:31:39

WIP: rebuilding all PyPi modules as RPM packages

For some time, Copr can build RPM package directly from PyPi (see previous blogpost), which means that you can build some modules on your own very easily. But are we able to build all modules in PyPi? "All" is equal to number 79 000 right now. Will Copr be able to cope with that? These days, the largest Copr repositories had have hundreds of packages. One experimental repository had 2000 packages. But 79 000?! No one tried that so far. What problems can we experience? Lets try it!

I have created quick'n'dirty script, which gets names of all modules from PyPi and submit them to Copr. Only submitting the builds into Copr takes almost whole day (21 hours). And importing into dist-git would take about 4 days (average time to import one module is 4 seconds). Our dist-git import is single threaded (because it is so fast and no one ever will be able to submit task so fast - haha). So if I would do that on production server, no one will be able to submit package into Copr for 4 days(!), because they would be blocked by importing queue. So I've throttled it by sleep(4) and the importing queue is short now.

Importing was quite fast - 4 seconds per module and 4 days in total. What about actual builds? Each package takes approximately 1-2 minutes to builds. That means 55-110 days in total. Each user can run max. 4 tasks in parallel, which means that it would take about 14-28 days to build all packages. Just for one chroot. On the development server, where there are no other users but me and my colleagues, I temporary raised the limit to 12 tasks in parallel per one user (so I'm blocking my collegues now). And the batch should be finished in 5-10 days.

But there is one problem. We want to build python2 and python3 subpackage. But some packages fails to build with python2 and some fails to build with python3. Such packages need to be build with only one subpackage. But which one? There is only one reliable method - trial and error. So we are going to create Copr project PyPi-2, where we will build all the packages only for python2 only. And another project PyPi-3, where we will build all packages only for python3. Then, we'll gather the statistics and try to build all packages in a final PyPi repository. Packages which succeed in both PyPi-2 and PyPi-3 projects will be build with both submodules enabled. Packages which succeed with only one, will be build with only one subpackage enabled. So that means it will take 28-56 days just to gather those statistics.

Is Copr WebUI able to handle such big number of records in one project? Sort of. The tab "Builds" loads quite long. But it will finish in reasonable time. And the Javascript code is able to sort and search the results in real time (at least on my workstation). However the tabs "Packages" and "Monitor" times out. We are working right now on the performance improvements.

In the time I'm writing this, Copr have finished 38k builds. From which 33.4k failed and 4.7k succeeded. That gives us 12 % chance to successfully build package. This is not a big number. BTW, when we did this experiment with only those PyPi modules, which are already packaged in Fedora, the success ratio was more than 50 %. We use Pyp2rpm for conversion of python modules to RPM package. We started our experiment with version 1.x and we provided lots of feedback to Michal Cyprian (upstream of pyp2rpm). We moved to version 2 recently and soon we will move to version 3. So I hope that success to fail ratio will be much higher in future. And on our TODO list is parsing build requirements and building packages in correct order, which may improve the number a lot.

BTW: while we build these python modules, Copr will automatically creates package definitions and when there is new release in PyPi, then Copr will automatically build updated rpm package within a day!

To sum it up: in 2-3 months we may have a repository with at least ten thousand python package for python2 and/or python3.


Posted by Miroslav Suchý | Permanent link
Comments

2016-03-29 15:56:48

New features in Copr

Jakub just released new version of Copr. What's new there?

There is new feature "forking". More about it on Jakub's blog. We created it so you can have projects for nightly builds and at one point you can fork your project to "yourproject-stable" and all successfull builds will be copied there. When you find some issue there during release testing, you can rebuild your package just in that forked projects and any new builds in your nightly projects will not affect your stable projects.

Another big feature is build directly from PyPi. Just fill in name of the module and we will create RPM for you automatically. And if you create record on Release-Monitoring.org for that module, then we will automatically rebuild that package once there is new release!

You can submit from command line using:

copr-cli buildpypi --packagename PYPINAME --packageversion PACKAGEVERSION msuchy/myproject

or from webUI. Hopefully this screenshot is self-explanatory:

Building PyPi from Copr webUI

Internally we use Pyp2Rpm to create SRPM. Right now we still use 1.x version. But we will soon deploy pyp2rpm-3.0 version. Which contains big enhancement from Michael Mráka and Michal Cyprian. It contains better parser of setup.py so the success to fail will be much much higher. If your build from PyPi fails, then please report it to authors of Pyp2RPM.

There is pending pull-request for Anitya so it can emit messages even if you previously did not register the module. The PR is currently stuck, so any help is welcome.

And there is some bugfixes and internal changes, which you probably do not find so interesting as we do :).

What will be next?

We will try to rebuild whole PyPi repository! Once we are done, we plan to do the same with CPAN, Rubygems and others.


Posted by Miroslav Suchý | Permanent link
Comments

2016-02-06 13:31:29

Brief history of DevConf.cz

I am this weekend at DevConf.cz and I met here several friends who do not work in Red Hat. They are able to speak about some interesting technical topics, but are afraid to give their speech here, because "This is something else then Red Hat is doing.". This is false assumption. We are interested in all open source projects. No matter if Red Hat is using it or not. Let me tell you brief history of DevConf.cz and you will understand better.

Long time ago, Red Hat Czech was just 60 people. And few hundreds Red Hat world-wide. We knew each other personally. But as we grow every year we are way over Dunbar number. So we had an idea that during our team-building activity we present something interested to each other. Usually something we work on and what can be interested for others. So the first event happen at hotel loungue.

Next year we decided to invite our US colleagues and we moved to University (much better then hotel lounge). And since there is nothing secret we decided to open it to students and anybody interested in. Because sharing is better. First year (2009) only few of them came and most of attendees were from Red Hat and conference was mostly in Czech language. And then the conference grew and grew. Most of the topic were in English. And now all session are in English. Every year there was lots of interesting topics. And this year is huge! With lots of people outside of Red Hat. Which is great!

Red Hat still organize this event, because we will do something like this anyway. And the in the term of cost, it really does not matter too much if you have 500 attendees or 1200 attendees.

So for historical reasons most of the talks are from Red Hat employees. But this is open conference. And we will love to hear what new open source technology you develop or use in your company. So during October there should be call for papers for DevConf.cz 2017 and you should not hesitate to submit your topic. Even if you are not from Red Hat or it is about technology not used by Red Hat. We would really love to attend your presentation too.


Posted by Miroslav Suchý | Permanent link
Comments

2015-09-09 17:16:37

Performance of RAID1 with mix of HDD and SSD

I have several computers where I have discs in RAID1 configuration (aka mirroring). All of them are magnetics HDD. I am thinking about replacing them with SSD. However to replace all of them, would cost a lot of money.Hmm - what if I only replace one (of two) disc in that array. What will be the performance. Do I get the best from HDD and SSD? Or the worst? There is a lot of benchmarks of HDD alone, a lot of benchmarks of SSD alone. But the mix in RAID is unknow.

Recently I got one spare SSD and some HDD so I was able to do some benchmarks.

First reading tests (write benchmarking is in second part of this blogpost). I used iops test.

The throughput of my SSD is between 61.6 Mbit/s and 2.4 Gbit/s. Raw data:

# python iops-2011-02-11  /dev/sdb
/dev/sdb, 120.03 GB, 32 threads:
 512   B blocks: 15033.9 IO/s,   7.3 MiB/s ( 61.6 Mbit/s)
   1 KiB blocks: 14838.3 IO/s,  14.5 MiB/s (121.6 Mbit/s)
   2 KiB blocks: 13785.3 IO/s,  26.9 MiB/s (225.9 Mbit/s)
   4 KiB blocks: 11490.4 IO/s,  44.9 MiB/s (376.5 Mbit/s)
   8 KiB blocks: 11273.0 IO/s,  88.1 MiB/s (738.8 Mbit/s)
  16 KiB blocks: 7147.7 IO/s, 111.7 MiB/s (936.9 Mbit/s)
  32 KiB blocks: 4037.1 IO/s, 126.2 MiB/s (  1.1 Gbit/s)
  64 KiB blocks: 2177.5 IO/s, 136.1 MiB/s (  1.1 Gbit/s)
 128 KiB blocks: 1139.4 IO/s, 142.4 MiB/s (  1.2 Gbit/s)
 256 KiB blocks:  712.4 IO/s, 178.1 MiB/s (  1.5 Gbit/s)
 512 KiB blocks:  434.5 IO/s, 217.3 MiB/s (  1.8 Gbit/s)
   1 MiB blocks:  241.6 IO/s, 241.6 MiB/s (  2.0 Gbit/s)
   2 MiB blocks:  129.5 IO/s, 259.0 MiB/s (  2.2 Gbit/s)
   4 MiB blocks:   66.5 IO/s, 266.0 MiB/s (  2.2 Gbit/s)
   8 MiB blocks:   34.1 IO/s, 272.9 MiB/s (  2.3 Gbit/s)
  16 MiB blocks:   17.5 IO/s, 280.6 MiB/s (  2.4 Gbit/s)

The throughput of HDD is between 518.1 kbit/s and 850.9 Mbit/s. Raw data:

# python iops-2011-02-11 /dev/sda
/dev/sda,   1.00 TB, 32 threads:
 512   B blocks:  126.5 IO/s,  63.2 KiB/s (518.1 kbit/s)
   1 KiB blocks:  115.4 IO/s, 115.4 KiB/s (945.2 kbit/s)
   2 KiB blocks:  104.6 IO/s, 209.2 KiB/s (  1.7 Mbit/s)
   4 KiB blocks:  100.0 IO/s, 399.8 KiB/s (  3.3 Mbit/s)
   8 KiB blocks:   97.2 IO/s, 777.7 KiB/s (  6.4 Mbit/s)
  16 KiB blocks:   93.3 IO/s,   1.5 MiB/s ( 12.2 Mbit/s)
  32 KiB blocks:   85.9 IO/s,   2.7 MiB/s ( 22.5 Mbit/s)
  64 KiB blocks:   78.0 IO/s,   4.9 MiB/s ( 40.9 Mbit/s)
 128 KiB blocks:   64.0 IO/s,   8.0 MiB/s ( 67.1 Mbit/s)
 256 KiB blocks:   46.1 IO/s,  11.5 MiB/s ( 96.6 Mbit/s)
 512 KiB blocks:   35.7 IO/s,  17.9 MiB/s (149.8 Mbit/s)
   1 MiB blocks:   30.2 IO/s,  30.2 MiB/s (253.5 Mbit/s)

# python iops-2011-02-11 -n 8  /dev/sda
/dev/sda,   1.00 TB, 8 threads:
 512   B blocks:  112.7 IO/s,  56.3 KiB/s (461.4 kbit/s)
   1 KiB blocks:  108.8 IO/s, 108.8 KiB/s (891.1 kbit/s)
   2 KiB blocks:  101.6 IO/s, 203.2 KiB/s (  1.7 Mbit/s)
   4 KiB blocks:   97.8 IO/s, 391.1 KiB/s (  3.2 Mbit/s)
   8 KiB blocks:   96.1 IO/s, 768.8 KiB/s (  6.3 Mbit/s)
  16 KiB blocks:   90.0 IO/s,   1.4 MiB/s ( 11.8 Mbit/s)
  32 KiB blocks:   85.0 IO/s,   2.7 MiB/s ( 22.3 Mbit/s)
  64 KiB blocks:   81.2 IO/s,   5.1 MiB/s ( 42.6 Mbit/s)
 128 KiB blocks:   78.4 IO/s,   9.8 MiB/s ( 82.3 Mbit/s)
 256 KiB blocks:   52.1 IO/s,  13.0 MiB/s (109.2 Mbit/s)
 512 KiB blocks:   36.2 IO/s,  18.1 MiB/s (151.8 Mbit/s)
   1 MiB blocks:   36.4 IO/s,  36.4 MiB/s (305.3 Mbit/s)
   2 MiB blocks:   28.3 IO/s,  56.6 MiB/s (474.4 Mbit/s)
   4 MiB blocks:   18.5 IO/s,  74.0 MiB/s (621.2 Mbit/s)
   8 MiB blocks:   11.4 IO/s,  91.2 MiB/s (765.3 Mbit/s)
  16 MiB blocks:    6.3 IO/s, 101.4 MiB/s (850.9 Mbit/s)

In the second run I lowered number of concurent process, which let the test run with bigger blocks. Those big blocks are close to sequential reading and you can see that HDD is quite close to SSD here. Or at least the gap is not as big as with smaller blocks where the difference is by order of magnitude.

Now I created 40GB partitions on both disc and created software raid1 using both disc (using mdadm). The throughput is between 57.8 Mbit/s and 2.5 Gbit/s. This is very very close to pure SSD performance. Mind that I do not care about absolute numbers, but about the relative change. Relative to pure SSD and HDD performance. Raw data:

# python iops-2011-02-11  /dev/md0
/dev/md0,  42.92 GB, 32 threads:
 512   B blocks: 14104.5 IO/s,   6.9 MiB/s ( 57.8 Mbit/s)
   1 KiB blocks: 13733.6 IO/s,  13.4 MiB/s (112.5 Mbit/s)
   2 KiB blocks: 13097.5 IO/s,  25.6 MiB/s (214.6 Mbit/s)
   4 KiB blocks: 11847.7 IO/s,  46.3 MiB/s (388.2 Mbit/s)
   8 KiB blocks: 11534.3 IO/s,  90.1 MiB/s (755.9 Mbit/s)
  16 KiB blocks: 7303.0 IO/s, 114.1 MiB/s (957.2 Mbit/s)
  32 KiB blocks: 4129.3 IO/s, 129.0 MiB/s (  1.1 Gbit/s)
  64 KiB blocks: 2250.5 IO/s, 140.7 MiB/s (  1.2 Gbit/s)
 128 KiB blocks: 1198.1 IO/s, 149.8 MiB/s (  1.3 Gbit/s)
 256 KiB blocks:  759.2 IO/s, 189.8 MiB/s (  1.6 Gbit/s)
 512 KiB blocks:  457.2 IO/s, 228.6 MiB/s (  1.9 Gbit/s)
   1 MiB blocks:  255.7 IO/s, 255.7 MiB/s (  2.1 Gbit/s)
   2 MiB blocks:  136.3 IO/s, 272.6 MiB/s (  2.3 Gbit/s)
   4 MiB blocks:   71.3 IO/s, 285.3 MiB/s (  2.4 Gbit/s)
   8 MiB blocks:   36.4 IO/s, 291.5 MiB/s (  2.4 Gbit/s)
  16 MiB blocks:   18.9 IO/s, 303.0 MiB/s (  2.5 Gbit/s)

Just for the record I bechmarked how change the performance of the MD raid1 on the two HDD.

#  python iops-2011-02-11 /dev/sdb3
/dev/sdb3,   2.00 TB, 32 threads:
 512   B blocks:   38.3 IO/s,  19.1 KiB/s (156.8 kbit/s)
   1 KiB blocks:   37.2 IO/s,  37.2 KiB/s (304.6 kbit/s)
   2 KiB blocks:   48.9 IO/s,  97.7 KiB/s (800.7 kbit/s)
   4 KiB blocks:   44.9 IO/s, 179.6 KiB/s (  1.5 Mbit/s)
   8 KiB blocks:   37.4 IO/s, 299.1 KiB/s (  2.5 Mbit/s)
  16 KiB blocks:   38.2 IO/s, 611.5 KiB/s (  5.0 Mbit/s)
  32 KiB blocks:   32.0 IO/s,   1.0 MiB/s (  8.4 Mbit/s)
  64 KiB blocks:   23.4 IO/s,   1.5 MiB/s ( 12.3 Mbit/s)
# python iops-2011-02-11 /dev/sda3
/dev/sda3,   2.00 TB, 32 threads:
 512   B blocks:   41.8 IO/s,  20.9 KiB/s (171.1 kbit/s)
   1 KiB blocks:   41.6 IO/s,  41.6 KiB/s (340.5 kbit/s)
   2 KiB blocks:   42.1 IO/s,  84.3 KiB/s (690.4 kbit/s)
   4 KiB blocks:   42.3 IO/s, 169.3 KiB/s (  1.4 Mbit/s)
   8 KiB blocks:   34.5 IO/s, 276.3 KiB/s (  2.3 Mbit/s)
  16 KiB blocks:   43.1 IO/s, 689.8 KiB/s (  5.7 Mbit/s)
  32 KiB blocks:   36.0 IO/s,   1.1 MiB/s (  9.4 Mbit/s)
  64 KiB blocks:   34.6 IO/s,   2.2 MiB/s ( 18.1 Mbit/s)
# python iops-2011-02-11 /dev/md2
/dev/md2,   2.00 TB, 32 threads:
 512   B blocks:   63.6 IO/s,  31.8 KiB/s (260.6 kbit/s)
   1 KiB blocks:   48.1 IO/s,  48.1 KiB/s (394.0 kbit/s)
   2 KiB blocks:   57.8 IO/s, 115.6 KiB/s (947.2 kbit/s)
   4 KiB blocks:   37.7 IO/s, 150.6 KiB/s (  1.2 Mbit/s)
   8 KiB blocks:   54.4 IO/s, 435.1 KiB/s (  3.6 Mbit/s)
  16 KiB blocks:   48.1 IO/s, 768.8 KiB/s (  6.3 Mbit/s)
  32 KiB blocks:   40.6 IO/s,   1.3 MiB/s ( 10.6 Mbit/s)
  64 KiB blocks:   44.5 IO/s,   2.8 MiB/s ( 23.3 Mbit/s)

Conclusion of reading test

MD RAID1 of two HDD gives you nearly twice as big perfomance of each individual disc. When you combine SSD and HDD, then the resulting raid will have the same performance as single SSD. The additional HDD will give you redundancy, and will not help you in performance, but on the other hand it will not be bottleneck neither.

Write test

For write tests I used FIO.

Here are raw data:

HDD
]# ./fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=/mnt/new/test.block --bs=4k --iodepth=64 --size=4G --readwrite=randwrite
test: (g=0): rw=randwrite, bs=4K-4K/4K-4K, ioengine=libaio, iodepth=64
fio-2.0.9
Starting 1 process
test: Laying out IO file(s) (1 file(s) / 4096MB)
Jobs: 1 (f=1): [w] [100.0% done] [0K/923K /s] [0 /230  iops] [eta 00m:02s]
test: (groupid=0, jobs=1): err= 0: pid=21855: Thu Aug 27 06:55:32 2015
  write: io=4096.0MB, bw=306738 B/s, iops=74 , runt=14002034msec
  cpu          : usr=0.10%, sys=0.66%, ctx=873849, majf=0, minf=4
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0%
     issued    : total=r=0/w=1048576/d=0, short=r=0/w=0/d=0

Run status group 0 (all jobs):
  WRITE: io=4096.0MB, aggrb=299KB/s, minb=299KB/s, maxb=299KB/s, mint=14002034msec, maxt=14002034msec

Disk stats (read/write):
  sda: ios=1459/1425151, merge=1013/1295320, ticks=13140546/1152434770, in_queue=1166246234, util=100.00%


SSD
# ./fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=/tmp/a/test.block --bs=4k --iodepth=64 --size=4G --readwrite=randwrite
test: (g=0): rw=randwrite, bs=4K-4K/4K-4K, ioengine=libaio, iodepth=64
fio-2.0.9
Starting 1 process
test: Laying out IO file(s) (1 file(s) / 4096MB)
Jobs: 1 (f=1): [w] [100.0% done] [0K/71460K /s] [0 /17.9K iops] [eta 00m:00s]
test: (groupid=0, jobs=1): err= 0: pid=25103: Thu Aug 27 09:41:47 2015
  write: io=4096.0MB, bw=68711KB/s, iops=17177 , runt= 61043msec
  cpu          : usr=8.94%, sys=88.57%, ctx=5348, majf=0, minf=4
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0%
     issued    : total=r=0/w=1048576/d=0, short=r=0/w=0/d=0

Run status group 0 (all jobs):
  WRITE: io=4096.0MB, aggrb=68710KB/s, minb=68710KB/s, maxb=68710KB/s, mint=61043msec, maxt=61043msec

Disk stats (read/write):
  sdb: ios=0/1047843, merge=0/35459, ticks=0/135364, in_queue=133722, util=97.71%

So for HDD I got iops=74 and for SSD iops=17177. Which is again huge difference. Now I run the test suite on MD RAID1, which I created in fist part of this blogpost. Raw data:

# ./fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=/tmp/b/test.block --bs=4k --iodepth=64 --size=4G --readwrite=randwrite
test: (g=0): rw=randwrite, bs=4K-4K/4K-4K, ioengine=libaio, iodepth=64
fio-2.0.9
Starting 1 process
Jobs: 1 (f=1): [w] [99.9% done] [0K/12859K /s] [0 /3214  iops] [eta 00m:06s]
test: (groupid=0, jobs=1): err= 0: pid=25535: Thu Aug 27 11:20:56 2015
  write: io=4096.0MB, bw=858435 B/s, iops=209 , runt=5003250msec
  cpu          : usr=0.12%, sys=1.42%, ctx=158288, majf=0, minf=4
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0%
     issued    : total=r=0/w=1048576/d=0, short=r=0/w=0/d=0

Run status group 0 (all jobs):
  WRITE: io=4096.0MB, aggrb=838KB/s, minb=838KB/s, maxb=838KB/s, mint=5003250msec, maxt=5003250msec

Disk stats (read/write):
    md0: ios=14/1158475, merge=0/0, ticks=0/0, in_queue=0, util=0.00%, aggrios=7/1105716, aggrmerge=0/54041, aggrticks=10/210009015, aggrin_queue=210007845, aggrutil=99.28%
  sdb: ios=3/1061184, merge=0/98573, ticks=1/225035, in_queue=222790, util=1.47%
  loop0: ios=11/1150248, merge=0/9509, ticks=19/419792995, in_queue=419792900, util=99.28%

The result for RAID1 is iops=209. This is close to HDD performance (74 iops) .

Conclusion for writing

Performance in writing sucks. Still 3 times better then just HDD alone, but still order of magnitude slower than SSD alone.

Conclusion

The result is definitelly not black and white. If I replace one HDD in RAID1 with SSD, then I will get between 3 and 100 times better performance in reading. If I replace the second HDD with SDD then I will get additional 2 times increase of performance. So here replacing one disk is huge benefit. I will keep rendunance and the boost of performance is huge. For the writes the boost is "only" three times bigger. So it really matter what your usage is. If you write a lot then it can make sense to replace both disk with SSD disks. This is not my case, I usually just read a lot and write only few data. Therefore I will replace one of my disks in array with SSD now. And the second sometime later.


Posted by Miroslav Suchý | Permanent link
Comments

2015-06-26 22:32:35

Stavba domu s odstupem

Přišel mi tento dotaz:

Dobrý den pane Suchý,
dostal jsem se na internetu k vašemu blogu a článku Stavíme s Haas Fertigbau. musím říct, že to bylo velice poučné a inspirativní čtení, jelikož právě taky zvažujeme dřevostavbu a možno právě od Haase. chtěl bych vás tímto poprosit jestli by jste mi aspoň stručně nenapsal, jak jste s odstupem času spokojeni, jak s kvalitou provedení od Haase, tak s dřevostavbou obecně, mám na mysli zejména ty klasiky, jako hlučnost, slabá tepelná akumulace atd. , případně kdyby jste stavěl znovu, co by jste udělal jinak.

Není první - a nebude asi poslední. Tak ho zkusím shrnout tady na blogu. Jen pro úplnost shrnu, že je to více než 4 roky co jsme se nastěhovali.

Jak jsme spokojeni s dřevostabou? Já jsem spokojen moc. Vlaďka by sice raději měla nějaký slaměný dům s hliněnou omítkou. Ale to je na mě už moc. Já bych šel do dřevostavby znovu.

Hlučnost - tohle mi přijde jako mýtus. Rozhodně pokud jsou podlahy z betonu. Ano pokud děti nahoře v patře skočí z patrové postele dolů, tak to v kuchyni, která je hned po nimi, slyším. Pokud jsou otevřené dveře, tak v ložnici slyším co se děje v obyváku - ale to protože jsou hned naproti sobě. Jakmile dveře zavřu nebo je tam nějaká příčka, tak nic neslyším. Teda pokud děti zrovna nezkouší překonat svůj rekord, který drží na -110 dB.

Tepelná akumulace - ano, dřevostaba nemá tepelnou akumulaci. Klasický argument je "jak přestaneš topit, tak to rychle vychladne". To si lidé pletou akumulaci s izolací. Dřevostavba má nízkou akumulaci a vysokou izolaci. Takže pokud přestanu topit, tak dům tu teplotu v pohodě udrží ještě dva dny. Ano když otevřu venkovní dveře dokořán na půl hodiny tak teplo uteče, ale to v cihlovém domě taky. Ale naopak, pokud se vrátíme z dovolené a v domě je vypnuté topení (resp. jenom temperuje na 15°), tak po zapnutí topení je dům vytopen do pár hodin. Pokud si pomůžu i kamnama tak do 20 minut. U cihlového domu toho nikdy nedocílíte právě kvuli jeho akumulaci. Protože akumuleje nejenom teplo ale i chlad. Ale i v našem domě máme prvek, který akumuluje - podlahu. Ta je z betonu. Což je dobré kvuli te hlučnosti, ale na pytel kvuli té akumulaci. Pokud se v zimě vrátíme z dovolené tak v celém domě je velmi brzo teplo. Až na tu podlahu. Ta ještě dlouho zůstává studená.

Rekuperace - To je asi nejlepší věc, pro kterou jsem se rozhodli. Ten drobný průvan není vůbec cítit. Zato čerstvý vzduch ano. V zimě si připadám jako ve vyhřátém letním kině - na vzduchu a přitom v teple. Příjemný vedlejší efekt je že pokud se něco rozlije na zem, tak ty zbytky vody po utření uschnou výrazně rychleji než v jiných domech. Zemní registr mi vůbec nechybí. Resp. tak 4 dny v roce ano. Ale za ty prachy si raději v tropických dnech pustím větrák. Rekuperace obvykle jede na 50m3 za hodinu a to žere cca 30W. Co mě na rekuperaci štve je ten ovládací panel. Každý den v týdnu se musí nastavovat zvlášt a nastevní je poměrně zdlouhavé (furt kroutit tlačítkem doleva a doprava). No a když vypadne elektřina, tak to můžete nastavovat znovu. Což se u nás na vesnici děje tak jednou za čtvrtletí. Opruz.

Kvalita provedení Haasu - až na ten renonc s vodou (který Haas bez keců opravil) nebyl se stavbou dosud žádný problém. Všechno drží. Rohy jsou pravé. Nic se nemuselo předělávat. Mám akorát tři výhrady. 1) živí mě počítače, takže jsem chtěl skoro do každé místnosti natáhnout minimálně jeden ethernetový kabel a chtěl jsem Cat6. Kabely jsou sice Cat6, ale sockety tam daly Cat5e. Navíc dvě koncovky jsou špatně nacvaknuté - u jedné je to nepužitý vodič a u druhé - v pracovně - mám více socketů - takže jsem to zatím neřešil (a přišel jsem na to samozřejmě po záruce). Navíc kabely jsem chtěl vyvést na půdě (mám tam malý rack se switchem). Kabely tam jsou sice vyvedené, ale i když jsem rack postavil přesně doprostřed mezi vývody tak dva kabely tam nedosáhnou a budu je muset jednou nastavit (zatím je nevyužívám). 2) Na záchodě a v koupelně na některých místech trochu poklesla podlaha (necelý 1 mm), takže bude potřeba předělat spáru mezi kachličkami. 3) Po naší akci s dřevěnými schody, kterou jsem zmiňoval v přechozím zápisu, museli Haasovci říznout beton v patře a po uložení schodů dobetonovali navazující kousek (pás asi 30 cm). Občas když na něj došlápnu a nestojím jinde tak jde cítit, že se trochu hne. Je prostě poznat že ta podlaha není z jednoho kusu betonu. Ale pochybuji že někdo jiný než já si toho všimnul.

Co bychom udělali jinak

  • Telefonicu a kabelovku bych řešil dříve. Už u základů. Aby se kabely protáhli dříve než se postaví barák. Některé věci by to zjednodušilo.
  • A zvonek bych nechal dělat Haasovce. Zbytečně jsem musel dodatečně odkrývat kus stěny v předsíni (20*10 cm). A doteď jsem se nedokopal to zakrýt (netřeba mi to každýho půl roku připomínat).
  • Tu datovou kabeláž jsem si měl důkladněji převzít - ale fakt toho bylo hodně.
  • Elektrických zásuvek opravdu mohlo být více.
  • Ovládání světel bych dneska řešil elektronicky. Tj. vypínaš přímo neovládá světlo, ale je vyveden na datovou sběrnici a programovatelný čip pak určí co se zapne/vypne. Takže třeba světlo v předsíni může zhasínat celý dům. Schodišťák se může udělat čtyřcestný. A kdykoliv se to může předělat - softwarově. Ano měl bych u nás jednoho kandidáta, kterého bych u nás předělal. Ale to by se muselo lízt do omítky a předělávat dráty, takže nic.
  • Krbová kamna bych napojil na topný okruh. Kamna jsem měl primárně jako záložní zdroj tepla, když by nejela elektřina několik dní (což se tuhle zimu opravdu stalo) a bylo mi řečeno že pokud by byly napojeny na topný okruh, tak při nefungující elektříně bych v nich nemohl vůbec topit. Tak jsem od tepelného výměníku ustoupil. Později mi jiný člověk říkal že to jde. Že se prostě akorát ten topný okruh uzavře. No nic. Teď už kvuli tomu betony v podlaze rozbíjet nebudu.
  • No a samozřejmě bidetovou spršku bych napojil na teplou vodu. Ha ha.
  • Se založením zahrady jsme měli taky začít dřív. Stromy jsme měli zasadit hned jak se dělala základovka.
  • Udělal bych přípravu na solární panely. Když jsme stavěli tak se pro domácnost tak moc nevyplatili. To se teď mění. A počítám že do pár let je na střechu dáme hned vedle tech kolektorů.
  • Udělal bych vývod teplé vody ven. Na omýtku. To mě Haas nabízel, že vetšina domů si nechá vyvést studenou vodu na kohout ven. Řikal jsem "Na co, když na zahradě mám studnu a tam je kohout - Pravda." A opravdu studenou vodu bych nevyužil. Ale využil bych teplou. V létě nám vodu zdarma ohřejí kolektory a máme 250 litrů velmi horké vody. Ovšem pokud chci dětem napustit nafukovací bazének teplou vodou, tak ji musím nosit v kýblech. Nebo ji nechat ohřát sluníčkem, což v tom bazénku trvá více jak den a to už abych tu vodu měnil. Venkovní kohout na teplou vodu by se hodil.
  • Keramické tašky - já jsem zvolil betonové tašky. Jsou super. Za celou tu dobu praskla jenom jedna a jinak nic. Ale betonem moc neprojde wifi signál. Vlastně jakýkoliv signál. A jelikož mám AP na půdě, tak wifi signál je jenom pod ním (tj. v baráku) a na zahradě už ne, protože neprojde přes tašky. Řeším to repeaterem v jednom pokoji, ale je to zbytečný bazmek navíc. Keramikou prostoupí signál lépe.

Co jsem rád že jsme udělali

  • Pochozí půda - je tam hafo odkládacího prostoru. Pokud nemáte sklep, tak byste měli určitě chtít pochozí půdu.
  • Kumbál za garáží na zahradní věci a na kola.
  • Rekuperace - už se opakuji, ale je to fakt super.
  • Kachlová kamna - v zimě je to lepší než televize. Navíc ty kachle hezky akumulují, takže když večer v zimě zatopím, tak ráno ještě krásně hřejí.
  • Stupáky u komína - jak jsem zjistil tak to vůbec není obvyklé. A dodá to člověku mnohem větší jistotu.
  • Solární ohřev vody - v březnu se vypne kotel a v listopadu zase naskočí. To je 7 měsíců kdy kotel vůbec nesepne a teplá voda je téměř zadarmo. V zimě to navíc velmi slušně předehřívá vodu.
  • Studna - stojí sice dost, ale při kropení zahrady ušetří cca 10 tis. ročně.

Posted by Miroslav Suchý | Permanent link
Comments