[THIN] Re: Hyperthreading and effect on network i/o
- From: Jarred Hogan <jarred@xxxxxxxxx>
- To: thin@xxxxxxxxxxxxx
- Date: Tue, 23 Sep 2003 08:56:59 +1200
We had problems with the 335s NIC Drivers that came packaged with the
Servers for Win2k.not 2003 though..downloading latest driver fixed fault.
which was that it took about 19 secs to copy a 20meg file from one to the
other.
Jarred
-----Original Message-----
From: thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx] On Behalf
Of Timothy Mangan
Sent: Tuesday, 23 September 2003 6:30 a.m.
To: thin@xxxxxxxxxxxxx
Subject: [THIN] Re: Hyperthreading and effect on network i/o
I took a quick look at a Dell server here with Intel Pro/1000 MT NIC and
Hyper-Threading. No unusual behavior in monitoring the card and the
redirector. I do seem to recall that the Intel card had a new 2003 driver.
So it may be NIC driver related.
tim
-----Original Message-----
From: thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx] On Behalf
Of Ron Oglesby
Sent: Monday, September 22, 2003 9:31 AM
To: thin@xxxxxxxxxxxxx
Subject: [THIN] Re: Hyperthreading and effect on network i/o
That is interesting since you mentioned it. I have a couple of 2003 servers
available and will disable HyperThreading on one of them to see if your
theory holds true across other hardware.
My concern is that while Ii/o may increase does that means its bad. well it
depends on how much it increases and if that increase creates a bottle neck.
IE someone with apps that do a lot locally (like office) and not so much
remote traffic (backend DB) may not ever run into that bottle neck.
Also we have to take into account whether this is specific to a certain
system./hardware or driver types.
Anyway, Will be interesting to look at. Have some tests going now.
Ron Oglesby
Senior Technical Architect
RapidApp
Office 312.372.7188
Mobile 815.325.7618
email roglesby@xxxxxxxxxxxx
-----Original Message-----
From: Timothy Mangan [mailto:tmangan@xxxxxxxxxxxx]
Sent: Monday, September 22, 2003 6:47 AM
To: thin@xxxxxxxxxxxxx
Subject: [THIN] Re: Hyperthreading and effect on network i/o
Rick,
Sounds like an interesting catch. If so, it should be specific to the
driver (although code is likely shared within the NIC manufacturer). What
NIC(s) was/were the problem?
tim
-----Original Message-----
From: thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx] On Behalf
Of Mack, Rick
Sent: Sunday, September 21, 2003 9: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.
Other related posts:
