Armbian, tj. linuxová distribuce založená na Debianu a Ubuntu optimalizovaná pro jednodeskové počítače na platformě ARM a RISC-V, ke stažení ale také pro Intel a AMD, byl vydán ve verzi 26.2.1. Přehled novinek v Changelogu.
Volí se dvě místa v Radě openSUSE. Seznamte se se čtyřmi kandidáty. Členové projektu openSUSE mohou hlasovat od 1. do 8. března. Výsledky budou oznámeny 9. března.
Společnost OpenAI uzavřela dohodu s americkým ministerstvem obrany o poskytování technologií umělé inteligence (AI) pro utajované sítě americké armády. Firma to oznámila několik hodin poté, co prezident Donald Trump nařídil vládě, aby přestala využívat služby společnosti Anthropic.
Technologická společnost Anthropic v noci na dnešek oznámila, že se obrátí na soud kvůli rozhodnutí ministerstva obrany označit ji za bezpečnostní riziko dodavatelského řetězce poté, co nevyhověla jeho požadavkům týkajícím se používání umělé inteligence (AI). Prezident Donald Trump krátce před tím uvedl, že nařídil federálním úřadům postupně ukončit využívání jejích AI technologií. Spor mezi firmou vyvíjející chatbot Claude a
… více »Zemřel Rob Grant, spolutvůrce kultovního sci-fi seriálu Červený trpaslík.
Apple oznámil, že iPhone a iPad jako první a jediná zařízení pro koncové uživatele splňují požadavky členských států NATO na zabezpečení informací. Díky tomu je možné je používat pro práci s utajovanými informacemi až do stupně „NATO Restricted“, a to bez nutnosti instalovat speciální software nebo měnit nastavení. Žádné jiné běžně dostupné mobilní zařízení tak vysokou úroveň státní certifikace dosud nezískalo.
Americký provozovatel streamovací platformy Netflix odmítl zvýšit nabídku na převzetí filmových studií a streamovací divize konglomerátu Warner Bros. Discovery (WBD). Netflix to ve čtvrtek oznámil v tiskové zprávě. Jeho krok po několikaměsíčním boji o převzetí otevírá dveře k akvizici WBD mediální skupině Paramount Skydance, a to zhruba za 111 miliard dolarů (2,28 bilionu Kč).
Americká společnosti Apple přesune část výroby svého malého stolního počítače Mac mini z Asie do Spojených států. Výroba v závodě v Houstonu by měla začít ještě v letošním roce, uvedla firma na svém webu. Apple také plánuje rozšířit svůj závod v Houstonu o nové školicí centrum pro pokročilou výrobu. V Houstonu by měly vzniknout tisíce nových pracovních míst.
Vědci Biotechnologické společnosti Cortical Labs vytvořili biopočítač nazvaný CL1, který využívá živé lidské mozkové buňky vypěstované z kmenových buněk na čipu. Po úspěchu se hrou PONG se ho nyní snaží naučit hrát DOOM. Neurony přijímají signály podle toho, co se ve hře děje, a jejich reakce jsou převáděny na akce jako pohyb nebo střelba. V tuto chvíli systém hraje velmi špatně, ale dokáže reagovat, trochu se učit a v reálném čase se hrou
… více »Pro testování byl vydán 4. snapshot Ubuntu 26.04 LTS (Resolute Raccoon).
Řešení dotazu:
12.10.2013 10:24
Jendа | skóre: 78
| blog: Jenda
| JO70FB
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
htop uvádí pro jednotlivá jádra naprosto jiné údaje o záteži. A samozřejmě takové, které nejdou vysvětlit libovolným přečíslováním jader.
Měřáky se berou z /proc/stat.
Zátěž není spojitá veličina, natož spojitě diferencovatelná. V daném časovém okamžiku je u jednoho procesoru vždy buď 0% nebo 100%. Tedy celkové zatížení systému například se 4 procesory je v daném okamžiku vždy přesně 0%, 25%, 50%, 75% nebo 100%.
Protože diferenciálně krátký okamžik je celkem nezajímavý a o ničem příliš nevypovídá, všechny utility zobrazují průměrnou zátěž za delší dobu. Jednoduše řečeno, odhadne se doba, kterou procesory strávily prací a kterou strávily nicneděláním. Zátěž je pak doba strávená prací během určitého časového intervalu dělená délkou tohoto intervalu. To například znamená, že pokud čtyři procesory strávily během jedné vteřiny dohromady 150% času prací, celková zátěž systému bude 150% / 400%, tedy 37,5%. Například mohly 3 z nich pracovat každý 50% času, případně všechny čtyři 37,5% času nebo třeba jeden na 100%, dva další na 25% a ten poslední během dané vteřiny nepracoval.
Odhad času, který procesory tráví prací, se dá provádět dvěma způsoby.
Primitivní způsob, který s několika modifikacemi používá Linux, využívá pravidelný tik hodin ke kontrole stavu procesorů. Když nachytá procesor při nicnedělání, zaznamená to. Když najde na procesoru běžící vlákno, přidá celý hodinový interval do časového účetnictví daného vlákna. Poté, co byl pravidelný hodinový tik odstraněn, bylo samozřejmě nezbytné postarat se o správné počítání času i na procesorech, které si dlouhodobě žádný timer nenaplánují. Nicméně hodnoty v souboru /proc/stat stále předstírají, jako by každý procesor zpracovával 100 tiků za vteřinu a u každého tiku zaznamenával aktuální stav. Odhad celkové zátěže je na Linuxu (nepřesně řečeno) tím přesnější, čím víc je procesorů, tedy například na 32-procesorovém stroji přibude do první řádky /proc/stat celkově 3200 tiků každou vteřinu, zatímco na dvouprocesoru pouze 200 tiků.
Tento jednoduchý způsob má samozřejmě své chyby, protože vlákno ve skutečnosti může běžet po dobu mnohem kratší než doba mezi tiky hodin, ať už kvůli vypršení plánovacího kvanta, kvůli migraci na jiný procesor nebo kvůli uspání z velmi široké škály možných důvodů. Idea je ovšem taková, že i přes drobné nepřesnosti bude v průměru a z dlouhodobého hlediska účtování času korektní, tedy pravděpodobnost výrazných systematických odchylek je z pohledu statistiky velmi malá.
Přesnější, ale náročnější způsob účtování času má například Solaris (Illumos, OpenIndiana) a AIX. V těchto systémech se při každé změně stavu procesoru explicitně přečte vhodný nanosekundový čas (tj. časomíra s velkým rozlišením, kterou většina moderních platforem implementuje) a na základě tohoto času se pak přesně počítá, jak dlouho byl procesor v userspace, jak dlouho byl v systému, jak dlouho obsluhoval interrupty, jak dlouho provozoval virtuální stroje — každý interval mezi dvěma sousedními změnami stavu se dá zaúčtovat velmi přesně. V Solarisu se to jmenuje microstate accounting. Tohle ovšem s sebou nese vysokou daň v podobě doby potřebné pro přečtení přesného času. Jakkoliv se to může zdát překvapivé, čtení přesného času je drahé a odpovídá desítkám až stovkám aritmetických instrukcí. (Důvodem je, že se zpravidla jedná o čítač tiků procesoru, který musí fungovat jako pipeline, protože inkrementace čítače se obecně nedá realizovat v jednom tiku. Čtení čítače vyžaduje čekání na dosažení definovaného a čitelného stavu a navíc různá opatření, která kompenzují vliv čtení na rychlost postupu čítače.) Jestliže se tedy například Linux chlubí, že přerušení dělí od příslušného handleru pouze 18 instrukcí (což se člověk dočte ve slavné zprávě „Have you ever kissed a girl?“; dnes už to bude zcela jistě úplně jinak), přidání přesného časovače by mohlo způsobit za jistých okolností zhoršení výkonnosti. (Dlužno připomenout například registrová okénka na platformě SPARC, o jejichž správu a přepínání se musí postarat kernel, když na to přijde, a může na to přijít velmi často.) (Jakmile ovšem musí handler přerušení sáhnout kamkoliv do paměti, která není zrovna v lokální cache na procesoru, cena takového přístupu odpovídá stovkám až tisícům aritmetických instrukcí, takže zůstává otázkou, jak moc velký negativní vliv vlastně microstate accounting má.)
Ať už je způsob měření času jakýkoliv, vždy nakonec dojde na průměrování přes delší časový úsek. Právě volba tohoto delšího časového úseku vede k různým výsledkům pro různé utility. Například průměr za dobu jedné minuty by jistě všechny utility vypočítaly téměř stejně. Jenže tento průměr příliš nevypovídá o změnách zátěže během té minuty. Naopak průměr za sto milisekund velmi rychle (z lidského hlediska) reaguje na změny zátěže, ale potíž je v tom, že je extrémně nestabilní a těžko se z něj (pouhým okem) odhaduje nějaký průměr nebo trend.
Monitorovací utilita v KDE (ksysguard) implicitně vykresluje zátěž pro každý procesor zvlášť. Ta bude samozřejmě mnohem méně stabilní než celkový průměr. Často bude některý z procesorů pravidelně skákat na 100%, protože například zrovna zpracovává data související s šifrováním filesystémů, SSH, VPN, dekódováním hudby a tak podobně, zatímco ostatní procesory budou častěji idle. Tedy to, co vidíš na tom screenshotu, je naprosto normální. V ksysguard si lze u každého sešitu nastavit interval měření, tedy ten interval, přes který se zátěž průměruje. Pak bude vidět, že dlouhý interval produkuje pěkný hladký průběh, ale neukazuje rychlé fluktuace zátěže, zatímco pro krátký interval platí přesný opak. Je méně stabilní, ale změny zátěže (i krátkodobé) jsou hned vidět. Tedy je to věc jakéhosi kompromisu.
Lepší způsob výpočtu zátěže (je-li třeba odhad zátěže aktualizovat často a nepravidelně) je založený na exponenciálním klouzavém průměru, jehož vzorec se trochu poupraví pro „práci se zlomky“ (extrémně vágně řečeno). Výhodou takového postupu je absence pravidelného intervalu, který by přinášel nestabilitu, a možnost aktualizovat odhad zátěže libovolně často. Nicméně i klouzavý průměr potřebuje předem znát konstantu, která představuje kompromis mezi rychlou odezvou na změnu zátěže a stabilitou hlášených hodnot. Nepřítomnost předělů mezi časovými intervaly s sebou ovšem nese jistou daň v podobě malého rezidua z minulosti, bez kterého by ovšem odhad neměl „hladší“ průběh. Pokud vím, současné utility pro měření zátěže klouzavé průměry nepoužívají. Použil jsem tuto techniku v projektech, u kterých byl hladký a zároveň přijatelně přesný odhad zátěže velmi důležitý a kde nebylo žádoucí měřit zátěž v předem daných pravidelných intervalech.
Sečteno a podtrženo, zátěž není žádná přesná a spojitá veličina; je to něco, co se dá mnoha různými způsoby definovat, mnoha různými způsoby měřit a odhadovat. Proto dává každý měřák jiné hodnoty.
16.10.2013 17:34
rADOn | skóre: 44
| blog: bloK
| Praha
Tiskni
Sdílej:
