[THIN] Re: 64 bit experience - repost
- From: "Steve Greenberg" <steveg@xxxxxxxxxxxxxx>
- To: <thin@xxxxxxxxxxxxx>
- Date: Fri, 9 Jun 2006 15:54:56 -0700
>>The only scenario I can think of at the moment is really lame, but here
goes.
>>We've got 32 bit centipedes that can only use 4 of their legs and 64 bit
centipedes
>>that can use all of their legs. But to make the contest fair we chop off
all but 4 of
>>the 64 bit centipede's legs. Now let's race.
Tim,
That analogy is pure genius- Bravo!!
Steve Greenberg
Thin Client Computing
34522 N. Scottsdale Rd D8453
Scottsdale, AZ 85262
(602) 432-8649
www.thinclient.net
steveg@xxxxxxxxxxxxxx
_____
From: thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx] On Behalf
Of Rick Mack
Sent: Friday, June 09, 2006 3:17 PM
To: thin@xxxxxxxxxxxxx
Subject: [THIN] Re: 64 bit experience - repost
Hi Alan,
Just adding my 2 cents worth.
Early on Microsoft were fairly careful to say that x64 would scale better
only where the system bottleneck was a kernel memory restriction or
application memory restriction. Then I think marketting might have got
involved ;-)
We need to remember that in a lot of ways we've hit the wall with 32 bit
systems.
Apps keep getting bigger and need more system resources (file handles etc),
user profiles (registry memory footprint) have increased in size (unless
you're using flex profiles), virus checkers have got more aggressive (paged
pool) so the demands on kernel memory just keep increasing. There's a lot of
stuff that's been nibbling away at the system memory allocation. Faster CPUs
and main memory have also meant we desperately need more system cache so
that disk i/o operations can keep up. But we've only got 2 GB virtual
memory.
With user memory we've got all the user's 2 GB virtual application mapped
into whatever is left. The dramatic effect of DLL remapping (TScale and
APpsense Performance manager [also with working set trimming]) on system
user scalability is really telling us that the limiting performance factor
on a lot of systems is paging activiy.
And why do we have paging? It's because we've fitted a 2GB+(number of
users)x2GB memory model into 4GB of physical memory.
There's a very important criterion that has to be accepted for any
meaningful x86/x64 testing. Unless there's a lot more memory available for
x64 you've got something much worse than the 2GB+Xx2GB model because the
kernel will now use more memory (64 bit code and address space is bigger!)
causing even more paging.
If I'm running 2GB kernel+2GB Application space (per user, I know) and am
limited to 4GB total on a system, running on x64 with 4GB of RAM hasn't
changed anything significant because I'm still memory constrained and my
kernel space isn't constrained to 2GB any more. So I've actually made things
harder for applications, increased paging etc.
The only valid test of x86 vs x64 is on essentially the same hardware but
with than 4GB RAM for x64. For example, performance comparisons of the same
system with 4GB for x86 and 16 GB for x64 can start to give us some
meaningful idea of the benefits of 64bit vs 32 bit. Any comparisons of x86
and x64 on 4GB systems can't help but be fundamentally flawed.
The only scenario I can think of at the moment is really lame, but here
goes. We've got 32 bit centipedes that can only use 4 of their legs and 64
bit centipedes that can use all of their legs. But to make the contest fair
we chop off all but 4 of the 64 bit centipede's legs. Now let's race.
Addressing some of the other 32bit/64 bit issues, the appropriate use of
universal printer drivers removes most of the printer driver issues, "hard"
printers like barcode and label printers can use the x64 drivers from
www.seagullscientific.com. We've been repackaging legacy installer apps into
MSIs (or even Citrix Packager) for a while so the problem of 16 bit
installer components really doesn't matter.
16 bit apps? Gosh I'd love to get rid of the 16 bit subsystem. It's a
security and performance nightmare and it's one thing I'd love to relegate
to a silo in the back of the data center.
Will there be other issues? Of course.
It's new technology and until we get a lot of people using it, and a lot of
hotfixes/service packs, it's going to be real flakey. But then so was
Windows 200 and Windows Server 2003 32 bit.
So am I pushing it for production systems?
No. I'm not that brave/stupid. But I think we'd be pretty short-sighted not
to at least test x64 (with lot's of memory) in our delopment environments.
Vista and Longhorn aren't that far away.
regards,
Rick
Ulrich Mack
Volante Systems
_____
From: thin-bounce@xxxxxxxxxxxxx on behalf of Hutchinson, Alan
Sent: Fri 9/06/2006 23:54
To: thin@xxxxxxxxxxxxx
Subject: [THIN] Re: 64 bit experience - repost
Maybe I was understating when I said that I'm not sure I believe the
scalability figures - I should have said that not only do I not believe the
scalability figures, I never have believed these (for anything let alone
x64). That said, any further ino you have would be good - may as well
overload me brain even more.
Apart from scalability I think that the issue for me will things such as the
different add-ins for I.E. that Tim mentions, and miscellaneous drivers and
installers
Thanks to both you and Tim for your responses.
Alan.
_____
From: thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx] On Behalf
Of Andrew Wood
Sent: 09 June 2006 09:55
To: thin@xxxxxxxxxxxxx
Subject: [THIN] Re: 64 bit experience - repost
Alan,
Look hard at the performance figures - there are some instances where there
are actually *lower* numbers when migrating to x64 - I'll see if I can get
my hands on a copy of the presentation :)
_____
From: thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx] On Behalf
Of Hutchinson, Alan
Sent: 08 June 2006 17:57
To: thin@xxxxxxxxxxxxx
Subject: [THIN] Re: 64 bit experience - repost
Thanks for that Andrew - one of my motives for looking at 64 bit (apart from
the technical challenge) is that once we get an environment up and running
smoothly here we tend not to change it for a couple of years or so (except
for the usual patches and supplier software upgrades). By that time I'll be
having problems with not having gone 64 bit and virtually no experience of
it. I am resigned to running mainly 32 bits apps at the moment and have read
of the performance hit of running wow64 so I certainly won't be selling it
as a way of reducing the overall estate.
I've had a quick look at the pubforum web site and can only find "Citrix
Metaframe ala 64 bit - what does it give us"
http://www.pubforum.net/vip/PubForum_x64_Citrix.ppt#259,1,64 bit
Presentation Server
by Simon Frost from Citrix. Like you said I'm not sure I believe the
scalability figures given here either.
At the moment I'm leaning heavily towards a simultaneous 32 and 64 bit build
and see what breaks first - as I said above I'd like to get my hands dirty
with this whilst I've got the opportunity.
Thanks for your input - really useful.
Regards,
Alan.
_____
From: thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx] On Behalf
Of Andrew Wood
Sent: 08 June 2006 15:09
To: thin@xxxxxxxxxxxxx
Subject: [THIN] Re: 64 bit experience - repost
Alan,
Bernhard Tritsch did great presentation on 64 bit for TS at the last
pubforum.
iirc the findings were essentially that the 64 bit environment didn't really
offer any additional benefit at present - in fact there could be more effort
involved in being an early adopter almost without gain. Issues identified
included getting device drivers for printers, and other hardware, anti-virus
support wasn't available from all vendors. He highlighted the fact that a
lot of existing apps are going to have to run in the windows on windows
emulation to allow the fact that they're 32 bit apps. You obviously can't
have anything older - 16bit apps won't run. This wow functionality for many
apps increased resource consumption. There were issues with the fact that
they've messed around with the system32/program files directories that can
lead to some applications not working correctly and being cumbersome to
install or not working at all.
More importantly, he load tested the same desktop app suite in a 32 and 64
bit environment. While the 64 bit environment could allow more sessions to
be created the apps in those (extra) sessions did not work well and were
very unreliable. Getting a user count that was reliable meant that you were
hitting about the same user count as with win32. He showed that the testing
M$ did to get the large amount of sessions working was performed over a
large amount of time - when you tried to get many users on in a short time
the environment did not hold up as well.
I wish I had a copy of the powerpoint :( it was a very compelling argument
to sitting tight until more apps were available natively on the x64
platform.
hth
_____
From: thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx] On Behalf
Of Michael Pardee
Sent: 08 June 2006 14:37
To: thin@xxxxxxxxxxxxx
Subject: [THIN] Re: 64 bit experience - repost
very close here. As we build our new PS4 Farm I challenged the team to do
as much with the 64 bit version as possible. I think we are just rolling.
I'll report back anything we find.
On 6/8/06, Hutchinson, Alan <Alan.Hutchinson@xxxxxxxxxxxxxxxxxx> wrote:
No takers? I was hoping to provoke some discussion - either I'm way
behind the times and evrybody is using this or (and I can't believe
this) I'm slightly ahead of the game, or everybody has got one in their
labs and is keeping quiet ..........
Regards,
Alan.
-----Original Message-----
From: thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx
<mailto:thin-bounce@xxxxxxxxxxxxx> ] On
Behalf Of Hutchinson, Alan
Sent: 07 June 2006 16:17
To: thin@xxxxxxxxxxxxx
Subject: [THIN] 64 bit experience
Well, as far as I can see this hasn't been aired for a couple of months
so I'm wondering what the experience is out there. I have the
opportunity for a completely new build on a new infrastructure and am
toying with a simultaneous 32 and 64 PS server build to see how it goes.
I've seen the following :
CTX105744 - but this is dated October last year and can't immediately
see any updates to this and the only thing that puts me off under
functionality not supported is 'Oracle' without any further explanation.
KB282423 - again a few months old. The bits that concern me with this
one relate to MDAC (but on re-reading may not be an issue), and '64 bit
I.E. cannot load 32-bit ActiveX controls' - which may be the killer.
I was encouraged by Brian Maddens article
http://www.brianmadden.com/content/content.asp?id=518 about 'dropping' a
64 bit PS server into an existing 32 farm. Although long term I don't
particularly fancy running a mixed farm.
Thoughts, discussions, opinions, real experience please.
Regards,
Alan.
************************************************
For Archives, RSS, to Unsubscribe, Subscribe or
set Digest or Vacation mode use the below link:
//www.freelists.org/list/thin
************************************************
************************************************
For Archives, RSS, to Unsubscribe, Subscribe or
set Digest or Vacation mode use the below link:
//www.freelists.org/list/thin
************************************************
--
Michael Pardee
www.blindsquirrel.org
############################################################################
#########
This e-mail, including all attachments, may be confidential or privileged.
Confidentiality or privilege is not waived or lost because this e-mail has
been sent to you in error. If you are not the intended recipient any use,
disclosure or copying of this e-mail is prohibited. If you have received it
in error please notify the sender immediately by reply e-mail and destroy
all copies of this e-mail and any attachments. All liability for direct and
indirect loss arising from this e-mail and any attachments is hereby
disclaimed to the extent permitted by law.
############################################################################
#########
############################################################################
#########
This e-mail, including all attachments, may be confidential or privileged.
Confidentiality or privilege is not waived or lost because this e-mail has
been sent to you in error. If you are not the intended recipient any use,
disclosure or copying of this e-mail is prohibited. If you have received it
in error please notify the sender immediately by reply e-mail and destroy
all copies of this e-mail and any attachments. All liability for direct and
indirect loss arising from this e-mail and any attachments is hereby
disclaimed to the extent permitted by law.
############################################################################
#########
Other related posts:
