Přehnaná očekávání od Linuxu

18.8.2007 16:56 | Přečteno: 3054× | Linux |

Tento mail v linux-kernel mailing listu mě přivedl k zamyšlení, jak se s tím, jak Linux postupně získává další a čím dál lepší schopnosti, zároveň zvyšují očekávání, která od něj lidé mají:

Hello!
I need use sleep with accurat timing.
I use 2.6.21 with rt-prempt patch.
with enabled rt_preempt, dyn_ticks, and local_apic
But

req.tv_nsec = 300000;
req.tv_sec = 0;
nanosleep(&req,NULL)

make pause around 310-330 microseconds.

I tried to understend how work nanosleep(), but it not depends from
jiffies and from smp_apic_timer_interrupt.

When can accuracy be lost?
And how are process waked up?


GolovaSteek

Ještě úplně nedávno (předtím, než Linux dostal časovače s vysokým rozlišením) když nějaký proces požádal o dočasné uspání na krátkou dobu, Linux ho nemohl probudit dřív než za jednu jiffy, tj. jeden celý tik časovače. Při obvyklém nastavení HZ=1000 to byla tedy vždy aspoň jedna milisekunda navíc k požadované době uspání. Při HZ=100 by to bylo deset milisekund.

Dneska se lidi diví, že když požádají o prodlevu 300 mikrosekund, bude ve skutečnosti delší o 10 až 30 mikrosekund a ještě jim ten 20-mikrosekundový nepředvídatelný jitter vadí.

To bych teda rád věděl, jaká aplikace má takové přísné požadavky, a proč si vůbec někdo myslí, že je PCčko může být schopno splnit.

Linux je v tomto případě totiž už tak skvělý, že možnosti programu jsou omezovány převážně schopnostmi hardwaru.

       

Komentáře

[vencour]

Jaký je vůbec praktický rozdíl meze linuxem a unixem? Zjistil jsem, že v jednom železe žijí vxworks, v něčem sakra stabilním. Takže nějaké řešení, východisko, být musí.

[Bluebear]

Dovedu si představit, že taková přesnost je třeba při řízení nějakého velmi jemného stroje, ale je pravda, že tam by se měl používat spíš nějaký jednočip bez operačního systému, jen s jednoduchým, ale zato předvídatelným programem.

[Lu-Tze]

Né že by teda z toho bylo jasné, o jakou přesnost vlastně jde.

[Bluebear]

Řekl bych, že požadovaná maximální chyba je méně než 10 mikrosekund.

Přiznávám, že se mi ještě nepodařilo vymyslet stroj, při jehož řízení by záleželo na 10 mikrosekundách; mám dojem, že ani jaderné reaktory, ani navigace raketoplánu nepotřebují tak přesné časování...

[Kyosuke]

Reaktory s tepelnými neutrony by uřídil i ENIAC. O jednom stroji vyžadujícm opravdu přesné řízení bych snad věděl - doufám však, že nevytahuju ožehavé téma...

[vencour]

Co je tam za řízení? To snad je jen statistika (+-), pustit do sebe dva svazky, změřit, vyhodnotit, najít nové částice ... ?

[Kyosuke]

Neříkej mi, že synchrotron se uřídí sám od sebe? Ty svazky částic vyžadují sakra přesné řízení a zaostřování.

[tdx]

To je ten, který bude slavnostně uveden do ostrého provozu 21. prosince 2012?

Jo! Ta část, jak Lister nastartuje druhej velkej třesk startérem z Kosmiku.

[Dalibor Smolík]

Ano, určitě je to ten

[Luk]

Např. řídicí jednotka spalovacího motoru potřebuje přesnější časování (je-li realizována plně softwarově). Ale předpokládám, že na to nikoho nenapadne použít aplikaci v běžném operačním systému! Když už Linux, tak opatchovaný na hard real-time plánování.

[Bluebear]

To jsem nevěděl, díky za informaci. Nicméně na takové řízení se asi používají opravdu ty jednočipy.

[Luk]

Nicméně na takové řízení se asi používají opravdu ty jednočipy.

Dnešní trend (který se mi příliš nelíbí, ale co nadělám) je ovšem soustřeďovat co nejvíc činností do jediného fyzického počítače. S tím, že jednotlivé funkce (u toho auta třeba řízení motoru, bezpečnostní systémy, diagnostika, klimatizace, rádio/TV atd.) běží v oddělených kontejnerech uvnitř nějakého hard real-time systému (např. PikeOS).

Ty skutečně kritické aplikace (motor, bezpečnost) jsou přímo v podobě nativních programů v jednotlivých kontejnerech, méně kritické pak mohou běžet na normálním OS (třeba Linuxu) nebo VM (třeba JVM) v rámci dalších kontejnerů.

[Jiří Veselský]

Pokud myslíte stroj ve smyslu fyzického zařízení, které s něčím hýbe, tak shodně s vámi nenalézám nic, kde je timing s rozlišením 10 mikrosekund nezbytný. Jedním dechem ale dodávám, že nepochybuji o existenci aplikací, které takovou přesnost vyžadují, akorát teď zrovna mě žádná nenapadá... BTW, raketoplány a jaderné reaktory jsou pomalé věci, tam nemáte kam spěchat. Ale co třeba nějaký špičkový obráběcí stroj? Jak rychle se točí hřídel a v jakých intervalech se vystavuje poloha nože?

Pokud ovšem netrváte na fyzickém pohybu věcí, pak samozřejmě existují stroje, které takovou (a ještě řádově vyšší) přesnost skutečně vyžadují. Triviálním příkladem budiž jakýkoliv gigabitový ethernetový switch - a i v těchto strojích je uvnitř nějaký CPU s nějakým OS, a i když se většina dějů takového switche odehrává "in silicon" (tedy mimo softwarový proces zpracování), některé přeci jen obsluhuje přímo CPU a musí je obsloužít pekelně rychle...

[Filip Dominec]

Takové zařízení by mohl být jednoduchý, na koleně zbastlený softwarový osciloskop, který sice mívá mizernou samplovací frekvenci (~100 kHz?), ale pokud se samotná doba měření zkrátí (což by neměl být problém na 1 µs, když s dobrou elektronikou se lze dostat pod 25 ps), lze s ním koukat na periodické signály s podstatně vyšší frekvencí, než je samplovací. Jenomže tam nesmí být jitter v snímání samplů. To je jenom takový nápad, možná je to blbost...

[Ctirad Feřtr]

To jsou ale dvě trochu nesrovnatelné věci. Uvědomte si, na jaké frekvenci běží dnešní průměrný CPU (už i to je řádově menší, že frekvence signálů běžné ve sdělovačce), jakými rozhraními je propojený s okolním světem a jak dlouhá doba tedy uběhne od chvíle, kdy se vyvolá přerušení do chvíle, kdy CPU událost zpracuje a nastaví nějaké bity na výstupním rozhraní.

[Kvakor]

No, ja treba pouzivam casovani na urovni milisekund pro moje softwarove PWM - ma deska je bohuzel natolik tupa, ze bouzel vsechny hodnoty od 255 do 8 delaji na ventilatoru maximalni otacky, od 7 do jedne se toci jen o cca. 100 ot/min mene a teprve pri nule se vypne uplne (kde asi udelaly inzenyri z Taiwanu chybu?).

Takze si delam PWM sam, tim, ze na se na jednu muilisekundu vetrak pusti (zapise se 1 do pwm1) a zas vypne (zapise se 0 do pwm1) a pak se bud 17ms nebo 34ms ceka. Musel jsem sice dat k ventilaturu vyhlazovaci LC filtr, aby slo odecitat otacky (jinak to vracelo hlouposti jako 320000 ot/min), ale jinak to funguje bez problemu. Thread, ve kterym bezi samotna smycka, musi mit nastavene realtimove planovani, jinak to funguje divne nebo vubec.

Jedina nevyhoda je, ze pokud se nahodou system tvrde rizne behem doby kdy je zpsana nula (coz je pravdepodobne), tak se procesor upece . Takze to pouzivam jenom kdyz jsem u pocitace - kdyz odejdu nebo kdyz se pousti automaticky (treba na nahravani z TV), tak je to vypnute, coz vubec nevadi, protoze tam stejne neni nikdo komu by hucici vetrak vadil .

[Ladislav Jancik]

zkusil bych upgrade BIOSu. mozna to pomuze.

[Bluebear]

To ale musí šíleně žrát výkon; nešlo by tam dát právě nějaký maličký čip, který by to řídil sám na základě údaje nastaveného z PC?

[Luk]

Proč by to žralo výkon? Vždyť je to vcelku nenáročné. Když si nechám otevřený browser a tam se bude mrskat nějaká flashová reklama, bude to žrát nesrovnatelně více. Ovšem osobně (pokud bych se do toho vůbec pouštěl, jako že asi ne) bych to dal radši přímo do kernelu (přes kernelový časovač), protože tím by se ušetřila hodně velká část režie.

[Kyosuke]

Tickless jádro podle nějakých těch měření ukouslo pěkných pár wattů ze spotřeby - ty části procesoru, které by normálně periodicky pracovaly, v něm zřejmě idlují (fujtablózní slovo ) po podstatně delší časové intervaly. Není možné, že by takovýhle režim provozu procesoru byl na spotřebu náročnější než osmidrátový PIC-brouk na nízké frekvenci? (Myslím, že dokážou jít dolů až na 32 kHz a pár miliwattů spotřeby, ne-li míň...)

[Luk]

Ovšem pokud je procesor chvíli idle (a tedy jeho teplota klesne), větrák by měl zůstat úplně vypnutý (a tedy nějaké zap/vyp není potřeba). Tím nechci to řešení obhajovat, tak jako tak mi nepřipadá moc dobré.

[Josef Kufner]

Tam bych ani nedával nic komunikujícího. Na tohle by stačil termistor a 555. Bylo by to spolehlivější a plně automatické.

[Kvakor]

Ne, vykon to opravdu nezere, i po nekolika hodinan je celkovy cas vsech vlaken mensi nez jedna sekunda. Program prece vetsinu casu jen ceka a obcas neco zapise do /sys. A pajet neco na desce s osmi vrsvamy spoju se mi opravu, opravdu nechce ...

A k predchozimu dotazu: Update BIOSu by opravu nepomohl - tohle dela primo SuperIO chip (v mem pripade Winbond 83967HF), BIOS ho jen nastavi pri startu (max. teplota procesoru), ale to je asi tak vsechno, navic lmsensors BIOS vubec nevyuzivaji. Tohle je spackany vystupniho obvodu spinaciho transistoru, nespis moc velka kapacita u gate.

[Ctirad Feřtr]

No, ja treba pouzivam casovani na urovni milisekund pro moje softwarove PWM

Článek ale mluví o mikrosekundách. To jsme trošku jinde. Přesnost v řádu miliseknud je celkém běžná a v podstatě nutná. Třeba i při přehrávání videa nebo zpracování audia posun větší než cca 10ms už člověk vnímá jako zpoždění.

[jnc]

dobrý názov blogu :)

[zde]

Dneska se lidi diví, že když požádají o prodlevu 300 mikrosekund, bude ve skutečnosti delší o 10 až 30 mikrosekund a ještě jim ten 20-mikrosekundový nepředvídatelný jitter vadí.

A proč by se sakra neměli divit? Pamatuju si jak jsem nedávno propadl záchvatu smíchu, když jsem zjistil jak blbě pre-tickless časování v Linuxu vlastně funguje. Jako diplomku jsem psal realtime plánovač pro PC-XT, a počítat timeout k nejbližšímu eventu a programovat tím PIC v one-shot módu mi přišlo jako naprostá samozřejmost. Nechápu proč Linuxu něco podobného trvalo dalších 15 let.

[Kyosuke]

Ech, to mělo být sem: Viz přípěvek o kousek níže.

[Kyosuke]

Hmm, jak na tom bylo PC/XT se SMM módem? Tehdy ten stroj byl podstatně jednodušší...

[zde]

Nevím co je to SMM mód. Já tehdy jednoduše nechal mode=0x36 a přeprogramovával counter v každém interruptu. Latence šla měřit (přečtením counteru před jeho přeprogramováním) a maskovat (odečíst od nově nastavované hodnoty). Problémem byly jen velmi krátké intervaly, tam hrozí že counter podteče víckrát než právě jednou, než ho stihnu přečíst. To jsem řešil dolním limitem na timeouty, když se procesy chtěly naplánovat fous od sebe, byly do running fronty šoupnuty současně. Speciální případ byl taky když další timeout byl stejný jako předchozí, pak se nemuselo dělat nic, protože latence současného interruptu už se sama odečetla od hodnoty counteru. Teď jsem vygoglovat tohle:

http://www.microsoft.com/whdc/system/CEC/mm-timer.mspx

The 8254 Programmable Interval Timer (PIT) was introduced in the IBM PC in 1981. It has a resolution of 1 millisecond and supports both periodic and aperiodic modes. However, because reads from and writes to this hardware require communication through an IO port, programming it takes several cycles, which is prohibitively expensive for the OS. Because of this, the aperiodic functionality is not used in practice. For this reason, this timer is only used in periodic mode to provide the periodic clock interrupt on uni-processor systems.

No, 2x IN a 2x OUT rozhodně nepovažuju za "prohibitively expensive for the OS". Navíc, wikipedia píše:

http://en.wikipedia.org/wiki/Intel_8253

In modern times, this PIT is not included as a separate chip in an x86 PC. Rather, its functionality is included as part of the motherboard's southbridge chipset. In some modern chipsets, this change may show up as measurable timing differences in accessing a PIT using the x86 I/O address space. Reads and writes to such a PIT's registers in the I/O address space may complete much faster.

..takže to programování PICu vůbec nemusí chodit přes nějaké pomalé emulované ISA I/O.

Ad jednodušší HW: Ano, byl jednodušší. Já s jednoduchostí problém nemám, jednoduchá řešení jsou obvykle správná.

[zde]

Teď si všímám, že tam mají milisekundu, asi překlep místo mikrosekundy. Nojo, Microsoft...