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