Nový démon ulatencyd má snížit odezvu desktopů

Daniel Poelzleithner nedávno zveřejnil svůj nový projekt ulatencyd. Jde o skriptovatelného démona, který má snížit odezvu desktopu pomocí dynamické úpravy plánovače. Autor projekt úspěšně otestoval na kompilaci kernelu s -j40 paralelně se sledováním HD videa. Projekt je hostován na Githubu, informuje Phoronix

13.1.2011 15:48 | Jakub Lucký | Zajímavý software

Komentáře

[jozinzbazin]

Stručně je to na prd. Plánovač CPU podle mě dávno funguje spolehlivě. Jediné, co počítač kompletně "znehodnotí" je větší práce s diskem.

[Josef Kufner]

...a vyplachováná cache jediným procesem, který toho přečte hodně, ale jen jednou (např. zálohování).

[Jendа]

Jo, toho jsem si nedávno taky všiml. Stačí přenášet něco po síti (~1,5 MB/s) a za pár minut čekáš na přepnutí z Firefoxu do Thunderbirdu. Dá se to nějak řešit (explicitně zakázat cachování nějakému procesu)?

[Jiří J.]

Dá, plánuji o tom napsat krátce v blogu, až mi skonči jísté ... období

Ve zkratce jde o to, že ulimit neumí limitovat unmapped paměť, ale cgroups to umí, takže řešením je zabalit "dd" (nebo jinou věc) do cgroupy a omezit paměť na pár MB. Bohužel nic elegantnějšího v rámci současného kernelu pravděpodobně možné není.

[Karry]

Jádro nevidí uživatelům do hlavy (díky bohu), takže nemůže vyhovět všem jejich zvráceným požadavkům. Právě vysoce paralelní kompilace a sledování HD videa je ukázkovým příkladem :) S tímto démonem budeš moci své požadavky specifikovat jednou a provždy.

Jinak s tvou narážkou na IO souhlasím.

[peterh]

Ale da sa ocakavat, ze prehravanie hudby musi byt neprerusovane a to iste aj video. Preto staci, aby toto nahintovali priamo aplikacie planovacu. Tiez napr., ze na desktope to okno, ktore je na vrchu je pravdepodobne to s ktorym pracujeme (nechcem tvrdit, ze windows to maju dobre, lebo tie sa tiez obcas na par sekund zakusnu).

[imploder]

Přesně, to mě taky štve. Něco kopíruju na disku a zbytek aplikací je tím hodně zpomalený, až se to skoro nedá používat.

[MaSo]

+1

[tomboytom-deviant]

Zdravím jaderné znalce, můžete mi osvětlit, jaktože má plánovač cpu (takový) vliv na odezvu desktopu při sledování HD videa, které dekóduje grafická karta? A nebo si to programujou fanATIci, kteří jí ještě namají...

[Rovano]

Zaprvé: On někde řekl, že mu to jede částečně přes GPU? Zadruhé: GPU nepočítá vše.

[Peter Fodrek]

velmi jednoducho

Tej karte musi nejaky proces davat data na dekodovanie. A ten proces bezi na CPU. Uz nehovorim o tom,ze to je tak, ze poslete karte data , ona ich dekoduje a zobrazi

Ale je to inak. Karta dekoduje data tie musi prijat proces na CPU a poslat ich do karty ako zabrazovaceie data..

a mimochodm fanATici uz nexistuu su len AMDroidi. A na AMD GPU to ide len API, ktore to umoznuje programy nevyuzivaju

[Tomáš Veslý]

Já třeba mám nvidiu8600m, a podle testů hd video narozdíl od dvoujádra na 2.0 GHz nezvládá(samozřejmě s binárními ovladači...).

Zajímavé je, že třeba Seti Home(už se to dávno jmenuje jinak, ale to je fuk) mi jelo na grafice pro změnu 4x rychleji, než na procíku.

[SPM]

Já jsem ze srandy zkoušel před pár dny pouštět na ntb nějaké full hd video. Core 2 duo @ 2,5GHz a nvidia 8400M GS... upřímně nevim jestli to počítala grafika nebo cpu (tak či tak se to hřálo jak prase a bylo to vytížený), ale stálo to celkem za nic (asi by se na to dalo koukat, ale úplně plynulé to nebylo)... takže to skončí tím, že k tv koupím nějaký ten malý čínský přehrávač a bude klid :))

[vodic]

Tak to je u tebe neco spatne. Ja mam integrovanou grafiku v chipsetu NVIDIA 8200, ktera je rozhodne pomalejsi, nez ta tvoje, a presto bez vetsich problemu zvladne full hd pres VDPAU naprosto plynule. Jen se to nesmi prehanet s postprocessingem.

[klif]

Tak zvýšit či snížit?

LOL, stejně je to prča, že Linux má za 10 let svého vývoje pořád stejné problémy. Holt plánovač je na hovno no (nejen on).

[Jakub Lucký]

Jo, pravda, mělo tam být zlepšit... Ale snížit je myslím logické, měříme-li odezvu časem...

[urblb]

Autore zpravicky:

Latency prelozeno do ceskeho jazyka muze byt "zpozdeni". Kdyz pak prekladame "minimize latency", pak doslova chceme "minimalizovat (lepe snizovat) zpozdeni".

No a pokud chceme volny preklad, tak muzeme pouzit "zvysujeme odezvu".

Jakakoliv dalsi vedecka diskuze, jak je na tomto serveru nekdy zvykem, na toto tema pak uz nema moc smysl.

[Peter Fodrek]

Planovac je dobry. Dokonca vynikajuci

napr. maximalna latencia Wind River Linux (byvaly RTLinux Pro) je 48 nanosekund maximalna latencia Windows NT jadier (treda aj Windows, 2000, XP, Vista, 7 ) je 300 milisekund teda takmer 7 500x vysia a teda horsia.z pohladu riadneie v realnom case

Ten demon riesi len to, ze parametre planovaca (ktore mozete aj inak samni prestvovat ) sa prestvuju atumaticky, podla kombinacie soft realtime uloh, ako je prehravnie video-a. Soft realtime ulohy, kde primerna latenciua v nejakom useku nesmie byt vacsia ako nejake cislo,

[mnn]

napr. maximalna latencia Wind River Linux (byvaly RTLinux Pro) je 48 nanosekund maximalna latencia Windows NT jadier (treda aj Windows, 2000, XP, Vista, 7 ) je 300 milisekund teda takmer 7 500x vysia a teda horsia.z pohladu riadneie v realnom case

Až na to, že v Linuxe (napr. posledné Ubuntu) mi vždy horšie prehráva HD videá, a vôbec kopíruje súbory na disku než na starom dobrom WinXP (cez DXVA).

A aby to nebolo až také subjektívne, tak aj v tejto diskusii sa ľudia sťažujú na pomalé I/O operácie v Linuxe...

[Peter Fodrek]

planovacov je niekolko

Tu ide o planovac procesov, ktory robi Ingo Molnar

I/O ooperracie planuje iny planovac,,

[Matlák]

Ona jedna věc je latence jádra a jiná věc je overhead X a podobných úletů. Dělám například na jedné aplikaci embedded linuxu a latenci (skutečně v nanosekundách) si nemůžu vynachválit. Tvořím hudbu v reálném čase na linuxu a taktéž skvělé, latence minimální,všechny zvukové karty jsou synchronní, pohoda.

Jakmile ale přijde na grafické operace, windows hravě X porazí, je tam míň vrstev, je to celkově snazší. Pokud má rendering čehokoli vyšší FPS na Linuxu s Xorg než na Windows, velmi pravděpodobně je za tím chyba na straně Windows.

Jinak problémy s I/O na linuxu nemám, nejspíš používám řadič který má ovladač už "vychytaný" jak na laptopu tak na desktopu. Jsem ale spíš v menšině, protože si na I/O spousta lidí stěžuje...a nebo jsou ti lidé co si stěžují nejvíc slyšet? kdo ví

[AsciiWolf]

Jakmile ale přijde na grafické operace, windows hravě X porazí, je tam míň vrstev, je to celkově snazší. Pokud má rendering čehokoli vyšší FPS na Linuxu s Xorg než na Windows, velmi pravděpodobně je za tím chyba na straně Windows.

+1

[Filip]

(300 mili) / (38 nano) = 6 250 000

Nemáš chybu v řádech? Můžeš dát odkaz na zdroj?

[Peter Fodrek]

vynechal som mikrosekundy v uvahe ano je to este 100x viac

v roku 2004 to bolo 143 ns worst case

http://www.linuxfordevices.com/c/a/Linux-For-Devices-Articles/RTLinuxPro-CPU-reservation-technology/

tych 44 som pocital pred asi troma rokmi , akle zdroj tak na rychlo neviem najst

[Kaero]

srovnavat realtime linux (RTLinuxPro) s nerealtimovymi windowsy (WinNT, WinXP) prece nema smysl...?

[Peter Fodrek]

Bohuzial ma, lebo obe sa pouzivaju v riadeni (aj ked pri Windows ako platforma pre SCADA na PLC)

Koncak totiz porovnava len cenu 200 Eur za Windows a 1999 EUR za RTLinux

Teda rozdiel latencii je v tej cene.