<f...@g...SKASUJ-TO.pl> napisał(a):

> <f...@g...SKASUJ-TO.pl> napisał(a):
>
> > Piotr Chamera <p...@p...onet.pl> napisał(a):
> >
> > > W dniu 2011-10-07 19:00, f...@g...SKASUJ-TO.pl pisze:
> > > > nie dam rady szybko przeczytac, ale zgadza sie ze tam jest
> > > > napisane ze te kawalki dla procesow to zwykle ok 20 ms
> > > > dla desktopow i 120 dla serwerow
> > > > (bardzo dlugo, myslelem ze to sie robi z 1000 razy czesciej)
> > >
> > > przełączenie kontekstu to kosztowna operacja - przerwanie potoku,
> > > zachowanie rejestrów, przeładowanie tlb, przeładowanie zawartości
> > > cache... na całość traci się kilkaset ns (lub więcej, zależy od wielu
> > > czynników) więc nie można tego robić zbyt często, bo nie wykonamy
> > > żadnej użytecznej pracy :) (przy kwancie 20 ms i czasie przełączenia
> > > 500ns tracimy ok. 2,5 %; przy kwancie 5 ms byłoby to już 10% itd).
> >
> > raczej rabnales sie o 1000x w tych oszacowaniach bo 500n to 0.5mikro
> > a nie 0.5 mili,
> >
> > ale z innych oszacowan wychodzi ze to przelaczanie moze
> > miecjednak spory udzial: (1) wydaje mi sie ze przelaczenie
> > kontekstu to moze byc wiecej niz 500 ns - 500 ns to nie
> > jest czas w ktorym mozna jakos duzo zrobic - no ale
> > trudno powiedziec, moze wydala w 0.5
> > (2) mi proces explorer dla wszystkich procesow pokazuje
> > tak z 1500 context switchow na sekunde (a jak doliczyc te
> > od przerwan to 1000 wiecej, ale nie wiem czy te nalezy doliczac
> > pewnie tak), wezmy 1 mikro na context switch x 2500 switchow
> > 2.5 ms na przelaczanie; ujdzie ale jest zauwazalne
> >
> > odrebny problem to to co wczesniej wspominane, ktore apki
> > z tla i jak podkradaja mi czas procesora... (bo te sa o wiele
> > gorsze niz samo przelaczanie)
> >
>
> same przelaczeniowe wtrety nie sa tak zle bo sa
> drobnoziarniste (choc kiedys cos czytalem ze niektore
> z przerwan i tak moga wstawic jakis gruby wtret i to
> wlasnie dyskwalifikuje winde do zast realtime, nie wiem
> dokladnie) takie drobnoziarniste wtrety moglyby robic
> problemy z plynnoscia ale w znacznie nizszej skali,
> np gdyby ktos chcial miec stabilne ramki w skali
> mikrosekund (ilustam), ja chialbym miec jedynie
> stabilne niezaburzane ramki w skali powiedzmy 300 - 500 Hz
> a mam tymczasem cholerne kobylaste cykliczne piki
> na 30 ms czy nawet wiecej (to juz przesada) - co
> prawda jak mowilem jak przelacze riorytet procesu na
> high to ich juz nie ma
>
>
w sumie to jest tam cos co by pasowalo jako ew wyjasnienie
tych pikow ale pewnosci czy to jest wlasnie to nie mam:
ponoc winda wybiera do dzialania procesy o najwyzszym
priorytecie, natomiast te o nizszym sa zatrzymywane,
ale aby nie zaglodzic ich na smierc raz na sekunde
sprawdza czy ktores z nich przez ostatnie 4 sekundy
dobijaly sie do dzialanie, o ile tak to na chwile
podnosi im priorytet na 15 - i z tego mogolyby wynikac
te piki mw co sekunde, co prawde jak ustawiam proces
na high to juz ich nie ma a high to chyba tylko 13
a 15 jest wiecej niz 13 , jest jeszcze cos takiego ze
(o ile rozumiem) fokusowany proces ma jakiegos boosta
do priorytetu (+3 chyba) albo do kwantu (x3 chyba)
ale chyba na xp jest to to drugie wiec nie tlumaczyloby
czemu juz 13 blokuje tamte glodomory (no ale ani bardzo
dokladni nie czytalem ani tez b dokladnie nie testowalem)



--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/