The company I work for makes IC testing equipment, and we have a few prototype Itaniums around. From what I've seen, the Merced is going to suck, but the McKinley will be much better.
BTW, both chips need 125 amps just to get a return signal! Better break out those fire extinguishers.
The package for the Merced looks sort of like a P2/P3 SEC cartridge, except it doesn't have an single-edge connector. It has a traditional PGA coming out the side (well, bottom, really). The PGA isn't much larger than the PGA for a Socket 370, but the socket itself has a surface area similar to a P2/P3 SEC cartridge laying on its side.
Much of the difference in surface area of the PGA connector and socket is due to the truck load of L2 cache on the PCB with the processor.
I doubt this is really a loss leader for MS, as they do very little training themselves. I have taken technical courses covering products from MS, HP, Sun, and Oracle, and they all charge ~US$2000 for a one-week course (give or take $200). Microsoft rarely teaches their own courses, as they usually license other, smaller companies and individuals to provide that training.
Microsoft *does* hold classes, but these are usually right before a product launch to seed some trainers so there will be someone around to train everyone else.
Of course, these smaller training organizations aren't exactly losing money, either. A contract instructor flown in from out-of-state to teach for five days may cost $3000-to-$6000, but a class of twelve students at $2000 per head still leaves one with a pretty hefty profit. Of course, office space, computers, and a competent sales staff aren't cheap, but that overhead is certainly bearable with each classroom pulling in $18,000 per week!
BTW, you don't need to take MS courses to get MS-certified, and you don't need to take Sun courses to get Sun-certified: you just need to pass the associated tests (at $100 or more per test), and the only company that profits from this is Sylvan Prometric.
Given that so many companies other than MS charge $2000 for these classes, for Red Hat to charge $5000 does not seem defensible.
I don't know about calcium, but vitamin C is safe to consume *far* in excess of USRDA recommendations. The USRDA of C is 60mg, and I consume 2000mg everyday with no ill effects. Linus Pauling (incidentally, Mr. Torvalds was named after him) was a Nobel Prize-winning researcher who consumed/recommended 16000mg daily (in four equal doses of 4000mg powdered C mixed in a glass of water).
"Well, well, well. Less than twenty-four hours 'til Ragnarok and I haven't a stitch to wear."
Billions of people around the globe are thinking this very thought. Don't be part of the mass of cannon fodder awaiting their fate on January 1st. I'd like to help others survive and prosper after the Y2K "situation" by describing the preparations I've made over the past year for tonight's Big Event.
1. The Car Nothing says "I'm a survivor!" like a cool set of wheels, which is why I have a 1971 Plymouth HemiCuda with a 426ci/425hp V8. I took out the rear window and rear seats, and welded in two 55-gallon drums as reserve fuel tanks. I filled the trunk with cement so I could ram other vehicles in reverse during "Road Warrior"-type scenarios. Due to the weight of the cement in the trunk, I had to replace the rear shocks with solid steel bars, so the suspension is pretty stiff, but boy does it have some range! I've mounted a 20mm cannon (originally from a AH-1 Cobra helicopter) - that I bought on eBay for $35K - to the roof of the car so it faces forward. It fires when the left turn signal is activated. I use a Xybernaut wearable PC for aiming, and I adapted the anti-wobble feature of my camcorder to stabilize the cannon during vehicle movement and firing. There is a radiacmeter attached to the grill, so I'll know when I'm approaching former urban areas. I didn't have time to cut a hole in the hood to accommodate the huge intake of the supercharger attached to the engine, so I just left the hood off. The exhaust system has been removed as a vestigial performance-hindering remnant of a civilized era.
2. The Duds I have a fire-resistant Nomex jumpsuit dyed to match desert terrain, as all terrain will soon be desert terrain. For formal occasions, black leather chaps are acceptable, but the buttless kind will make you the laughing-stock of Bartertown. Accessorize with low-slung pistol holster, gas mask, and black leather jackboots. Bandoleers are in this year, but only for survivors with crew-served weapons. Fine-grain leather driving gloves will assist you in controlling your vehicle when driving through fallout-blighted areas.
3. Food Pound-for-pound, dry dog food has ten times the nutritional value of boiled potatoes, and it can be stored longer, too! Dog food for older dogs is often packed with fillers that you just don't need, but Puppy Chow is geared towards growing dogs, and has more than enough nutrition. I'm towing a U-Haul trailer full of it, with a few cases of surplus MREs from the Gulf War for special occasions.
I hope I've provided some insight into the preparations necessary for surviving the coming hard times. I am interested in having a traveling companion to help with driving. Any fertile females interested in repopulating the planet should contact me at TheSurvivor@militia.mt.us
Actually, Compaq and other vendors will be shipping systems with Win2K installed next month, as stated in this article. Also, so-called "golden code" (not beta) CDs are available now to members of the early adopter program for Win2K... so it has been released.
Well, lack of bandwidth is not really an issue in our network. Further, I am not trying to convince anyone that what I am doing in my environment would work best for them. I am simply stating that it works for us.
Running H.323 over HTTP isn't a decision that we made because we were trying to preserve bandwidth. It was a compromise to allow videoconferencing through our firewall. Maintaining two different configuration settings for the client program (one for Internet, one for LAN) would probably cause additional helpdesk calls, so we chose a one-size-fits-all approach. No one on our LAN is complaining about a slow network.
Further, we chose to use HTTP-DAV because is integrates well with our vision of having a web-based information resource for the company. The end-users are familiar with the point-and-click interface, and they don't have to learn any cryptic commands or switch amongst different apps to do their jobs. We do not expect our accountants, receptionists, machinists, and salespersons to become computer power users when there is an easier way for them to access the information they need to do their work.
If we have to sacrifice some bandwidth to make this happen, so what? I'm probably using the wrong octane-level of gas in my car, but my mechanic doesn't flame me for it.
Maybe you should find someone who will be able to setup things in your company properly then!?
Thanks for the suggestion, AC! I'll bring this up at our next staff meeting. Neither I nor the end-users were aware that the network was malfunctioning, as our applications deceptively behave as though nothing is wrong, but I'll forward your comments to them.
If you kill your own bandwidth (be it Gigabit or whatever) by making 100gb downloads, don't blame web server for not 'serving' the requests
Actually, our bandwidth isn't getting killed. We have an excess of it. Our end-users are happy.
I appreciate your enthusiastic and - dare I say it - emotional response to my network's configuration, but I wasn't posting to point out some flaw or error that needs correcting. I was simply stating that web servers that are capable of dishing out content in excess of T3 speeds aren't as exotic as some people may think, since many web servers are used to deliver content over a LAN at Ethernet speeds.
If the few posters who think I am insane or stupid because file transfers are generally done over HTTP in my network want to hear me admit that HTTP might not be the most efficient protocol for this kind of thing, so be it! HTTP is not a very bandwidth-efficient means of file transfer.
However, the excess of bandwidth in our LAN means that we can afford to waste a little bandwidth. The LAN has been over-engineered with scalability in mind. Further, the nature of the clients' use of the network (i.e. as much as possible is done with the web browser) makes file transfer over HTTP the easiest way to do it.
Well, I sure don't use ZD articles as a shopping tool. When I am looking for solutions for uncommon problems, I often ask my friends at the consulting firm where I used to work what has worked for them. I also ask my hardware vendors for advice, but that has to be taken with a grain of salt since they're usually just trying to sell the most expensive solution. I also use AltaVista to search for text strings like "enterprise document management" or "PDF automation". Sure, I have to put up with "2,102,893 matches found, displaying results 1 - 10", but I find some pretty off-the-wall stuff that way
For more mundance solutions, I usually stick with what I know works. I'm a little surprised that HP didn't send me a Christmas card this year, as we buy a whole lot of their products. All the Intel-based servers are HP NetServers, the workstations are HP Kayaks, and the low-end clients are *cheap* and reliable HP Vectras. It doesn't hurt that the CEO and COO are both technophiles, and have realized the productivity gains of their employees as our IT infrastructure has grown.
One of the reasons I've pushed to make everything web-based is to create some level of platform independence. We have a huge number of Word, Excel, and PowerPoint files on our network, so for the time being everyone needs MS-Office, and thus, Windows, but at least there are packages out there with import/export tools for MS-Office, such as StarOffice and ApplixWare. What is more insidious are the client/server applications that will probably never get ported outside of Windows. By pushing the web-centric option, we leave open the possibility of making an alternative OS the primary desktop.
The engineers will probably never be able to leave NT, as AutoCAD, SolidWorks, and Pro/Engineer would all have to offer UNIX versions of their product to make that switch, but virtually everyone else in the company could someday be moved.
(Sliding even further off-topic) I certainly understand your apprehension at putting all functions on one box... when I first started working for my employer about two years ago (then as a consultant) it was a 100% Microsoft shop with everything running on three NT servers cobbled together from parts someone probably bought at Fry's.
I've finally managed to offload some core network functions to Solaris and BSD boxes, and got rid of that awful MS-Proxy Server, but it looks like NT is here to stay for inhouse messaging and such. At least the NT boxes are on better hardware now.
As far as configuring the firewalls go, well, our super-spooky network security guru has developed a model of "ultra-paranoid double redundancy" which makes changes unsanctioned by him impossible, so port 80 it is.
Perhaps I should provide a few more details about our network, so I can justify the the design decisions that went into it.
We have about 250GB - in about 200,000 files - available on four servers. At this point, having a cleverly designed directory structure is no longer a viable solution for organizing our documents across the enterprise, and an additional layer of abstraction is needed so users can locate the files they need. Enterprise Document Management Systems are applications that usually sit on top of an RDBMS and allow search, check-in check-out, version control, and other features beyond what a file server can do. Since we already have an Oracle ERP solution installed here, we went with their EDMS product, but there are certainly others available (most notably from Xerox and Eastman-Kodak, although recently I've wondered how suitable CVS would be for such a task).
By the way, I think the biggest CAD file I found on our servers was ~400MB, and it was a Pro/Engineer drawing of a component that could fit in the palm of your hand. After a six-month campaign of trying to ration disk usage by our employees, only to be voted down by higher-ups, I have resigned myself to the fact that I will be adding disk storage to these servers forever. Network Appliance is starting to look real good...
The concept is called "protocol encapsulation." As in H.323 videoconferencing protocol over HTTP. Since we also must do videoconferencing with our customers, we need a configuration that works over the Internet as well as the LAN, and our firewalls are configured such that HTTP is the viable solution.
As for file transfers, HTTP-DAV is nice because it allows totally clueless end-users to post documents via the web browser, rather than use some other application to handle file transfer. Since they are already using the browser as the interface for just about everything else, allowing them to post documents via the browser reduces end-user training requirements.
I'm not certain what you mean by using protocols that actually suit what I'm doing, as these two protocols (H.323, HTTP-DAV) are being used exactly as the designers intended.
If you have only 200 users, how are you going to be generating that kind of load?
By uploading and downloading multi-hundred megabyte CAD drawings and other such bandwidth consuming activity - such as video conferencing - over HTTP. Or by being in a much larger company with a similar, high-bandwidth infrastructure.
My point is that the firm I work for only has 200 users, yet we have more than enough bandwidth to saturate the web servers tested in the benchmark. There must be many companies with larger user bases that are capable of generating this kind of traffic over the LAN, without being eBay or a huge ISP. Not all web servers publish over the Internet, many publish over an intranet.
Our company may not be able to afford a T3, but we don't need one if the client is in the same building, capiche? Good. Such performance issues are relevant to more people than the poster three levels up described.
Re:"Webbench" of 600 or 4000 - It Just Doesn't Mat
on
Web Server Comparisons
·
· Score: 1
The best are maxing out multiple 10Mbps Ethernet cards - i.e. you need a T3 line to actually provide the bandwidth you're serving.
Without addressing the issue of whether *this* benchmark is valid, what if you are providing web services over a local intranet with a gigabit backbone and most clients on switched-100? What if that web server was the web interface for a heavily-used ERP application, or a Product Data Management solution over HTTP-DAV? Wouldn't the web server that was able to perform at the high-end matter in this case?
You don't need to be a big ISP or an eBay to make use of such bandwidth - if it's local. This scenario describes the company I work for, and we have only ~200 employees.
Slashdot Mirror
The company I work for makes IC testing equipment, and we have a few prototype Itaniums around. From what I've seen, the Merced is going to suck, but the McKinley will be much better.
BTW, both chips need 125 amps just to get a return signal! Better break out those fire extinguishers.
The package for the Merced looks sort of like a P2/P3 SEC cartridge, except it doesn't have an single-edge connector. It has a traditional PGA coming out the side (well, bottom, really). The PGA isn't much larger than the PGA for a Socket 370, but the socket itself has a surface area similar to a P2/P3 SEC cartridge laying on its side.
Much of the difference in surface area of the PGA connector and socket is due to the truck load of L2 cache on the PCB with the processor.
... a Beowulf cluster of Steve Gutenbergs competing in the synchronized swimming event at the Olympics?
I doubt this is really a loss leader for MS, as they do very little training themselves. I have taken technical courses covering products from MS, HP, Sun, and Oracle, and they all charge ~US$2000 for a one-week course (give or take $200). Microsoft rarely teaches their own courses, as they usually license other, smaller companies and individuals to provide that training.
Microsoft *does* hold classes, but these are usually right before a product launch to seed some trainers so there will be someone around to train everyone else.
Of course, these smaller training organizations aren't exactly losing money, either. A contract instructor flown in from out-of-state to teach for five days may cost $3000-to-$6000, but a class of twelve students at $2000 per head still leaves one with a pretty hefty profit. Of course, office space, computers, and a competent sales staff aren't cheap, but that overhead is certainly bearable with each classroom pulling in $18,000 per week!
BTW, you don't need to take MS courses to get MS-certified, and you don't need to take Sun courses to get Sun-certified: you just need to pass the associated tests (at $100 or more per test), and the only company that profits from this is Sylvan Prometric.
Given that so many companies other than MS charge $2000 for these classes, for Red Hat to charge $5000 does not seem defensible.
I don't know about calcium, but vitamin C is safe to consume *far* in excess of USRDA recommendations. The USRDA of C is 60mg, and I consume 2000mg everyday with no ill effects. Linus Pauling (incidentally, Mr. Torvalds was named after him) was a Nobel Prize-winning researcher who consumed/recommended 16000mg daily (in four equal doses of 4000mg powdered C mixed in a glass of water).
It hit me so hard that it forced out some scat.
Or did you "violate" JonKatz 'til he rose from the dead?
"Well, well, well. Less than twenty-four hours 'til Ragnarok and I haven't a stitch to wear."
Billions of people around the globe are thinking this very thought. Don't be part of the mass of cannon fodder awaiting their fate on January 1st. I'd like to help others survive and prosper after the Y2K "situation" by describing the preparations I've made over the past year for tonight's Big Event.
1. The Car
Nothing says "I'm a survivor!" like a cool set of wheels, which is why I have a 1971 Plymouth HemiCuda with a 426ci/425hp V8.
I took out the rear window and rear seats, and welded in two 55-gallon drums as reserve fuel tanks.
I filled the trunk with cement so I could ram other vehicles in reverse during "Road Warrior"-type scenarios.
Due to the weight of the cement in the trunk, I had to replace the rear shocks with solid steel bars, so the suspension is pretty stiff, but boy does it have some range!
I've mounted a 20mm cannon (originally from a AH-1 Cobra helicopter) - that I bought on eBay for $35K - to the roof of the car so it faces forward.
It fires when the left turn signal is activated.
I use a Xybernaut wearable PC for aiming, and I adapted the anti-wobble feature of my camcorder to stabilize the cannon during vehicle movement and firing.
There is a radiacmeter attached to the grill, so I'll know when I'm approaching former urban areas.
I didn't have time to cut a hole in the hood to accommodate the huge intake of the supercharger attached to the engine, so I just left the hood off.
The exhaust system has been removed as a vestigial performance-hindering remnant of a civilized era.
2. The Duds
I have a fire-resistant Nomex jumpsuit dyed to match desert terrain, as all terrain will soon be desert terrain.
For formal occasions, black leather chaps are acceptable, but the buttless kind will make you the laughing-stock of Bartertown.
Accessorize with low-slung pistol holster, gas mask, and black leather jackboots.
Bandoleers are in this year, but only for survivors with crew-served weapons.
Fine-grain leather driving gloves will assist you in controlling your vehicle when driving through fallout-blighted areas.
3. Food
Pound-for-pound, dry dog food has ten times the nutritional value of boiled potatoes, and it can be stored longer, too!
Dog food for older dogs is often packed with fillers that you just don't need, but Puppy Chow is geared towards growing dogs, and has more than enough nutrition.
I'm towing a U-Haul trailer full of it, with a few cases of surplus MREs from the Gulf War for special occasions.
I hope I've provided some insight into the preparations necessary for surviving the coming hard times.
I am interested in having a traveling companion to help with driving.
Any fertile females interested in repopulating the planet should contact me at TheSurvivor@militia.mt.us
I'm not suggesting it's a good idea to write business logic in VB, but there is a book on doing so under SAP R/3, so *someone* must be doing it.
Actually, Compaq and other vendors will be shipping systems with Win2K installed next month, as stated in this article.
Also, so-called "golden code" (not beta) CDs are available now to members of the early adopter program for Win2K... so it has been released.
Well, lack of bandwidth is not really an issue in our network. Further, I am not trying to convince anyone that what I am doing in my environment would work best for them. I am simply stating that it works for us.
Running H.323 over HTTP isn't a decision that we made because we were trying to preserve bandwidth. It was a compromise to allow videoconferencing through our firewall. Maintaining two different configuration settings for the client program (one for Internet, one for LAN) would probably cause additional helpdesk calls, so we chose a one-size-fits-all approach. No one on our LAN is complaining about a slow network.
Further, we chose to use HTTP-DAV because is integrates well with our vision of having a web-based information resource for the company. The end-users are familiar with the point-and-click interface, and they don't have to learn any cryptic commands or switch amongst different apps to do their jobs. We do not expect our accountants, receptionists, machinists, and salespersons to become computer power users when there is an easier way for them to access the information they need to do their work.
If we have to sacrifice some bandwidth to make this happen, so what? I'm probably using the wrong octane-level of gas in my car, but my mechanic doesn't flame me for it.
Maybe you should find someone who will be able to setup things in your company properly then!?
Thanks for the suggestion, AC! I'll bring this up at our next staff meeting. Neither I nor the end-users were aware that the network was malfunctioning, as our applications deceptively behave as though nothing is wrong, but I'll forward your comments to them.
If you kill your own bandwidth (be it Gigabit or whatever) by making 100gb downloads, don't blame web server for not 'serving' the requests
Actually, our bandwidth isn't getting killed. We have an excess of it. Our end-users are happy.
I appreciate your enthusiastic and - dare I say it - emotional response to my network's configuration, but I wasn't posting to point out some flaw or error that needs correcting. I was simply stating that web servers that are capable of dishing out content in excess of T3 speeds aren't as exotic as some people may think, since many web servers are used to deliver content over a LAN at Ethernet speeds.
If the few posters who think I am insane or stupid because file transfers are generally done over HTTP in my network want to hear me admit that HTTP might not be the most efficient protocol for this kind of thing, so be it! HTTP is not a very bandwidth-efficient means of file transfer.
However, the excess of bandwidth in our LAN means that we can afford to waste a little bandwidth. The LAN has been over-engineered with scalability in mind. Further, the nature of the clients' use of the network (i.e. as much as possible is done with the web browser) makes file transfer over HTTP the easiest way to do it.
Way off topic...
Strangely, there is no Fry's website. They do own the frys.com domain (apparently for mail), but I can't find any publicly accessible pages.
Well, I sure don't use ZD articles as a shopping tool. When I am looking for solutions for uncommon problems, I often ask my friends at the consulting firm where I used to work what has worked for them. I also ask my hardware vendors for advice, but that has to be taken with a grain of salt since they're usually just trying to sell the most expensive solution. I also use AltaVista to search for text strings like "enterprise document management" or "PDF automation". Sure, I have to put up with "2,102,893 matches found, displaying results 1 - 10", but I find some pretty off-the-wall stuff that way
For more mundance solutions, I usually stick with what I know works. I'm a little surprised that HP didn't send me a Christmas card this year, as we buy a whole lot of their products. All the Intel-based servers are HP NetServers, the workstations are HP Kayaks, and the low-end clients are *cheap* and reliable HP Vectras. It doesn't hurt that the CEO and COO are both technophiles, and have realized the productivity gains of their employees as our IT infrastructure has grown.
One of the reasons I've pushed to make everything web-based is to create some level of platform independence. We have a huge number of Word, Excel, and PowerPoint files on our network, so for the time being everyone needs MS-Office, and thus, Windows, but at least there are packages out there with import/export tools for MS-Office, such as StarOffice and ApplixWare. What is more insidious are the client/server applications that will probably never get ported outside of Windows. By pushing the web-centric option, we leave open the possibility of making an alternative OS the primary desktop.
The engineers will probably never be able to leave NT, as AutoCAD, SolidWorks, and Pro/Engineer would all have to offer UNIX versions of their product to make that switch, but virtually everyone else in the company could someday be moved.
True, but I referring to changes made through "official" channels.
(Sliding even further off-topic)
I certainly understand your apprehension at putting all functions on one box... when I first started working for my employer about two years ago (then as a consultant) it was a 100% Microsoft shop with everything running on three NT servers cobbled together from parts someone probably bought at Fry's.
I've finally managed to offload some core network functions to Solaris and BSD boxes, and got rid of that awful MS-Proxy Server, but it looks like NT is here to stay for inhouse messaging and such. At least the NT boxes are on better hardware now.
As far as configuring the firewalls go, well, our super-spooky network security guru has developed a model of "ultra-paranoid double redundancy" which makes changes unsanctioned by him impossible, so port 80 it is.
Perhaps I should provide a few more details about our network, so I can justify the the design decisions that went into it.
We have about 250GB - in about 200,000 files - available on four servers. At this point, having a cleverly designed directory structure is no longer a viable solution for organizing our documents across the enterprise, and an additional layer of abstraction is needed so users can locate the files they need.
Enterprise Document Management Systems are applications that usually sit on top of an RDBMS and allow search, check-in check-out, version control, and other features beyond what a file server can do. Since we already have an Oracle ERP solution installed here, we went with their EDMS product, but there are certainly others available (most notably from Xerox and Eastman-Kodak, although recently I've wondered how suitable CVS would be for such a task).
By the way, I think the biggest CAD file I found on our servers was ~400MB, and it was a Pro/Engineer drawing of a component that could fit in the palm of your hand. After a six-month campaign of trying to ration disk usage by our employees, only to be voted down by higher-ups, I have resigned myself to the fact that I will be adding disk storage to these servers forever. Network Appliance is starting to look real good...
The concept is called "protocol encapsulation." As in H.323 videoconferencing protocol over HTTP. Since we also must do videoconferencing with our customers, we need a configuration that works over the Internet as well as the LAN, and our firewalls are configured such that HTTP is the viable solution.
As for file transfers, HTTP-DAV is nice because it allows totally clueless end-users to post documents via the web browser, rather than use some other application to handle file transfer. Since they are already using the browser as the interface for just about everything else, allowing them to post documents via the browser reduces end-user training requirements.
I'm not certain what you mean by using protocols that actually suit what I'm doing, as these two protocols (H.323, HTTP-DAV) are being used exactly as the designers intended.
If you have only 200 users, how are you going to be generating that kind of load?
By uploading and downloading multi-hundred megabyte CAD drawings and other such bandwidth consuming activity - such as video conferencing - over HTTP. Or by being in a much larger company with a similar, high-bandwidth infrastructure.
My point is that the firm I work for only has 200 users, yet we have more than enough bandwidth to saturate the web servers tested in the benchmark. There must be many companies with larger user bases that are capable of generating this kind of traffic over the LAN, without being eBay or a huge ISP. Not all web servers publish over the Internet, many publish over an intranet.
Our company may not be able to afford a T3, but we don't need one if the client is in the same building, capiche? Good. Such performance issues are relevant to more people than the poster three levels up described.
The best are maxing out multiple 10Mbps Ethernet cards - i.e. you need a T3 line to actually provide the bandwidth you're serving.
Without addressing the issue of whether *this* benchmark is valid, what if you are providing web services over a local intranet with a gigabit backbone and most clients on switched-100? What if that web server was the web interface for a heavily-used ERP application, or a Product Data Management solution over HTTP-DAV? Wouldn't the web server that was able to perform at the high-end matter in this case?
You don't need to be a big ISP or an eBay to make use of such bandwidth - if it's local. This scenario describes the company I work for, and we have only ~200 employees.