Real-Time Linux - Bakalarska prace (diskuse)

[Luk]

S časovači v RTLinuxu ani RTAI bohužel nemám zkušenosti, ale v "normálním" Linuxu se to dělá tak, že se nastaví časovač např. funkcí setitimer(). Předtím se ale musí nastavit reakce na signál (pro časovač reálného času) SIGALRM, který časovač generuje. Bližší informace - viz "man setitimer".

Není to ale v žádném případě "realtime". Při nezatíženém systému závisí zpoždění na hodnotě HZ nastavené při kompilaci jádra, u současných jader (HZ=250) to dělá přes 4 ms (může to být i méně - pokud zrovna běží stejný proces -, ale počítat se musí s touto hodnotou). Při velké zátěži to ale může být i mnohem víc.

[belisarivs]

No, ja budu pouzivat patch Realtime preempt na jadro. To se pak programuje stejne jako normalni jadro.

[zde]

Pro presne casovani vysilani na seriovem portu je preempot patch dosti zbytecny. Ten pomuze pouze tehdy, kdyz mas moc velke latence na interrupty (cili i na casovac) z duvodu ze jiny proces moc dlouho tvrdne v nejakem pomalem syscallu.

[belisarivs]

Jo, diky za radu. Aspon nekdo.

[zde]

Přesnost časování jádra nemá s HZ nic společného. HZ je interval kdy se (potenciálně) střídají procesy, které jsou READY a perou se vzájemně o CPU. Linux umí naplánovat probuzení procesu podstatně přesněji (na jeden tick systémového časovače), a pokud má proces po probuzení vyšší prioritu než proces který je v tom okamžiku na CPU, tak ho preemptne.

[Luk]

Je to možné. Vycházel jsem z toho, co jsem se dočetl o časovačích z dokumentace ke GNU LIBC. Jen potom nerozumím tomu, že když jsem měl hodnotu HZ=1000, bylo zpoždění cca 1,7 ms, kdežto později při HZ=250 bylo okolo 4,7 ms. I když možná je to jen shoda okolností, způsobená tím, že se jednalo o různé verze jádra.

Až budu mít čas, musí se holt podívat do zdrojáků, jak je to tam udělané.

[zde]

Hergot, tak jsi mne znejistěl a zjevně máš pravdu.

BUGS
       The current implementation of nanosleep() is based on the normal kernel
       timer  mechanism,  which  has  a  resolution  of  1/HZ s (i.e, 10 ms on
       Linux/i386 and 1 ms on  Linux/Alpha).   Therefore,  nanosleep()  pauses
       always for at least the specified time, however it can take up to 10 ms
       longer than specified until the process becomes runnable again. For the
       same  reason,  the value returned in case of a delivered signal in *rem
       is usually rounded to the next larger multiple of 1/HZ s.

Přitom by nebyl problém nemít systémový časovač s pevnou periodou, ale vždy se v irq handleru podívat kdy je potřeba probudit další proces, a případně přeprogramovat časovač na kratší než obvyklou hodnotu. Linux saje :(

[belisarivs]

Jo, chapu, ja to tak proste mam zadane, takze proto ten Realtime preempt. Ale diky za info.

[mivrap]

No jo, to je hezký že se ti nechce hledat ani přemýšlet, ale těžko za tebe bude někdo dělat tvoje úkoly celý život. "zdrojáky prohledávat se mi nechce" boha jeho.

Tak se snaž, ne?

Děti, děti, takhle se naučíte h*vno!

[belisarivs]

Dekuju ti pekne za pomoc. Priste si takove rady radsi nech od cesty, prosim. Nevim jak pro tebe, ale pro me je tech 200-250 MB textu celkem dost. Zvlast, kdyz to neni jedina vec kterou mam na starosti.
Ja po nikom nechci, aby vse udelal za me, jenom jsem chtel pomoci.
Muj semestralni projekt jsem zmaknul sam. Taky se tu na me vsichni vybodli a nic mi neporadili.

[Josef Kufner]

Na velikosti zdrojáků nezáleží. Doba hledání a zkoumání je prakticky nezávislá na jejich velikosti. Zavisí to spíš na kvalitě návrhu toho programu a schopnosti ovládat grep (a vim).

[belisarivs]

Vy jste me nepochopil. Ja se ptam pro pripad, ze nekdo vi jak na to abych neztracel cas znovuobjevovanim ameriky. Pokud se nikdo takovy nenajde, tak to proste budu resit sam stejne jako muj sem. projekt.

Ja chapu, ze je super nekomu rict RTFM BFU a pripadat si jako king, ale to mi nepomuze.

Pokud nekdo vi jak na to, odpovi, pokud ne, tak at neztraci cas psanim prispevku jak je skvele si na vse prijit sam.

Dekuji za pochopeni.

[zde]

Moje důvěra v realtime schopnosti Linuxu byla poněkud otřesená, když jsem před týdněm zjistil že dokonale vyladěný (tj s minimem transmit a receive timeoutů) plip link má na TCP úrovni propustnost cca 800kB (tj link běží na nějakých 110kbps), to za vytížení cpu na 98% (v softirq, samozřejmě). Aktuální vanilla kernel, UP, preempt apod vše N.

Naproti tomu když jsem na identickém železe nabootoval Windows 95 na jedné a Windows 2000 na druhé straně, tak přenost dat (navíc ještě s overheadem SMB protokolu) běžel téměř 2x rychleji (nějakých 1.5MB za minutu), navíc za podstatně menší zátěže- nevím kolik ale okna se normálně překreslovaly, zatímco na Linuxu jsem na výpis 'ls' čekal i deset vteřin.

Kdybych to neviděl tak nevěřím.

[Luk]

Podle mě bude nějaká chyba v modulu PLIP. Tohle není normální, a chybu v ovladači paralelního portu, nebo dokonce v jádře, bych určitě nehledal.

Jinak jako příklad je to docela mimo mísu. Mohu argumentovat úplně stejně, proč nepoužívat WinXP s RT8139 - oproti Linuxu (zvlášť tehdy, když se 8139too zkompiluje pro použití mmio) drasticky pomalejší a náročnější na procesor.

[zde]

Ad dotaz:

Asi bych to dělal takto:

- proces spustit v userspace, pod rootem, pomocí iopl() si zvýšit ptivilege level, a chodit na status port uartu přímo.

- popis toho který bit odpovídá rts/cts, dtr apod najdeš všude.

- Adresu uartu zjistíš třeba z /proc/tty/driver/serial, nebo zadáš ručně.

- pro časování by měl stačit usleep() (???)

- Jak zajistit aby na porty UARTu nelezl i někdo jiný (např. ovladač v kernelu) nevím.

Mozná by šlo se status line cvičit i pomocí tcsetattr(), ale nedoporučuju to- UNIX nahromadil kolem terminálového rozharní neuvěřitelné množství balastu.