Dotaz: realtime micro-cron

[hajoucha]

Ahojda,

mám debian s realtime jádrem a proces, který čte teplotu z teploměru (cca 10 měření/s). Potřebuji nyní vyrobit jiný program, který jednou za např. 2s načte teploty a časy uložené někam prvním programem (doba se může změnit, ale ne mnoho, např. 3s,2s,1s, nebo 0.5s je představitelných, 0.1s je už příliš krátké). Nicméně tento druhý program musí nutně běžet velmi přesně periodicky. Tj. každé 2.0001s nikoli jednou 2.1s a jednou 1.9s. Přesnost požaduji alespoň 0.0005s, tj. 0.5ms. Nyní by mne zajímalo, jak to celé šikovně implementovat.

V současné chvíli je to tak, že teplomer čte z hw (skrze gpib) a posílá na stdin. Asi bych měl ještě dodat, že celý záznam, tj. všechny dvojice "čas-teplota" z celého experimentu potřebuji zachovat. Druhý program zase naopak potřebuje tyto dvojice jenom "od posledního čtení". Tj. za poslední 2s.

Odpovědi

[ava]

Řekl bych, že tě bude zajímat

man setitimerman

a z něj ITIMER_REAL

kde do it_interval-u si doplníš dvě vteřiny a odstartuješ to. Nemám osobní zkušenosti s přesností tohoto řešení, ale je to volání na úrovni kernelu, takže by to mohlo být tak přesné jak je jen možné, včetně toho že by nemusela vznikat kumulativní chyba (předpokládám že ta by ti vadila především, to že to bude jednou za 2.1s a podruhé za 1.9s ti asi vadit nebude, pokud ta odchylka nebude příliš velká a součet odchylek bude víceméně nulový). Každopádně si pak přesnost tohoto řešení samozřejmě pro jistotu změř.

[hajoucha]

díky, mrknu na to. Alespoň nějaký začátek....

[trekker.dk]

Nemám osobní zkušenosti s přesností tohoto řešení, ale je to volání na úrovni kernelu, takže by to mohlo být tak přesné jak je jen možné, včetně toho že by nemusela vznikat kumulativní chyba

Taktéž nemám osobní zkušenost, ale kdybych měl něco takového dělat, tak bych asi zkusil stejné řešení.

V závislosti na zatížení stroje (např. počtu procesů, které budou chtít běžet zároveň s tím důležitým) se může objevit nějaké zpoždění mezi spuštěním časovače a reakcí procesu, ale to by se mělo pohybovat v řádu jednotek, maximálně desítek milisekund (a jak už bylo řečeno, časovač běží v jádře, takže toto zpoždění ho neovlivní)

[hajoucha]

no já už se chystám to spáchat a změřit... abych sem mohl hodit konkrétní výsledky. Nicméně ještě než to udělám bych rád zopakoval, že několik milisekund je prostě pro mne příliš dlouho. Takže běžné plánování v systému mi nestačí. Na druhou stranu, mám kernel s realtime patchem, takže ten by to snad mohl vyřešit. Tj. svému časovači dám vysokou prioritu, takže ani při velkém zatížení nebude muset čekat na konci fronty.

[hajoucha]

tak první pokusné měření říká, že zpoždění u běžného procesu je v nejhorším případě 21.5us, což je akceptovatelné. Přitom velká většina časových značek není zpožděná o více než 0.5us. Teď ještě zkusím, co s tím udělá nastavení větší priority...resp. jestli na tohle má nějaký vliv real-time patch.

[e.lisak]

man signal, sigaction, setitimer ...

[kuly]

Jaký to používáš prohlížeč, že ti nezobrazil předchozí odpovědi?

[Jose]

Na co potřebuješ tak přesné rozlišení ? Teploměr připojený přes GPIB stejně bude mít celkové dopravní zpoždění včetně náhodných fluktuací podstatně věší než je vlastní reakce operačního systému.

[hajoucha]

Na co potřebuješ tak přesné rozlišení ?

je to otázka akademické cti. Prostě chci co největší rozlišení pro svůj fyzikální experiment. Navíc se domnívám, že to udělat lze. Tudíž to udělat chci.

Teploměr připojený přes GPIB stejně bude mít celkové dopravní zpoždění včetně náhodných fluktuací podstatně věší než je vlastní reakce operačního systému.

no, domnívám se právě, že nebude. Mám lpt-gpib ovladač, který mi "dopravní zpoždění" gpib minimalizuje. Pak mám real-time patch pro jádro. Možná se ale pletu a někde něco přehlížím. To je vždy možné. Kritika vítána.