Na crowdsourcingové platformě Crowd Supply byla spuštěna kampaň na podporu open source biometrického monitoru ve tvaru hodinek HealthyPi Move. Cena je 249 dolarů a plánovaný termín dodání listopad letošního roku.
Firma Murena představila /e/OS verze 2.0. Jde o alternativní sestavení Androidu bez aplikací Google. Mezi novinkami je podrobnější nastavení ochrany soukromí před sledováním aplikacemi. Murena prodává několik smartphonů s předinstalovaným /e/OS (Fairphone, repasovaný Google Pixel 5).
Do 30. května lze v rámci akce Warhammer Skulls 2024 získat na Steamu zdarma hru Warhammer 40,000: Gladius - Relics of War.
HelenOS (Wikipedie), tj. svobodný operační systém českého původu založený na architektuře mikrojádra, byl vydán ve verzi 0.14.1. Přehled novinek v poznámkách k vydání. Vypíchnou lze nabídku Start. Videopředstavení na YouTube.
BreadboardOS je firmware pro Raspberry Pi Pico (RP2040) umožňující s tímto MCU komunikovat pomocí řádkového rozhraní (CLI). Využívá FreeRTOS a Microshell.
Vývojáři KDE oznámili vydání balíku aplikací KDE Gear 24.05. Přehled novinek i s náhledy a videi v oficiálním oznámení. Do balíku se dostalo 5 nových aplikací: Audex, Accessibility Inspector, Francis, Kalm a Skladnik.
Byla vydána (𝕏) nová verze 18.0.0 open source webového aplikačního frameworku Angular (Wikipedie). Přehled novinek v příspěvku na blogu.
V neděli 26. května lze navštívit Maker Faire Rychnov nad Kněžnou, festival plný workshopů, interaktivních činností a především nadšených a zvídavých lidí.
Byla vydána nová stabilní verze 3.20.0, tj. první z nové řady 3.20, minimalistické linuxové distribuce zaměřené na bezpečnost Alpine Linux (Wikipedie) postavené na standardní knihovně jazyka C musl libc a BusyBoxu. Z novinek lze vypíchnou počáteční podporu 64bitové architektury RISC-V.
Práce se sítí byla testována nástrojem netperf (verze 2.4.4-5 z repozitáře Debianu). Provedeny byly testy počtu transakcí, které je možné uskutečnit mezi dvěma stroji (test TCP_CRR, výsledkem je počet transakcí za sekundu), a test propustnosti mezi těmito hosty (test TCP_STREAM, výsledek je udán v milionech bitů za sekundu). Všechny testy byly pětkrát opakovány.
ssh 192.168.150.1$a "sleep 1 ; netperf -t TCP_CRR -H 192.168.150.1$((a+1))" &
Test začíná vteřinovým čekáním, aby se hostitel stihl připojit na testované hosty bez čekání a tedy aby se všechny testy spustily pokud možno naráz. Za a je ve for cyklu dosazováno podle počtu testovaných strojů.
Test proběhl na šesti 1/1 hostech, testovalo se v párech, tzn. první host se připojoval na druhý, třetí host na čtvrtý atd.
TCP_CRR | KVM 1/1 | Xen 1/1 |
---|---|---|
minimum | 662,1 | 391,7 |
průměr | 680,6 | 2703,3 |
maximum | 693,5 | 3943,9 |
TCP_STREAM | KVM 1/1 | Xen 1/1 |
---|---|---|
minimum | 834,46 | 1,9 |
průměr | 979,55 | 2082,0 |
maximum | 1060,14 | 5362,8 |
V tomto případě byl testován jeden pár hostů 1/1 proti 8 párům 1/4.
TCP_CRR | KVM 1/1 | Xen 1/1 | KVM 1/4 | Xen 1/4 |
---|---|---|---|---|
minimum | 693,6 | 50,1 | 577,6 | 68,9 |
průměr | 701,7 | 60,3 | 604,7 | 1078,8 |
maximum | 704,4 | 69,3 | 655,2 | 1600,5 |
TCP_STREAM | KVM 1/1 | Xen 1/1 | KVM 1/4 | Xen 1/4 |
---|---|---|---|---|
minimum | 958,0 | 1,27 | 183,9 | 17,91 |
průměr | 1030,0 | 16,89 | 200,2 | 794,86 |
maximum | 1085,2 | 47,52 | 231,1 | 1507,61 |
I přes čísla v tabulkách, kde Xen zdánlivě dosahuje lepších výsledků, se nedá říct, že by na tom v těchto testech byl lépe, a to z následujících důvodů:
Test TCP_STREAM na Xenu vytěžoval fyzickou síťovou kartu eth0 (projevovalo se výrazným nárůstem odezvy), přestože vůbec nebylo potřeba ji do bridge připojovat.
Výsledky Xenu jsou poměrně nevyrovnané a test se v několika případech na některém z hostů dokončil později než na ostatních (takové výsledky byly vyřazeny, protože když daný test již běží jako poslední sám, těžko hovořit o paralelním běhu).
Poměrně nepříjemný je také fakt, že teoreticky silnější varianta hosta dosahovala při testech různých variant podstatně horších výsledků než varianty slabší. U testu počtu transakcí byly výsledky silnější varianty cca patnáctkrát horší, u propustnosti dokonce téměř padesátkrát.
U obou testů TCP_STREAM během testování jeden z hostů zhavaroval – spadl a bylo nutné ho znovu nastartovat
Naproti tomu KVM podávalo bez problémů vcelku stabilní výkony – minimální ani maximální hodnoty se příliš neodchylují od průměru. Počet transakcí byl víceméně rovnocenný bez ohledu na výkonnostní variantu, poměr objemu přenesených dat byl 1:55.
Jako v předchozích případech je samozřejmě potřeba mít na paměti to, že taková zátěž je v reálném provozu vcelku nepravděpodobná.
5 Využívání sítě hosty nebylo v těchto testech nijak explicitně omezováno, poměr objemu přenesených dat blížící se hodnotě 1:4 je pravděpodobně důsledkem toho, že rychlejší datové přenosy hosté nestíhali kvůli omezení času CPU.
Nástroje: Tisk bez diskuse
Tiskni Sdílej:
Ano, to je velice nepříjemná věc v debianu (u mě squeeze) - musí se instalovat balík "qemu-kvm", protože balíček "kvm" je VELICE a značně zastaralý, způsobuje výkonnostní anomálie, padání guestů, ...
Prvne diky moc za clanek.
Kdyby na to nekdy byla chut, tak bych moc rad videl aspon zakladni porovnani behu widli na Xen a KVMku. Sam jsem si hral s Win 2k3 serverem a na obojim se chova proti Linuxu mnohem hur. Na Xenu widle doslova staly na miste kvuli desivejm odezvam. Na KVM to bylo lepsi, ale zase se dost desne chovaly disky.
Lidi, jakou mate zkusenost s virtualizaci widli? Zaslech jsem, ze velmi dobre chodi vmware server, ale zrovna nemam volnej HW na testovani.
Protože se KVM poměrně rychle vyvíjí, byla použita verze z Debianu Unstable – v té době nejnovější jádro 2.6.31 (balík linux-image-2.6.31-1-amd64) a kvm-85 (85+dfsg-4.1).Opravdu bylo použito poslední KVM? kvm-85 je poměrně starý balík. Aby nedošlo ke zmatení čtenářů... Sám používám na desktopu unstable a používám balík qemu-kvm, teď ve verzi 0.12.3+dfsg-4. V dokumentaci se lze dočíst v
/usr/share/doc/qemu-kvm/changelog.upstream-kvm.gz
, že tento balík je založen na kvm-88 [12 july 2009]. Sám jsem používal chvíli kvm-85 a měl problémy s virtualizovanými Windoze. Po čase jsem si všiml balíku qemu-kvm (s novějším KVM). V tom mě Windoze běžely o řád lépe (to už je tak 3/4 rok zpět). Tedy nevím kdy tyhle testy proběhly, ale o aktuálnosti user-space části KVM lze dost pochybovat?
No a co se týče XENu, tak ten je teď samozřejmě v kernelu 2.6.32 připravován pro Squeeze také zřejmě v novější podobě.
Nechtěl by si někdo dát práci a ty testy zopakovat?
Opravdu bylo použito poslední KVM?V té době... je to cca půl roku, spíš víc, nechá se to odvodit i podle "nejnovějšího jádra" 2.6.31. Holt docela dlouho trvalo to sepsat.
qemu-kvm (0.11.0+dfsg-1) unstable; urgency=low * Package qemu-kvm (stable series) instead of kvm (snapshots) * Simplify the packaging, remove support for external module source * Move old debian/changelog to debian/changlog.kvm -- Jan Lübbe <jluebbe@debian.org> Mon, 02 Nov 2009 11:49:28 +0100Zrejme ty testy probehly jiz v roce 2009...
Bohuzel spatne dopadl test site a spousteni.Teď jsem ještě zkusil netperf -t TCP_STREAM mezi KVM Linux hostem (virtio síť) a fyzickým strojem (ne hostitelem) a vyšlo cca 920×10^6 b/s na gigové síťovce. Stejný fyzický stroj proti hostiteli dá 940, takže tu síť bych opravdu tak špatně neviděl. netperf AFAIK používají k benchmarkování i vývojáři jádra, takže špatným nástrojem to IMO taky nebude...
Zalostne taky dopadlo rekurzivni spousteni skriptu. Linux Host mel 1:25 (v minutach), XEN guest mel 1:34, windows xp host s cygwinem sam mel 20:31.Zatímco v Linuxu, jako ostatně ve většině unixů, jsou procesory "lehké" (light-weight) a jejich spouštění přes
fork()+exec()
relativně nenáročné, ve Windows jsou procesy relativně "těžkotonážní", fork()
není nativně v dispozici (Cygwin ho musí emulovat) a mnohem víc se využívají lehká vlákna. Pokud se na
Windows provozuje program silně používající unixový styl (např. právě ono rekurzivní spouštění skriptů), je logické, že výsledek dopadne takto žalostně.
Pamatuju si, jak jsem kdysi musel při portování jednoho svého programu z Linuxu na Windows přepsat volání externích utilit na používání knihoven, protože to, co Linuxu běžel celkem slušně, bylo ve Windows nepoužitelně pomalé - rozdíl v rychlostech byl téměř o řád a většinu zátěže spotřebovalo spouštění oněch externích utlilit (užívaných jako "filtry" na načítání vstupních a ukládání výstupních obrázků).
Tisk bez diskuzetak dostanes cely clanek...
Asi tolik ke slavne virtualizaci