firr kenobi <p...@g...com> wrote:

> Input moglby bo nawet przyciski fizyczne laguja plus ekran dot laguje na
> maksa, pozatym te wszystkie osy psują się i zamulaja z czasem, co mz też
> ma związek z nie rt-owoscia, czas to przepisać ;-)

Poczytaj o schedulerze i scheduling policy, matole.

--
"Project Manager to człowiek, który myśli, że jak weźmie
dziewięć kobiet, to urodzą dziecko w miesiąc."

do góry

Użytkownik "Slawek Kotynski" <s...@a...com.pl> napisał w wiadomości
news:p3fn4a-2lb.ln1@tower.askar24.pl...
> Musi gwarantować czas reakcji na zdarzenia.

Kursor myszki np. porusza się nawet przy przeciążonym systemie, z kolei
zabijanie procesu może trwać bardzo długo.

do góry

On Thu, 25 Apr 2013 14:06:15 +0200, "Borneq"
<b...@a...hidden.pl> wrote:

>U?ytkownik "Slawek Kotynski" <s...@a...com.pl> napisa? w wiadomo?ci
>news:p3fn4a-2lb.ln1@tower.askar24.pl...
>> Musi gwarantowa? czas reakcji na zdarzenia.
>
>Kursor myszki np. porusza si? nawet przy przeci??onym systemie, z kolei
>zabijanie procesu mo?e trwa? bardzo d?ugo.

A co ma piernik do wiatraka?

Poprzednik podal JEDYNA poprawna definicje RTOS: przewidywalny i
gwarantowany czas akceptacji i wykonania zadania.

A.L.

do góry

On 25.04.2013 14:06, Borneq wrote:
> Użytkownik "Slawek Kotynski" <s...@a...com.pl> napisał w
> wiadomości news:p3fn4a-2lb.ln1@tower.askar24.pl...
>> Musi gwarantować czas reakcji na zdarzenia.
>
> Kursor myszki np. porusza się nawet przy przeciążonym systemie,

Bo zazwyczaj jest "sprzętowy" czyli rysowany bezpośrednio przez kartę
graficzną - system musi odebrać przerwanie (a one są prawie zawsze
hard-rt i działąja nawet przy zawieszonych wątkach (soft rt) kernela) i
wysłać współrzędne do karty graficznej (zapisać 2 rejestry) - koniec.

> z kolei
> zabijanie procesu może trwać bardzo długo.

Wiesz jak działają systemy operacyjne? "Zabicie" procesu to tak z 4
takty zegara - oznaczenie go jako "martwy". Potem może dojść jeszcze
sprzątanie po nim, ale generalnie jest to dość szybkie o ile nie ma
muteksów/ipc czy innych współdzielonych obiektów po drodze.


--
Pozdrawiam
Michoo

do góry

On 2013-04-25 08:21, firr kenobi wrote:
> Chodzi o to ze w systemach o. duzo da sie zrobic i rt byłoby właśnie istotnym
krokiem

Czy to przyspieszy oglądanie Facebooka w Windowsie? Jesli nie, to nie
ten target. Idź szukaj w embedded.

do góry

Dnia Thu, 25 Apr 2013 00:10:27 -0700 po głębokim namyśle Adam Klobukowski
rzekł:

> On Thursday, 25 April 2013 08:43:06 UTC+2, firr kenobi wrote:
>> chodzi chyba raczej o to ze jak wywolujesz dowolny kod to masz
>> gwarancje ze nie zajmie on więcej niż X mikrosekund - ci sie ma dziac
>> gdy jskas fibra przekroczyłaby ten czas (blue screen?) I jak to
>> pogodzić z różnorodna mocą sprzętu to nie wiem

Mechanizm polega na nie wykonaniu mniej istotnych wątków gdy obciążenie
zbiża się do granicy.

> Systemy czasu rzeczywistego gwarantują stałe czasy wykonania pewnych
> operacji (lub nie większe niż) lub możliwość dokładnego wyliczenia ile
> dana operacja zajmie. Dodatkowo, umożliwiają przydzielenie procesom
> twardych priorytetów, tj. przydzielenia stałego fragmentu mocy
> procesora.

Nie do końca. Zgodziłbym się co do Hard Realtime, ale w Soft Realtime
już nie. Tam raczej górny np. kwantyl ma minimalne wymagania, a reszta ma
być reponsywna. W realtime procesor musi mieć zapas, nie ma rt gdy
jest obciążony w 100%. Jak już ktoś wspomniał, są rzeczy typu
sched. policy, jak chociażby odstawiany w pierwszej kolejności batch.

--
Edek

do góry