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).

do góry

W dniu 2011-10-07 19:34, 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)
>>
>> mozna tez przelaczac w zakladce system -> -> -> planowanie
>> uzycia procesora miedzy 20 ms a 120 ms
>>
> ale jesli tak to pownienem miec 50 context switchow na sekunde
> a process explorer pokazuje ze mam 150-200

wątek nie musi wykorzystać całego kwantu, często zatrzyma się czekając
na I/O, na semaforze itp. więc system przełączy na następny gotowy do
pracy - kwant to maksimum, średnia zawsze będzie mniejsza. Problem
w tym, że od czasu do czasu któryś jednak wykorzysta cały kwant i na te
20 ms zatrzyma wszystkie pozostałe, i że trudno przewidzieć kiedy to
się stanie.

do góry

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)




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

do góry

<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






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

do góry

Piotr Chamera <p...@p...onet.pl> napisał(a):

> W dniu 2011-10-07 19:34, 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)
> >>
> >> mozna tez przelaczac w zakladce system -> -> -> planowanie
> >> uzycia procesora miedzy 20 ms a 120 ms
> >>
> > ale jesli tak to pownienem miec 50 context switchow na sekunde
> > a process explorer pokazuje ze mam 150-200
>
> wątek nie musi wykorzystać całego kwantu, często zatrzyma się czekając
> na I/O, na semaforze itp. więc system przełączy na następny gotowy do
> pracy - kwant to maksimum, średnia zawsze będzie mniejsza. Problem
> w tym, że od czasu do czasu któryś jednak wykorzysta cały kwant i na te
> 20 ms zatrzyma wszystkie pozostałe, i że trudno przewidzieć kiedy to
> się stanie.
>
mam tam tylko jeden watek i nie amm io ale przypomnialem sobie
ze przeciez mam tam 1 ms sleepa, a skoro klatka tam ma mw 7 ms to
by sie zgadzalo

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

do góry

<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/

do góry

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


> (o ile rozumiem) fokusowany proces ma jakiegos boosta
Ma na pewno, wiele razy to obserwowałem. Nie mam pewności
skąd to się bierze, strzelam że z ustawień w systemie,
czy optymalizować usługi w tle.

Pozdrawiam


--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl

do góry

M.M. <m...@t...pl> napisał(a):

> >  <f...@g...SKASUJ-TO.pl> napisał(a):
>
>
> > (o ile rozumiem) fokusowany proces ma jakiegos boosta
> Ma na pewno, wiele razy to obserwowałem. Nie mam pewności
> skąd to się bierze, strzelam że z ustawień w systemie,
> czy optymalizować usługi w tle.
>
> Pozdrawiam

z tego co pisze w windows internals w xp (a mam stare wydanie tak ze nie
wiem jak w ciscie i 7) wotki procesu w foreground dostaja 60 milisekundowe
slice zamiast 20 ms (jak ustawic w zakladce te bacground services) to
jak rozumiem tego boosta nie ma i wszystkie procesy dostaja po 120 ms

Quantum Boosting

Prior to Windows NT 4.0, when a window was brought into the foreground on a
workstation or client system, all the threads in the foreground process (the
process that owns the thread that owns the window that's in focus) received a
priority boost of 2. This priority boost remained in effect while any thread
in the process owned the foreground window. The problem with this approach
was that if you started a long-running, CPU-intensive process (such as a
spreadsheet recalculation) and then switched to another CPU-intensive process
(such as a computer-aided design tool, graphics editor, or a game), the
process now running in the background would get little or no CPU time because
the foreground process would have its threads boosted by 2 (assuming the base
priority of the threads in both processes are the same) while it remained in
the foreground.

This default behavior was changed as of Windows NT 4.0 Workstation to instead
triple the quantum of the threads in the foreground process. Thus, threads in
the foreground process run with a quantum of 6 clock ticks, whereas threads
in other processes have the default workstation quantum of 2 clock ticks. In
this way, when you switch away from a CPU-intensive process, the new
foreground process will get proportionally more of the CPU, because when its
threads run they will have a longer turn that background threads (again,
assuming the thread priorities are the same in both the foreground and
background processes).

Note that this adjustment of quantums applies only to processes with a
priority higher than Idle on systems configured to Programs (or Applications,
in Windows 2000) in the Performance Options settings described in the
previous section. Thread quantums are not changed for the foreground process
on systems configured to Background Services (the default on Windows Server
systems).



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

do góry

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

> M.M. <m...@t...pl> napisał(a):
>
> > >  <f...@g...SKASUJ-TO.pl> napisał(a):
> >
> >
> > > (o ile rozumiem) fokusowany proces ma jakiegos boosta
> > Ma na pewno, wiele razy to obserwowałem. Nie mam pewności
> > skąd to się bierze, strzelam że z ustawień w systemie,
> > czy optymalizować usługi w tle.
> >
> > Pozdrawiam
>
> z tego co pisze w windows internals w xp (a mam stare wydanie tak ze nie
> wiem jak w ciscie i 7) wotki procesu w foreground dostaja 60 milisekundowe
> slice zamiast 20 ms (jak ustawic w zakladce te bacground services) to
> jak rozumiem tego boosta nie ma i wszystkie procesy dostaja po 120 ms
>
> Quantum Boosting
>
> Prior to Windows NT 4.0, when a window was brought into the foreground on a
> workstation or client system, all the threads in the foreground process
(the
> process that owns the thread that owns the window that's in focus) received
a
> priority boost of 2. This priority boost remained in effect while any
thread
> in the process owned the foreground window. The problem with this approach
> was that if you started a long-running, CPU-intensive process (such as a
> spreadsheet recalculation) and then switched to another CPU-intensive
process
> (such as a computer-aided design tool, graphics editor, or a game), the
> process now running in the background would get little or no CPU time
because
> the foreground process would have its threads boosted by 2 (assuming the
base
> priority of the threads in both processes are the same) while it remained
in
> the foreground.
>
> This default behavior was changed as of Windows NT 4.0 Workstation to
instead
> triple the quantum of the threads in the foreground process. Thus, threads
in
> the foreground process run with a quantum of 6 clock ticks, whereas threads
> in other processes have the default workstation quantum of 2 clock ticks.
In
> this way, when you switch away from a CPU-intensive process, the new
> foreground process will get proportionally more of the CPU, because when
its
> threads run they will have a longer turn that background threads (again,
> assuming the thread priorities are the same in both the foreground and
> background processes).
>
> Note that this adjustment of quantums applies only to processes with a
> priority higher than Idle on systems configured to Programs (or
Applications,
> in Windows 2000) in the Performance Options settings described in the
> previous section. Thread quantums are not changed for the foreground
process
> on systems configured to Background Services (the default on Windows Server
> systems).
>
>

mw to co solomon i russinovich pisza w tym windows internals sie
zgadza, ale niktore rzeczy sa wyrazone albo ja je rozumiem niejasno,
np tam jest powtarzane ze czas procka dostaje proces o najwyzszym
priorytecie a jak jest kilka o tym samym priorytecie to one go dostaja
z tym ze foregroundy dostaja 3 razy dluzsze slice, watki o nizszym
priorytecie od tych dzialajacych ogolnie nie dostaja nic poza
pewnym dodatkowym mechanizmem pomocniczym ktore raz na sekunde
popycha na 20 ms te niskiego priorytetu ktore od 4s chcialy
dzialac a nic nie dostaly (to co tu pisze dodtyczyc
powinno przynajmniej jednoprocesorowego xp bo na to zwracalem uwage)

tylko ze z tego by wynikalo ze jak odpale samego proces explorera
ktory ma priorytet 13 to inne apki (a wszystkie dzialaja z priorytetem
8 powinny stac), chyba wiec jest tak ze te o najwyzszym priorytecie
dostaja procka ale te o nizszym nie dostaja nic tylko _reszte_,
tyle ile zostawia te o najwyzszym priorytecie, ja np poki co
nawet intensywnie ielace apki puszczam na 90-95% czasu procka
a nie na calosc, bo te wolne 5-10% jest o wiele bardziej
potrzebne windzie (ktora dziala na tym zupelnie spox) niz
mojemu progsu



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

do góry

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

> <f...@g...SKASUJ-TO.pl> napisał(a):
>
> > M.M. <m...@t...pl> napisał(a):
> >
> > > >  <f...@g...SKASUJ-TO.pl> napisał(a):
> > >
> > >
> > > > (o ile rozumiem) fokusowany proces ma jakiegos boosta
> > > Ma na pewno, wiele razy to obserwowałem. Nie mam pewności
> > > skąd to się bierze, strzelam że z ustawień w systemie,
> > > czy optymalizować usługi w tle.
> > >
> > > Pozdrawiam
> >
> > z tego co pisze w windows internals w xp (a mam stare wydanie tak ze nie
> > wiem jak w ciscie i 7) wotki procesu w foreground dostaja 60 milisekundowe
> > slice zamiast 20 ms (jak ustawic w zakladce te bacground services) to
> > jak rozumiem tego boosta nie ma i wszystkie procesy dostaja po 120 ms
> >
> > Quantum Boosting
> >
> > Prior to Windows NT 4.0, when a window was brought into the foreground on
a
> > workstation or client system, all the threads in the foreground process
> (the
> > process that owns the thread that owns the window that's in focus)
received
> a
> > priority boost of 2. This priority boost remained in effect while any
> thread
> > in the process owned the foreground window. The problem with this
approach
> > was that if you started a long-running, CPU-intensive process (such as a
> > spreadsheet recalculation) and then switched to another CPU-intensive
> process
> > (such as a computer-aided design tool, graphics editor, or a game), the
> > process now running in the background would get little or no CPU time
> because
> > the foreground process would have its threads boosted by 2 (assuming the
> base
> > priority of the threads in both processes are the same) while it remained
> in
> > the foreground.
> >
> > This default behavior was changed as of Windows NT 4.0 Workstation to
> instead
> > triple the quantum of the threads in the foreground process. Thus,
threads
> in
> > the foreground process run with a quantum of 6 clock ticks, whereas
threads
> > in other processes have the default workstation quantum of 2 clock ticks.
> In
> > this way, when you switch away from a CPU-intensive process, the new
> > foreground process will get proportionally more of the CPU, because when
> its
> > threads run they will have a longer turn that background threads (again,
> > assuming the thread priorities are the same in both the foreground and
> > background processes).
> >
> > Note that this adjustment of quantums applies only to processes with a
> > priority higher than Idle on systems configured to Programs (or
> Applications,
> > in Windows 2000) in the Performance Options settings described in the
> > previous section. Thread quantums are not changed for the foreground
> process
> > on systems configured to Background Services (the default on Windows
Server
> > systems).
> >
> >
>
> mw to co solomon i russinovich pisza w tym windows internals sie
> zgadza, ale niktore rzeczy sa wyrazone albo ja je rozumiem niejasno,
> np tam jest powtarzane ze czas procka dostaje proces o najwyzszym
> priorytecie a jak jest kilka o tym samym priorytecie to one go dostaja
> z tym ze foregroundy dostaja 3 razy dluzsze slice, watki o nizszym
> priorytecie od tych dzialajacych ogolnie nie dostaja nic poza
> pewnym dodatkowym mechanizmem pomocniczym ktore raz na sekunde
> popycha na 20 ms te niskiego priorytetu ktore od 4s chcialy
> dzialac a nic nie dostaly (to co tu pisze dodtyczyc
> powinno przynajmniej jednoprocesorowego xp bo na to zwracalem uwage)
>
> tylko ze z tego by wynikalo ze jak odpale samego proces explorera
> ktory ma priorytet 13 to inne apki (a wszystkie dzialaja z priorytetem
> 8 powinny stac), chyba wiec jest tak ze te o najwyzszym priorytecie
> dostaja procka ale te o nizszym nie dostaja nic tylko _reszte_,
> tyle ile zostawia te o najwyzszym priorytecie, ja np poki co
> nawet intensywnie ielace apki puszczam na 90-95% czasu procka
> a nie na calosc, bo te wolne 5-10% jest o wiele bardziej
> potrzebne windzie (ktora dziala na tym zupelnie spox) niz
> mojemu progsu
>
>
wogole process explorer to fenomenalne narzedzie,
zainstaluj sobie jak piszesz pod winde, juz nie
wyobrazam sobie uzywania windy bez tych malych wskaznikow
w trayu ktore pokazują wykresiki na ile mieli w tej chwili procek,
mozna tez dostac tony innego ciekawego info (np widze ze
itunes odtwarzajac mi kazika konsumuje ok 6%, przy zmianie
piosenki na nowa na 2 sekundy zamulil do 70% po czym znowu
zlecial do kilku procent; ale wielu rzeczy z tych co podaje
nawet dotyczacych moich progow ktore od wewnetrznej
strony dobrze znam, nie kojarze np nie wiem co to jest
USER objects, dla bociakow jest to 9, samo GDI objects
jest 14 i co to jest - uchwyty do windowsowych resourcow?




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

do góry