[THIN] Re: Hyperthreading and effect on network i/o
- From: "Braebaum, Neil" <Neil.Braebaum@xxxxxxxxxxxxxxxxx>
- To: <thin@xxxxxxxxxxxxx>
- Date: Mon, 22 Sep 2003 09:56:47 +0100
Processor affinity is only of real use, if you can either:-
a) Write the code yourself - if it's a NIC driver or some other driver
level code, this may not be an option - only truly an option if it's a
home-grown app.
b) Use something like process control or job objects to manage these
things on the server(s).
Otherwise, it's largely a mildly interesting manual tweak, that won't
survive a reboot or any other additional instance.
Neil
PS: Rick - useful info, once again, thanks for keeping the list informed
of your findings.
-----Original Message-----
From: Steve Greenberg [mailto:steveg@xxxxxxxxxxxxxx]
Sent: 22 September 2003 02:56
To: thin@xxxxxxxxxxxxx
Subject: [THIN] Re: Hyperthreading and effect on network i/o
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
***********************************************
This e-mail and its attachments are confidential
and are intended for the above named recipient
only. If this has come to you in error, please
notify the sender immediately and delete this
e-mail from your system.
You must take no action based on this, nor must
you copy or disclose it or any part of its contents
to any person or organisation.
Statements and opinions contained in this email may
not necessarily represent those of Littlewoods.
Please note that e-mail communications may be monitored.
The registered office of Littlewoods Limited and its
subsidiaries is 100 Old Hall Street, Liverpool, L70 1AB.
Registered number of Littlewoods Limited is 262152.
************************************************
Other related posts:
