abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×

    dnes 11:44 | Komunita

    Konference OpenAlt 2023 proběhne o víkendu 11. a 12. listopadu v Brně. Přihlásit přednášky lze do neděle 08. října 23:59.

    Ladislav Hagara | Komentářů: 0
    dnes 09:00 | Bezpečnostní upozornění

    V X.Org v libX11 do 1.8.7 a libXpm do 3.5.17 bylo nalezeno a v upstreamu opraveno 5 bezpečnostních chyb (CVE-2023-43785, CVE-2023-43786, CVE-2023-43787, CVE-2023-43788 a CVE-2023-43789). Dvě nejstarší jsou s námi 35 let. Obsaženy byly již v X11R2 vydaném v únoru 1988.

    Ladislav Hagara | Komentářů: 3
    dnes 08:00 | Bezpečnostní upozornění

    Byly publikovány informace o bezpečnostní chybě Looney Tunables aneb CVE-2023-4911 v glibc ld.so. Útočník ji může využít k lokální eskalaci práv. Vyzkoušeno na výchozích instalacích linuxových distribucí Fedora 37 a 38, Ubuntu 22.04 a 23.04 a Debian 12 a 13. Chyba byla do glibc zavlečena v dubnu 2021. Detaily v txt.

    Ladislav Hagara | Komentářů: 0
    včera 20:33 | Komunita

    Na Kickstarteru byla spuštěna crowdfundingová kampaň na podporu telefonu Murena 2 s /e/OS. Telefon má 2 hardwarové přepínače. Prvním lze jednoduše vypnout kamery a mikrofony. Druhým se lze odpojit od sítí.

    Ladislav Hagara | Komentářů: 2
    včera 20:11 | Bezpečnostní upozornění

    Společnost Qualcomm publikovala říjnový bezpečnostní bulletin. V úvodu informuje, že bezpečnostní chyby CVE-2023-33106, CVE-2023-33107, CVE-2022-22071 a CVE-2023-33063 jsou cíleně využívány útočníky. O CVE-2022-22071 se píše už v loňském květnovém bulletinu. Detaily o zbylých chybách jsou k dispozici OEM partnerům. Veřejně budou k dispozici až s vydáním prosincového bulletinu.

    Ladislav Hagara | Komentářů: 0
    včera 13:55 | Nová verze

    Byla vydána nová verze 5.18 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přehled změn v příslušném seznamu. Tor Browser byl povýšen na verzi 12.5.6. Tor na verzi 0.4.8.6.

    Ladislav Hagara | Komentářů: 0
    včera 10:55 | Nová verze

    Šifrovací nástroj VeraCrypt v menším vydání 1.26.7 nejen opravuje chyby a aktualizuje podporované algoritmy (podrobnosti v poznámkách vydání), ale také přestává podporovat původní svazky TrueCrypt.

    Fluttershy, yay! | Komentářů: 0
    včera 09:00 | Pozvánky

    V sobotu 7. října proběhne Maker Faire Liberec, festival plný workshopů, interaktivních činností a především nadšených a zvídavých lidí.

    Ladislav Hagara | Komentářů: 0
    včera 08:00 | Zajímavý článek Ladislav Hagara | Komentářů: 0
    2.10. 23:44 | Komunita

    Ubuntu Summit 2023 proběhne od 3. do 5. listopadu v Rize.

    Ladislav Hagara | Komentářů: 0
    Raději
     (54%)
     (46%)
    Celkem 56 hlasů
     Komentářů: 3, poslední 2.10. 23:31
    Rozcestník

    Dotaz: Časovače jádra & traffic shaping

    LFCIB avatar 7.3.2008 22:29 LFCIB | skóre: 19 | blog: LFCIB | /home/lfcib
    Časovače jádra & traffic shaping
    Přečteno: 335×
    Dobrý večer,

    chtěl bych se zeptat, zda někdo nevíte, jestli mohu nějak pozitivně ovlivnit rychlost nebo propustnost serveru, který dělá shaping, za pomocí úpravy hodnot časovače jádra, toho jak se v configu upravuje pro server 100 Hz, pro desktop 1000 Hz nebo tak podobně, už jsem to dlouho neviděl. Ještě jsem zaslechl o beztikovém jádře, ale jelikož tomu nerozumím do hloubky, nevím jestli by nějaké tyto úpravy měly smysl. Nevíte někdo?

    Děkuji
    -=:L:i:N:u:X:=-<=>-=:4:e:V:e:R:=- Vyhovuje mi Debian GNU/Linux

    Odpovědi

    7.3.2008 22:39 trekker.dk | skóre: 72
    Rozbalit Rozbalit vše Re: Časovače jádra & traffic shaping
    Pokud vím, tak tahle hodnota ovlivňuje, jak často plánovač přeruší běh nějaké uživatelské úlohy a nechá běžet jinou. Na serveru, který dělá shaping, se tě to netýká - žádné úlohy neběží, respektive určitě neběží dost dlouho na to, aby to mělo nějaký vliv - takže je záhodno, aby plánovač přerušoval co nejméně často - hodnota 100Hz je lepší, než 1000Hz.

    Beztikové jádro má plánovač upravený tak, že například když běží jenom jedna úloha a žádná další běžet nechce (nebo neběží žádná úloha), tak plánovač žádná přerušení nedělá. Beztikové jádro by tedy bylo ještě lepší, než 100Hz.

    Jestli vliv té změny, pokud nějakou uděláš, bude vůbec měřitelný, to je jiná otázka. Mám ten pocit, že beztikové jádro se nedělalo kvůli výkonu, ale kvůli tomu, aby se v počítači (hlavně u notebooků), který nic nedělá, zbytečně neprobouzelo CPU.
    Quando omni flunkus moritati
    8.3.2008 15:58 Jary | skóre: 30 | blog: Jary má blog | Dům
    Rozbalit Rozbalit vše Re: Časovače jádra & traffic shaping
    Řekl bych, že to může mít vliv na přesnost shapování a na odezvu. Čím větší f, tím větší přesnost a snad i lepší - kratší odezva. Ovšem čím větší f, tím větší overhead zpracovávání přerušení a tím asi i menší propustnost. Ale asi to nebude s tou propustností tak horký. Změř to a pak nám řekni, co ty na to?
    .sig virus 3.2_cz: Prosím, okopírujte tento text do vaší patičky. GitHub
    Max avatar 8.3.2008 16:50 Max | skóre: 72 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: Časovače jádra & traffic shaping
    Čím větší f, tím větší přesnost a snad i lepší - kratší odezva. Ovšem čím větší f, tím větší ...

    Teď jsi to trochu sešmodrchal :).
    Zdar Max
    Měl jsem sen ... :(
    8.3.2008 17:43 Jary | skóre: 30 | blog: Jary má blog | Dům
    Rozbalit Rozbalit vše Re: Časovače jádra & traffic shaping
    Neřekl bych. Ale to je přesně to, co bych řekl, kdybych to měl v hlavě zašmodrchané přesně tak, jak jsem to řekl.

    Frekvence f (Hz, nebo jak se tomu říká) je vlastně maximální frekvence přepínání mezi procesy. Ta je generována nějakým HW čítačem/časovačem. Po doběhnutí vyvolá čítač IRQ a tím se přeruší vykonávání procesu a začne se vykonávat funkce jádra, co zpracovává přerušení. V tomto případě je to funkce, která rozhodne, jestli se CPU předá jinému procesu, nebo se nechá tomu, co ho měl doteď. To závisí na plánovači procesů. Pokud nějaký proces čekal na data, která jsou už k dispozici, tak je dost pravděpodobné, že se kontext přepne - CPU se přidělí onomu procesu, co čekal na data.

    Síťovka IMHO vyvolá přerušení, když dojde nějaký rámec, nebo nějaká skupina rámců. Proces ovladače síťovky má také funkci pro obsluhu přerušení od síťovky, takže síťovku obslouží a pak je otázka, komu předá CPU. Řekl bych, že původnímu procesu. Nevím který proces je zodpovědný za shapování, ale hledal bych v ps -e něco jako htb, ten pravděpodobně čeká, až mu jádro předá nová data ze síťovky, tedy čeká na I/O a je tedy závislý, pravděpodobně, na frekvenci přepínání kontextu.

    Čím více Hz, tím více příležitostí bude mít shaper přijmout a odeslat data - větší přesnost shapování a lepší odezva (ping), ale také může být shaper vícekrát přerušen při počítání, tímpádem padá propustnost, protože jádro se pořád rozhoduje komu dát CPU k počítání, ale procesy nemají moc času na počítání.

    Snad jsem to vysvětlil stručně a jasně.
    .sig virus 3.2_cz: Prosím, okopírujte tento text do vaší patičky. GitHub
    8.3.2008 19:11 trekker.dk | skóre: 72
    Rozbalit Rozbalit vše Re: Časovače jádra & traffic shaping
    Nevím který proces je zodpovědný za shapování, ale hledal bych v ps -e něco jako htb, ten pravděpodobně čeká, až mu jádro předá nová data ze síťovky, tedy čeká na I/O a je tedy závislý, pravděpodobně, na frekvenci přepínání kontextu.
    Za shapování žádný proces zodpovědný není, to má na starosti jádro. Tím pádem tohle:
    Čím více Hz, tím více příležitostí bude mít shaper přijmout a odeslat data - větší přesnost shapování a lepší odezva (ping)
    neplatí, protože jádro má v běhu přednost před uživatelskými procesy a tudíž se ho Hz netýká.
    Quando omni flunkus moritati
    8.3.2008 22:20 Jary | skóre: 30 | blog: Jary má blog | Dům
    Rozbalit Rozbalit vše Re: Časovače jádra & traffic shaping
    Ano, žádný proces co by mohl mít shapování na starosti jsem po modprobe sch_htb nenašel, takže trekker.dk je zdřejmě kabrňák a má pravdu. V tom případě by mě ale zajímalo jak to funguje.

    Dovolil jsem si vymyslet teorii, jak by to mohlo být:

    Pokud jdou data ze sítě, tak síťovkovej driver obslouží přerušení - zpracuje rámec, předá data ip stacku a začne s tím stackem třást, dokud z něj data nevypadnou, už je jedno kam. Proces driveru se po vypadnutí dat ze stacku zastaví a CPU se tak předá někomu jinému.

    Když proces vysílá packet, tak zavolá syscall send, kterej hodí data do stacku a stackem zatřese, dokud packet někam nevypadne. Třeba do fronty TCP portu, nebo do fronty rozhraní, nebo do fronty shaperu.

    No, ale když máme data v shaperu, kdo zatřese shaperem, aby data vypadla na rozhraní? Třást by se mělo asi pravidelně, což odporuje tomu, že by se shaperem třáslo při odesílání a přijímání dat. Má fantazie je v koncích. Jak je to? Můžu si o tom někde přečíst?
    .sig virus 3.2_cz: Prosím, okopírujte tento text do vaší patičky. GitHub
    michich avatar 8.3.2008 23:35 michich | skóre: 51 | blog: ohrivane_parky
    Rozbalit Rozbalit vše Re: Časovače jádra & traffic shaping
    Shaperem zatřese timer v kernelu. A je to hrtimer, takže nemusí být omezen rozlišením 1/HZ.
    8.3.2008 23:35 trekker.dk | skóre: 72
    Rozbalit Rozbalit vše Re: Časovače jádra & traffic shaping
    Ano, žádný proces co by mohl mít shapování na starosti jsem po modprobe sch_htb nenašel...
    Taky jsem to pro jistotu nejdřív vyzkoušel ;-)
    Jak je to? Můžu si o tom někde přečíst?

    Jediná literatura, která mě napadá, jsou zdrojáky jádra.

    Tady budu čistě spekulovat, jak by to s tím shaperem mohlo fungovat. Odněkud se vezmou data (z lokálu, ze sítě), která se mají shapovat. Shaper reaguje na to, že data přišla - dokud žádná nemá, nemá smysl s ním "třást" - zjistí, jestli je může odeslat, tj. jestli nebyl překročen limit, když zjistí, že může, tak je pošle.

    Když zjistí, že je teď vyslat nemůže, tak je někam uloží a nastaví si časovač, že za nějaký čas (který si sám zvolí) chce znovu běžet a teprve potom ta data poslat.

    Jak říkám, je to čistě spekulace a takhle, jak to popisuju, by to bylo přinejmenším hodně zjednodušené.
    Quando omni flunkus moritati
    9.3.2008 00:22 Jary | skóre: 30 | blog: Jary má blog | Dům
    Rozbalit Rozbalit vše Re: Časovače jádra & traffic shaping
    Už mi to asi začíná pasovat dohromady. Plánovač packetů, a pravděpodobně i plánovač procesů, používá hrtimer. Tímpádem s plánovačem packetů třese hrtimer. S procesy taky. Je tedy na hrtimeru, komu dá vyšší prioritu, jestli plánovači procesů, nebo plánovači packetů. Priorita asi nebude definovaná, takže jestli se svýší Hz moc, tak se na plánovač packetů skrzevá plánovač procesů nemusí dostávat. Jelikož by to ale musela být opravdu šílená hodnota Hz a jelikož by se moc nedostávalo ani na procesy, dovoluji si teď tvrdit, že Hz na plánování packetů nemá vliv.

    Děkuji zdejším pánům trekker.dk a michichovi za plodnou diskuzi. I když dost teoretickou.
    .sig virus 3.2_cz: Prosím, okopírujte tento text do vaší patičky. GitHub
    8.3.2008 17:23 trekker.dk | skóre: 72
    Rozbalit Rozbalit vše Re: Časovače jádra & traffic shaping
    Řekl bych, že to může mít vliv na přesnost shapování a na odezvu.
    Shapování a vůbec všechny záležitosti kolem sítí má přece na starosti jádro a toho se četnost tiků plánovače přece netýká, ne?
    Quando omni flunkus moritati

    Založit nové vláknoNahoru

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.