Rick, Is there a way to set processor affinity so that I/O requests use a physical CPU versus a logical one? Wouldn't that produce the best of both worlds where I/O has a physical processor to use and users have their processes spread out in a more even and consistent way? Steve Greenberg Thin Client Computing 34522 N. Scottsdale Rd. suite D8453 Scottsdale, AZ 85262 (602) 432-8649 (602) 296-0411 fax steveg@xxxxxxxxxxxxxx -----Original Message----- From: thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx] On Behalf Of Mack, Rick Sent: Sunday, September 21, 2003 6:43 PM To: 'thin@xxxxxxxxxxxxx' Cc: 'rashid.mohammed@xxxxxxxxxxxxxxx' Subject: [THIN] Hyperthreading and effect on network i/o Hi People, I've been having some ongoing fun on one of our sites where 2003 servers are hanging, luckily infrequently, when a bunch of users are logging on. We've found quite a few things that needed sorting out including tuning a back-end file/print cluster that have improved things markedly. Nevertheless, we've been monitoring and playing with just about everything to try and get a handle on the hangs. This has included debug dumps to Microsoft, Citrix etc. All that aside, one very interesting thing did crop up. We have a total of 8 new IBM X-series model 335 systems, (and a bunch of older systems as well) running Windows server 2003. These new systems support hyperthreading and in an attempt to deal with the hangs, one of the things we did was to disable hyperthreading on a couple of the 335s. Since we had a suspicion that the hangs could be network i/o related, one of the things (amongst many!) that we've been monitoring is the local redirector (redirector > current commands). The 2 systems with hyperthreading disabled were consistently running with a current commands queue length that was 50%-60% of that is seen on the systems with hyprthreading enabled. Stated simply, the redirector's pending i/o request queue length (current commands) was much shorter on non-hyperthreaded systems compared to hyperthreaded systems with the same application and user load. The non-hyperthreaded systems were handling network i/o requests more efficiently Now this kind of makes sense in a scenario where a single-threaded NIC driver latches on to a logical CPU rather than a physical CPU. Certainly, a logical CPU is going to have less resources available than a physical CPU in terms of interrupt handling capability. This observation, if it's real, has some interesting ramifications if the effect of hyperthreading benefits cpu intensive processes at the expense of i/o intensive processes. Do I really want my file/print servers to go slower than they could? I guess the bottom line for me is that I'm going to be very cautious about recommending or using hyperthreading on our TS or file/print systems for a while until the effect of hyperthreading on i/o has been clarified. Terminal server systems are way too dependent on network i/o responsiveness for their good health for me to risk anything screwing up the works. regards, Rick Ulrich Mack rmack@xxxxxxxxxxxxxx Volante Systems 18 Heussler Terrace Milton 4064 Queensland, Australia tel +61 7 32467704 ---------------------------------------------------------------------------- ---------------------------------------- The information contained in this e-mail is confidential and may be subject to legal professional privilege. It is intended solely for the addressee. If you receive this e-mail by mistake please promptly inform us by reply e-mail and then delete the e-mail and destroy any printed copy. You must not disclose or use in any way the information in the e-mail. There is no warranty that this email or any attachment or message is error or virus free. It may be a private communication, and if so, does not represent the views of Volante group Limited.