[THIN] Re: thread quanta and chkroot.cmd thingy
- From: "Webmail" <web@xxxxxxxxxx>
- To: <thin@xxxxxxxxxxxxx>
- Date: Mon, 15 Sep 2003 19:26:23 -0400
damn thats more information than anyone needs to know Bernd... LOL my head
is spinning after reading that. Do you keep Kevin locked in a room with
quantum physics books surrounding him? I'm starting to feel like Special Ed
from Crank Yankers.... Yay I can measure quanta..Yay... sorry..couldn't
resist.
JK
-----Original Message-----
From: thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx]
Sent: Monday, September 15, 2003 5:24 PM
To: thin@xxxxxxxxxxxxx
Subject: [THIN] Re: thread quanta and chkroot.cmd thingy
Brian,
Here is the response from Kevin, our CTO:
Tim's test is for priority boost not thread quantum. There is an important
difference. The Background Services vs. Applications setting has no effect
on priority boost. It does, however, have an effect on thread quantum. Just
for clarification, priority determines the thread schedule (which thread
will run next). How long each thread will run (AKA time slice) is measured
in quanta. (Point of interest: the original poster uses the correct usage of
quanta, but MSFT uses quantums so expect to see either in print)
On Windows 2000, when using Applications Mode the time slices vary.
Foreground apps in Application Mode get 6 quanta and background apps get 3
quanta.
When you choose Background Services mode the time slice is fixed at 36
quanta. I haven't checked W2003 yet but assume that the number of quantums
is similar.
When I talked to David Solomon (the guy who wrote Inside Windows 2000) last
December he indicated that the times slices for threads running in Terminal
Services Sessions are not variable even in Applications Mode. Only apps on
the console are considered foreground apps (as far as time slices are
concerned). In other words each terminal session user would get a time slice
of 3 per thread while the console foreground application would get 6
(Regardless of what each thread's priority is). The test I was going to run
was to see if this is correct or not.
However, even without running the test, I recommend Background mode.
Quantums of 3 or 6 are too short for Terminal Services. Compare a typical
terminal server with your desktop machine and look at the difference in the
amount of threads. As you know, each time your time slice expires it causes
a context switch. Having 6 or 12 times as many context switches (3 or 6
compared to 36) is an impediment to performance. Most desktop users are more
concerned with their foreground app being peppy than they are with context
switches, but too many context switches on a Terminal Services box is a
killer for performance (and scalability).
Kevin
Bernd Harzog
CEO
RTO Software, Inc.
bernd.harzog@xxxxxxxxxxx
678-455-5506 x701
www.rtosoft.com
-----Original Message-----
From: Brian Madden [mailto:brian@xxxxxxxxxxxxxxx]
Sent: Monday, September 15, 2003 4:33 PM
T
********************************************************
This Week's Sponsor: ThinPrint
http://www.thinprint.com
**********************************************************
Useful Thin Client Computing Links are available at:
http://thethin.net/links.cfm
For Archives, to Unsubscribe, Subscribe or
set Digest or Vacation mode use the below link:
http://thethin.net/citrixlist.cfm
Other related posts:
