A few answers... 1) I have done quite a bit of testing on 2003. My recommendation for enabling the boost (foreground mode) on terminal servers applies to both operating systems (but see #4 below). 2) 2003 works just like 2000 in regard to quanta/priority boost. Both have the same registry setting you can use directly to tweak your server, however, the basic fore/background control for the server sets the registry value to the best settings for any situation. 3) Quanta is less important than the priority boost associated with fore/back ground (unless you have the kind of applications that consume an entire CPU). I have personally tested and shown that each TS session receives the foreground boost for their foreground window thread. 4) The difference on this one setting is quite small, and addresses the underlying problem in the wrong way. In the end, it's not very important (but it is ever so slightly better to use foreground mode). To address perceived performance, one must take a more comprehensive approach to application control. There are several vendors that do this (I would recommend triCerat's, but then I might be biased). Tim Mangan Founder, TMurgent Technologies -----Original Message----- From: thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx] On Behalf Of Lilley, Brian Sent: Tuesday, September 28, 2004 12:20 PM To: 'thin@xxxxxxxxxxxxx' Subject: [THIN] that question again... performance settings for perceived perform ance... ok, firstly I apologise for bringing this up again, but I never got to the bottom of this one... Right.. Windows 2000 had a peformance setting which (according to Microsoft documentation), affected thread quanta and priority boost. Supposedly, if the windows 2000 server was set to foreground, a foreground thread would get 9 (some docs say 6!) quanta and a background thread would get 3 and that the threads priority is boosted. Microsoft claims that all terminal server sessions are affected by this setting, i.e. each session has foreground tasks for the UI and any arbitrary background tasks as instantiated by the users session. Ok, the Microsoft documentation makes sense, all users have foreground thread and background threads, the multiple user sessions' foreground threads will each get 6 quanta and their respective background tasks will only get 3 quanta ... so the 'Foreground applications' setting seems like the appropriate setting for the terminal server... Not so, say a number of the leading thin client community, claiming that only the console session is regarded as a foreground thread and so all terminal services sessions are regarded as background threads, and so, if the 'Foreground processes' setting is chosen, then all term server sessions will get only 3 quanta and we will have masses of context switching...because 3 quanta is too short?? and then......the Perceived Performance methodology states that perhaps the additional 'minimal' overhead of context switching on modern hardware is worth the effort for producing, not necessarily max capacity computing but certainly much 'smoother' gui experience for multi-users on an MS terminal server... Ok, so now I am still none the wiser for win2000, my question to the community is, have Microsoft reengineered this for win2003? What should the settings be for 1. 'Programs over background services' and 2. 'allocating memory for programs over system cache?' I understand that the beta version of 2003 provided configurable quanta settings? has anyone any testing results? has anyone uncovered any Microsoft documents recommending the settings for Term Servers or should I just find better things to do with my time? Like Brian Madden said, does this really make a difference in the real world? So, all I want to know is, for Windows Office apps on a Windows terminal server... can't someone just tell me what the setting should be... thaBrianos ============================================================================ == This message is for the sole use of the intended recipient. If you received this message in error please delete it and notify us. If this message was misdirected, CSFB does not waive any confidentiality or privilege. CSFB retains and monitors electronic communications sent through its network. Instructions transmitted over this system are not binding on CSFB until they are confirmed by us. Message transmission is not guaranteed to be secure. ============================================================================ == ******************************************************** This Weeks Sponsor RTO Software Do you know which applications are abusing your CPU and memory? Would you like to learn? -- Free for a limited time! Get the RTO Performance Analyzer to quickly learn the applications, users, and time of day possible problems exist. http://www.rtosoft.com/enter.asp?id=320 ********************************************************** Useful Thin Client Computing Links are available at: http://thin.net/links.cfm *********************************************************** For Archives, to Unsubscribe, Subscribe or set Digest or Vacation mode use the below link: http://thin.net/citrixlist.cfm ******************************************************** This Weeks Sponsor RTO Software Do you know which applications are abusing your CPU and memory? Would you like to learn? -- Free for a limited time! Get the RTO Performance Analyzer to quickly learn the applications, users, and time of day possible problems exist. http://www.rtosoft.com/enter.asp?id=320 ********************************************************** Useful Thin Client Computing Links are available at: http://thin.net/links.cfm *********************************************************** For Archives, to Unsubscribe, Subscribe or set Digest or Vacation mode use the below link: http://thin.net/citrixlist.cfm