> joe, I run my desktop heavily loaded, and frequently run with > 200 to 300 windows open, and persistently run out of desktop > heap (a kernel mode resource, I've even increased this several > times), I'm greatly anticipating having a 64-bit desktop for > "whizbang GUI stuff".
Brett I would never consider you a standard user, heck most people won't hit 30 windows open at once let alone hundreds unless they accidently hit CTRL-A and Enter in explorer or outlook or something else that will launch new windows. At one point for a company I had to write a special mailslot app for receiving NET SEND messages on Win9x machines because the users would close out the Win Popup app because they didn't like seeing something they weren't immediately working on on the taskbar. It wasn't "clean" to them. I myself probably top out at about 80-90 windows and that is if I don't reboot for a couple of months and leave things open until I "get back to them" and I consider myself to be a pretty "avid" user. On the plus side, about 15-20 of those windows will be CMD Prompt but they are 9999 lines by 180 columns. The rest are a mixture of notepad, messenger, excel, IE, FF, Outlook messages, TS, VPC, VMWare, and explorer windows. At the moment, I have maybe 30 windows open but I rebooted today. I think I understand why MS wants to go to 64 bit only. But I see it simply as the tide turning from not thinking Enterprise to seemingly thinking all enterprise so they can "scale" but mostly because they have too much fat to fit in the 32 bit pants anymore for any load of any size that is carried. Even an Exchange server not doing anything can practically be falling over itself. SBS for example would do better with a lighter weight cleaner messaging environment, not one that runs better because it can now use 8GB of RAM. I recall running a time share system with dumb terminals on a machine with 1MB of RAM that served 40 people consecutively (120 total throughout the day), 16 bits, 18Mhz, and maybe 8MB of disk space. I realize that times have changed but email and calendaring and file sharing and printing all worked great, we had all of the stuff I use in Exchange, DLs, meetings, recurring meetings, etc. The one thing that Windows and the PC have encouraged is fat inefficient coding. For quite a while the processor and disk/RAM increases helped it along at the desktop but stuff hasn't moved quite as well at the server. Moving away from a desktop OS at the server and desktop type apps at the server could help, I don't know though I am just a tool writer. I am looking forward to some serious improvements with Server Core though it seems the traditionally fat apps probably won't run on it anyway because they need the strawberry shortcake and chocolate pudding and cheesecake. Exchange is slowly growing in hardware requirements to require the size of hardware it was supposed to replace when replacing big fat mini and mainframe systems but still doesn't perform as well. Note I am not saying everything from MS is like this, but I am willing to say Exchange certainly is. The only part of Exchange I can really talk about technically is the use of AD based on traces, etc and it, overall, is poor. It is getting better, but there has been and still is some pretty bad use there. I haven't had a single session of tracing Exchange traffic to AD that I didn't at some point say, WTF... There is no reason to assume that the only inefficiencies are there. While it is possible all of the bad coding is strictly in the use of AD, I would tend to not assume that. On top of that I have had some blog conversations with some Exchange Dev folks and it sounds like fat is the order for the day for the new management pieces with Monad too and they didn't seem to have an inkling of what I was trying to point out about being too fat. The bad thing is that it is one of, if not the best PC based messaging/calendaring system out there. Some people seem to mistake that for meaning it is good. Being the best doesn't make something good, it just makes it better than the other crap. I would seriously love if someone else would come out with something better, if only to make Exchange button down and work hard at being really good. Look at what FF did for IE development. Breathed whole new life into that product. On the expensive disk. I don't see people who spend the money on the expensive disk really cutting back on it just because MS say they can now with E12. The large companies still aren't going to trust the cheaper disk and will stick with configuring Exchange the way they have for some time, definitely at first, maybe less as time goes on if it proves itself out. I also don't expect people to scale up big time on E12 again at least initially, the same scaling promises came out for E2K and people put 5000 people on a server and tended to find out it wasn't a good thing unless they had very small mailboxes and nothing else going on (no DLs, no serious searching, etc). They cut back to 4000 and then 3000 and then 2000 and some all the way back into sub-1000 because of "power" users. The whole time, there is no strong identification of WHAT was puking out the perf. You might get DSACCESS counters pointing at an AD that is practically idling and two parts of MS both saying their piece (AD and Exchange) is fine by every test they know of except Exchange perf sucks. So you spend months chopping down number of users and finding any slightly different user to further subclassify users to break them out into even smaller groups. Personally, most places put up with the speed of Exchange, none seem to brag about how fast it is. I think most will welcome it going faster if it happens to beat up the disks less and you get more throughput because of less IOPS. The best thing done for the speed of Exchange in any recent times that I recall is making Outlook run in cached mode so the users don't notice the servers slobbering on themselves as often. The servers perform the same, just users are less likely to notice. I would love to see E12 be this amazing app but we can't honestly have those conversations until say about 2009 once we have sat down and started to figure out what it is doing and where it breaks at. I would have loved for E2K3 to have been that amazing app or even E2K. Mostly we have seen, let's change that and see how it works. Both in design/dev as well as daily support. Personally I don't care what they do, as long as theypick something and stick with it. I am getting a trifle annoyed with finding a bug and trying to report it and being fought with concerning it actually being a problem and then getting to the end to hear, we aren't doing that in the new version so we don't care about it anyway or to put it another way, the new version fixes everything. Overall I see 64 bit to be the new pair of pants for Exchange simply because it is too fat to fit in 32 bit pants even or maybe especially if the use is extremely light say like 10-15 users. joe -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brett Shirley Sent: Monday, November 21, 2005 12:01 PM To: [email protected] Subject: RE: [ActiveDir] Microsofts Exchange Server 12 64 bit announcement I can confirm, yes, you will only be able to deploy Exchange 12 on amd64 (well x64, i.e. including EMTWhatever) hardware. Now, I must confess something ... A bit over one and a half years ago (~Mar 2004, give or take a couple months), there was this "Focus 64" campaign, posters showed up everwhere "Focus 64 ... Shift to the power of 64-bit ... <picture of rear view mirror, with tailgating Semi-Truck with "64" on the grill, mirror reads:> Objects in mirror are closer than they appear." It was just some internal propaganda to get the development teams to be thinking and taking into consideration 64-bit ... there are always a few of these campaign's going on ... Around the same time or shortly before this Exchange was still asking if we could add PAE/AWE support to ESE like SQL. At one point, I vaguely remember yelling across the room, "PAE? PAE?!? Are you kidding me?! We have 64-bit desktops today! PAE will be mueseums in five years!" (the exact wording probably involved swear words). I also mentioned that PAE is a horrible hack, it makes me nauseous. Hack up ESE because they didn't want to port to 64-bits? Shortly after they were waffling again!! Wondering if they could just make it run as a 32-bit app on 64-bit OSs, large memory aware so they could go from the ~3GB they got today to the 3.9GB of address space a large aware app gets on a amd64 based Windows OS (that'd be a 30% increase in available memory). They could get this if they only ported the IFS driver to 64-bit, or removed it. BTW, the IFS driver is what prevents running 32-bit Exch2k3 on 64-bit OSs. 64-bit OSs require 64-bit drivers / kernel mode components. At which point I made a clarifying comment to the effect of, "No, no, I want to see 48 GBs of ESE buffer cache! Only a native 64-bit store.exe will do. Get off your ..." (perhpas I felt more swear words were necessary, I don't remember) Anyway, with all this debate on "what 64-bit support means", I just wasn't 100% convinced that Exchange was compelled enough ... So I arranged with the guy in charge of the Focus 64 campaign to reserve 50 posters for the Exchange mailbox team's floor exclusively, and one night I snuck over in the dead of night (or early early morning I think) and plastered these posters up and down the mailbox team's hall, I put 64-bit posters in thier regular reserved War team room, on the back of the dev manager's chair, and even on the back of the bathroom stall doors, just so when they're really "concentrating", they'd be thinking 64-bit. I mean what was I supposed to do <grin>!?, they were making JET Blue look bad. We've servers 1 TB worth of databases attached, and only .09 to .12% of DB buffer cache, and email is kind of weird load, kind of 4/5ths OLTP and 1/5th DSS, and well basically Exchange is _starved_ for memory today. JET had multiple 64-bit binaries (the Win2k DEC Alpha binary - Sept 1999 [last shipped in Beta 3, never made it to RTM], the ia64 binaries in Sept 2001, the amd64 binaries in Mar 2003). We had tested 64-bit Itanium DCs, with on the order of 32 GBs of RAM, to great effectiveness for huge DIT files. Anyway, I'm not going to claim my persistent nagging of the mailbox team swung the tide, I honestly think they would've come to the decision naturally on thier own (it was the only real choice). But did walking by a couple hall ways of posters make them _only_ Focus 64?? I personally don't think so, but I've confessed, so I have a clear conciousness. :) If you need someone to blame, you can blame me personally if you like ... Overall ... I'm quite happy, the Exchange team stepped up to the plate, and is going to release IMO, the killer 64-bit app. They deserve accolades. There are actuallly several details besides this one that make an inplace upgrade a more difficult thing to do/support, and together these details embolden the forced migration option. If you read the notes from people at the IT Forum close enough, I saw at least 2 of the other reasons that increase the difficulty of doing in place upgrades. We rigorously debate these things, there are more aspects to the decision than has been mentioned so far. joe, I run my desktop heavily loaded, and frequently run with 200 to 300 windows open, and persistently run out of desktop heap (a kernel mode resource, I've even increased this several times), I'm greatly anticipating having a 64-bit desktop for "whizbang GUI stuff". I had some comments on the cost debate, but I'll put that on another fork of the thread ... Cheers, BrettSh [msft] ESE Developer This posting is provided "AS IS" with no warranties, and confers no rights. On Wed, 16 Nov 2005, Rich Milburn wrote: > Makes me wonder if MS is not betting at least some of the farm on the quick 64 bit transition that Gates is certain is going to happen. If anyone has the potential to influence that switch, MS has got it. The switch to 32 bit was overdue, so everyone realized the benefits and it happened fast. But we've currently got a memory model that will allow us to quite comfortably handle reading parts of programs and files and caching to disk - even though it's common knowledge that caching to disk, or reading the next parts of files, is a huge speed bottleneck. Memory price was a barrier before - who could afford 1GB of RAM?? But that barrier is diminishing, when you can buy a fully functional PC for a couple/few hundred bucks. What if I did editing, or ran some kind of server software, that could load itself, or its working space, or its database, entirely into memory?? With a 3GB per app current limit, it doesn't happen now, so it's hard to imagine what kind of functionality could be possible in that model. The question I'm curious about is what is Microsoft's reasoning behind doing it - is it because they are too lazy to program 2 platforms, because they are too lazy to write efficient code, or because there is a feature set they want to use that is only possible with the extended memory space? There are a lot of applications (uses) that are pretty tough to tackle because of the datasets they require (i.e. genetic algorithms/neural networking/predictive analysis) but those might become more commonplace with the address space to handle them - with multiple processors yes but also with a TB limit on physical RAM. > > Does all that help me read my list mail better? Probably not. At > least not until I can set up rules that can research questions for me > automatically and present me with a proven response I can sign and > click send :) > > Rich > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of joe > Sent: Wednesday, November 16, 2005 11:47 AM > To: [email protected] > Subject: RE: [ActiveDir] Microsofts Exchange Server 12 64 bit > announcement > > The first thing I thought of when I read the announcement that it was > to test the waters and MS would recall it as a "the person spoke out of turn". > Then I heard it was Muglia which shored it up quite bit. Now I am > hearing more in dept info from various places and fully believe that > MS is definitely intending to do this. > > Regardless of what MS or Intel or AMD does, I am not so sure I expect > the death of 32 bit machines any time soon. They will just go to more > lower end uses than running a big bad GUI OS. Even if AMD and Intel > drop production completely, I expect you will see some Chinese/Korean > Chip manufacturer cranking them out. If at the same price or the 32 > bit was cheaper I would take the MP 32 bit system over a single processor 64 bit for a home system. > I previously bought the 64 bit system to do some eventual testing > versus thinking it was going to be so much better. I like 64 bit so > much I am running a 32 bit OS on it. ;o) I expect at some point > someone will complain that I need to make my tools 64 bit. I don't > expect it to happen whole hog or probably even at all for quite some time. > > Without all of the whizbang GUI stuff, 32 bit is quite fine for many > many many and let me just say probably most applications. It would be > for even longer though the push is to go 64 bit because some apps have > hit ceilings in easy use of the memory they need. 64 bit is about > memory and available address space for resource allocation, etc. There > are extended memory schemes available for 32 bit just like there were > for 16 bit and 8 bit. They are a pain to code around though and no one > likes to do it. When we go to > 128 bit procs it will be the same issue, the apps are too fat to > easily fit in the memory space we have available at the time. I > wouldn't even be close to being stupid enough to say we won't ever need 128 bit... > > Who was it that allegedly said "640KB ought to enough for anybody."? > > > For pure speed, multiprocessing, not 64 bit, is where we are and need > to be going. That also requires extensive work in the coding side of > things because code not properly written for MP purposes can perform > very badly in MP machines. This involved coding techniqus and smart > compilers that can generate good MP code. I have seen some in house > apps in previous jobs that failed in a stellar fashion once loaded > onto production MP servers while the test environment was entirely > single processor. I expect there are folks in software companies who > have experienced the same with their apps. I also expect we will have > fun with some 32 bit apps that perform in quite unique ways under 64 > bit. Shouldn't happen, but lots of things that shouldn't happen, do. > That is just the way this stuff works or else we would all be out of jobs. > > > joe > > > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > [EMAIL PROTECTED] > Sent: Wednesday, November 16, 2005 12:19 AM > To: [email protected] > Subject: RE: [ActiveDir] Microsofts Exchange Server 12 64 bit > announcement > > I agree with you. This is one stupid [1] business decision that will > ultimately hurt E12 adoption. We reached the plateau of 5.5 to E2K3 > mass migration a long time ago. Most people still on 5.5 are waiting > to see "the Next Thing" and we can't seem to move them from their standoffish position. > Erecting a roadblock at this point (in the name of 64-bit innovation) > will create a huge disincentive to the adoption of this "Next Thing". > The customers have enough reason to not want to adopt new technologies > "just because......". Now MS is giving them more ammunition to not even bother. > > I do not know what this was predicated on. Perhaps MS is going to > pressure the OEM into abandoning 32-bit machines. Perhaps they will > succeed, perhaps not. My hope is that this is merely a feeler from MS > to gauge the industry's reaction to the plan. I am guessing somewhere > in someone's back pocket is a card that reads "Hehehe....just > kidding". If those guesses are wrong, then let me hazard one more > guess - MS is not REALLY interested in getting a lot of people onto > E12 because E12 is just a transitional platform (like WinME) and will be abandoned as soon as it escapes from the Redmond lab. > > OK, maybe I'm seriously wrong on all my guesses. In which case, I > would have to conclude that someone somewhere is seriously deluded. I > don't see a lot of customers clamoring for 64-bit. Not yesterday, not > today, and 95% of the clients I interface with don't have it in their > 2-year plans. Drawing an imaginary line and proclaiming "64-bit or > die" will only lead to one outcome > - a premature death for all the hard work so far invested in E12. In > the absence of death, MS will surely run into the adoption roadblock > [2] they are currently contending with in the XP space - people see no > need to move off of Win2K (thank you very much), especially now that > Vista is looming large. > > [1] I guess one of the perks of being a partial observer is being able > to call MS decisions "stupid" > [2] Unlike a lot of people, I get paid to push MS technologies, so I > have a vested interested in getting maximum adoptions. > > > Sincerely, > > Dèjì Akómöláfé, MCSE+M MCSA+M MCT > Microsoft MVP - Directory Services > www.readymaids.com - we know IT > www.akomolafe.com > Do you now realize that Today is the Tomorrow you were worried about > Yesterday? -anon > > ________________________________ > > From: [EMAIL PROTECTED] on behalf of joe > Sent: Tue 11/15/2005 6:21 PM > To: [email protected] > Subject: RE: [ActiveDir] Microsofts Exchange Server 12 64 bit > announcement > > > > They aren't dropping backwards compatability, they are dropping a > platform, this isn't going to clean up security issues or remove some > nasty functional problem. It is sort of like they dropped the Alpha > and the PowerPC. They just aren't doing it whole hog for the OS yet. > You still hear occasional complaints about those being dropped though > you hear a lot more of "what are those platforms". > > It is easier to utilize more memory on 64 bit than on 32 bit. Exchange > Dev must feel that a lot of their problems will go away going to 64 > bit so that is the decision. Maybe it is true, I think good coding and > design decisions would go a long way in solving a lot of the problems > as well, probably help considerably more in fact. 64 bit wouldn't have > helped the DSACCESS problems, it wouldn't have fixed the security design and AD integration. > Wouldn't help 9548. Etc. Plus just going 64 bit isn't going to fix > much of anything I don't think. You start getting "fixes" since they > are able to use the more and more memory that you throw at it without > having to use the complicated memory management mechanisms in 32 bit. > Some might call that covering up the issues versus fixing them. :o) > > Windows sucks because it is slow and bloated, oh just buy > bigger/faster hardware and you are fine... If you can get an older > version of Windows to run on your newer hardware, try it. It can be > amazing how fast it is. The hardware companies instead of bitching at > MS should be paying them dividends and praising them for driving the hardware industry. > > Plus we need the faster bigger memory machines, more stuff is going .NET.... > > > joe > > > ;o) > > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Susan > Bradley, CPA aka Ebitz - SBS Rocks [MVP] > Sent: Tuesday, November 15, 2005 8:37 PM > To: [email protected] > Subject: Re: [ActiveDir] Microsofts Exchange Server 12 64 bit > announcement > > We got SBS 2003 6 months after Windows 2003. > > We don't even have Vista yet folks... how relatively short is short to > you guys? > > Vista is possibly Christmas 2006 yes? Server after that...remember > we're just now getting R2 in late 2005, we'll hit Longhorn in 2007.... > SBS after that. > > I find this thread kinda funny... Security folks have argued for MS to > drop backwards compatibility... Mac's did after all....to get better security. > So here they are dropping backwards compatibility for the benefits of > 64 bit, right? And look at us.... it's business side talking again, isn't it? > > More small firms are leasing or buying over time. More small firms > are looking into hosted solutions...we're tired of the patch it and break it. > > 2003 is solid..unlike NT and yet look at the NT still deployed.. And > when that compelling story of why a business should upgrade occurs > because of the productivity gains... I'll bet that will push folks. > > Hopefully then we can finally rip out all the lanman stuff...ya think? > > Do they need to get the migration documentation, guidance ready to > go...yeah ...that they need to do. > > Tomasz Onyszko wrote: > > joe wrote: > >> I don't believe Exchange 12 is waiting for Longhorn. > >> > >> Also SBS Longhorn is in the scope due to Exchange 12. > > > > Yes, You are right - I just replied to Your post where you mentioned > > specific about longhorn. I don't feel very well with this > > announcement too. I'm not sure if it is good step especially with > > exchange 12 which will be released in relatively short time. > > > > > > -- > Letting your vendors set your risk analysis these days? > http://www.threatcode.com > > List info : http://www.activedir.org/List.aspx > List FAQ : http://www.activedir.org/ListFAQ.aspx > List archive: > http://www.mail-archive.com/activedir%40mail.activedir.org/ > > List info : http://www.activedir.org/List.aspx > List FAQ : http://www.activedir.org/ListFAQ.aspx > List archive: > http://www.mail-archive.com/activedir%40mail.activedir.org/ > > > List info : http://www.activedir.org/List.aspx > List FAQ : http://www.activedir.org/ListFAQ.aspx > List archive: > http://www.mail-archive.com/activedir%40mail.activedir.org/ > > List info : http://www.activedir.org/List.aspx > List FAQ : http://www.activedir.org/ListFAQ.aspx > List archive: > http://www.mail-archive.com/activedir%40mail.activedir.org/ > > -------APPLEBEE'S INTERNATIONAL, INC. CONFIDENTIALITY NOTICE------- > PRIVILEGED / CONFIDENTIAL INFORMATION may be contained in this message or any attachments. > This information is strictly confidential and may be subject to > attorney-client privilege. This message is intended only for the use > of the named addressee. If you are not the intended recipient of this > message, unauthorized forwarding, printing, copying, distribution, or > using such information is strictly prohibited and may be unlawful. If > you have received this in error, you should kindly notify the sender by reply e-mail and immediately destroy this message. > Unauthorized interception of this e-mail is a violation of federal criminal law. > Applebee's International, Inc. reserves the right to monitor and > review the content of all messages sent to and from this e-mail > address. Messages sent to or from this e-mail address may be stored on the Applebee's International, Inc. > e-mail system. > List info : http://www.activedir.org/List.aspx > List FAQ : http://www.activedir.org/ListFAQ.aspx > List archive: > http://www.mail-archive.com/activedir%40mail.activedir.org/ > List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
