For $11 million, not only would I shoot the movie in spite of back problems, I'd let the producer whack me in the spine with a baseball bat whenever he felt like it!
Remember that an Athlon on a *measly* 266-MHz bus can often out-outperform a P4 on a 400-MHz bus, and sometimes out-perform the P4 on a 533-MHz bus. Assuming they actually increase clock speed (and not another PR game), I'll bet that this will make the Athlons VERY competitive again.
The real question, at least in my mind, is whether they will make AthlonMP's with the 400-MHz bus. While it's not a wrap-up, indications seem to say that they won't, because it would compete with the hammers.
Seeing as how the AthlonMP motherboards have seperate busses for each processer, imagine if Nvidia made an "nforce" chipset with dual-channel memory for dual Athlons - each processer could get full memory bandwidth at the same time. That would be truly impressive, especially for RDBMS servers where you live and die on bandwidth.
But, of course, such a monster would be a direct competitor with the Hammers - and AMD's got too much at stake to let the Hammers fail.
Alrighty, look at the cost per port for those things. These people are charging $30 per month. After they pay for the investment in the fiber, their bandwidth, pay their employees, etc., just how long do you think it would take them to pay off those switches? A lot longer than they're willing to go for, I'll imagine.
Besides, simply putting all of those computers on the same L3 switch would be... well, quite ludicrous.
Even then, are they going to have the switching capacity from within the network? My guess is that they won't. Again, it wouldn't take many people actually trying to use that much bandwidth to create some serious congestion.
I've been in colocation facilities where you got a 100 mbit connection, and could push/pull 100 mbits to the outside world. Generally, though, you're buying a much smaller amount, and paying for that base +/ overage.
The difference is that in most upper-end colo facilities, you pay for BANDWIDTH, not TRANSFER. It's one thing to say "You get to mvoe 5 GB per month", it's another to say "You get to use X Mbits/second".
The hippocampus integrates short-term memory into long-term. People who have had their hippocampus damaged (or removed) are unable to form any new long-term memories. They live incredibly interesting lives, because everyone they meet is a new person - every time they meet them. Why would you want to actually have yours replaced?
I told my wife that if I had my hippocampus removed, I'd get to sleep with a new woman every night, and not even be cheating on her! She didn't appreciate the comment so much, though....
Five gigabytes per month for a server? That's only 2 kilobits/second. If you assume that all of your traffic will be during an 8-hour period, that's still only 6 kilobit/s second. That means that somebody on a dial-up modem can make you go over that amount.
I suppose that if it's a personal server that is just going to handle email and occasionaly web-surfing, it would work, but not for much more. If you're doing ANY appreciable amount of traffic on the server, you're going to use a lot more transfer than that.
(As an aside, my servers generally pump out 5 gigabytes every couple of hours, but that's probably not the level of serving that you were talking about.)
There are a couple of fundamental problems with 100 mbit fiber to the door. First, the cost. With real, gauranteed bandwidth costing anywhere from up to $1,000 per megabit (depending on the quality of the provider), that means that they are going to have to oversell their bandwidth like *crazy* to try and make any profit. With a 100 mbit connection, it only takes a very small number of kiddies with P2P clients to use enough bandwidth to make the entire project unprofitable. Five people using an average of 50 mbits/second each could potentially cost the company over a hundred thousand dollars per month. That means that they'd need a minimum of 2,500 customers just to break even.
The second problem is the routing/switching. Let's say that they signed up those 2,500 people on the service. If even one tenth of them actually tried to use even half of their bandwidth at the same time, you're looking at 12 gigabits per second, which is more than an OC192 can handle.
Yep, there are some serious problems here. The kind of problems that they will only overcome by one or more of the following:
capping bandwidth
overselling like mad, effectively capping bandwidth
charging a lot
It looks like it will still be as good (or better) than DSL, but don't cling to the hopes of actually using 100 mbits.
On the other hand, I *have* been in places where one person could actually use 100 mbits. I watched a single download from Microsoft coming along at 11 megabytes/second - 88 megabits/second. Of course, the place had a barely-used OC3.
Pretty much everything Corel has touched has turned extremely mediocre. Corel Draw was a workable program, but nowhere near as good as the competition. The same was true for their photo editor and other side-apps.
When they bought WordPerfect, they took what was a very good product, and turned it into a workable, but mediocre product.
That's not necessarily because they "couldn't get it right". A lot of actors have realized that folks really like the bonus features, like deleted scenes. So, what do they do? When they're not pretending to know about world politics, they're demanding that they be paid extra for anything used as bonus features on a DVD.
They're already getting paid to shoot scenese. Then they want MORE money if some of those scenes are used in the bonus features. My, isn't that an interesting economical perspective.
Wow. 14 days between reboots? 90-day uptimes? Might I respectfully suggest that something on your systems sounds entirely broken?
Out of a pool of about 12 heavily-loaded servers that have been running for 4 years on 2.2 and 2.4 kernels, so far, I have had exactly *one* need to reboot that couldn't be positively traced to hardware problems. And that time I'm not entirely sure that it wasn't hardware-related, I just couldn't *prove* it.
The couple of times there have been hardware problems have been because of things like failed RAID cards or power supplies. I could count the number of incidents on one hand, and have at least one hand left over. A couple of the machines, in the 3 or 4 years they've been in service, have only been rebooted to switch colo facilities (twice) and for batched kernel+critical software (libc) upgrades (two or three times).
The last time I switched colocation facilities, *ALL* of the machines had been running for over a year. The thought of rebooting them never crossed my mind. And while some of them were very robust systems (triple-redundant power supplies, etc.), most of them were plain old commodity machines that I slapped together on my desk.
If you're really having to reboot those machines like that, you probably want to dig deeper and find out what the problems are. Chances are it's not just that one kernel version is more stable than another, it's that one kernel version doesn't exacerbate underlying, pre-existing problems as much as another.
who else (besides me) out there still has machines running 2.2 and intends to keep it that way?"
Certainly not me. All of my machines are SMP machines, and 2.4 with the o(1) scheduler lets me get much more out of the hardware. I was very excited when I decided that the combination (2.4+o(1)) was stable enough, and upgraded my main database server (4 CPU's) from a 2.2 kernel. System loads dropped by around 15% or 20%. That may not sound like much on the surface, but when you consider the cost of upgrading the hardware at that level, it's a HUGE bonus.
*yawn*. What else did you expect from sendmail? With the viable (usually BETTER) alternatives out there, anybody still using sendmail kind of gets what they deserve.
Serve out anonymous FTP through public file (http://cr.yp.to/publicfile.html). Then there aren't any security holes.
Really. The security holes in sendmail can be fixed by installing qmail. The security holes in BIND can be fixed by installing djbdns. The security holes in WuFTP (and most others) can be fixed by installing publicfile. There are also other good programs out there as well.
Yeah, sure, we don't need it, even for gaming. I remember back when I didn't even need a Pentium, my AMD 486 knock-off running at 120 MHz played all of my games just fine! Why, we shouldn't even THINK of anything higher than, say, a Pentium Pro.
The IO on a server is rarely going to run through an AGP port
No kidding. I just put that to show one of many I/O paths.
The V880 has several PCI busses for all of its PCI slots
I've got a PC with four different PCI busses. You've got to have some pretty serious data to saturate even the "measly" four PCI busses.
Some of the PCI slots are 66MHz 64 bit wide PCI slots
Old news. Those have been around on PC's for a good number of years now. I've got a three-year old, semi-retired PC that has a couple.
How can you possibly saturate that 533MHz FSB on the PC?
Um.... just about any memory-intensive application? Try using an RDBMS where you're potentially scanning through gigabytes of data. (even though that would generally indicate a lack of suitable indexes...)
Try loading up your PC with FCAL adapters, hooking them to smart disk arrays with gigs of write-through cache and see how much IO you can get.
Why would I need an FCAL adapter? I could stick in a couple of U320 SCSI adapters, or any of the hardware RAID controllers, and get just as much through. In either event, the 64/66 PCI bus is going to be the bottleneck, giving you a *sustained* average transfer of around 360-400 MB/s. You can do just as much on a PC. And putting the gigs of RAM into the controller probably isn't as efficient as putting the gigs of RAM into system memory, and letting the OS cache it. If you put it on the controller, your max bandwidth is still limitted by the PCI bus. If it's in the system, then a read (or write) that is cached has all the bandwidth of the system memory, which is going to be a lot faster than the PCI bus.
After all of that, let's look at the cost: A few thousand bucks for the PC I'm talking about (including a nice hardware RAID array), vs. $100,000 to $130,000 for a decked-out V880.
Yep, the V880 is a lot of iron. There aren't any PC's that will keep up with it. I'd expect nothing less, since the V880 you're talking about is at least a FULL ORDER OF MAGNITUDE MORE EXPENSIVE, for crying out loud. If the task is at all parallelizable, then guess what: For the same money as you'd spend on the Sun, you could deck the room out with enough clustered PC's to run circles around the V880. That's why all of the largest supercomputers now are... clusters of PC's. Of course, not all applications are parralelizable, hence the market for Suns, Alphas, IBM's, etc..
There are, of course, other benefits to owning a high-end Sun than just the processing power. Being able to have a motherboard burn out without taking down the system is one of them. Just be prepared to open the wallet and bend over when you buy one. My employer's largest competitor plonked down a couple of *million* dollars on Sun servers. I convinced my employer to plonk down about $25,000 on PC-based servers. While they were still in business, our site could dish out far more database-driven traffic than they could, and had better uptimes to boot. Of course, since they burned up all of their cash early and went out of business while we went on to become profitable, that's sort of a moot point.
Yes, ARM isn't x86, and Itanium's moving away. But I still believe that tens years from now, commodity desktop systems very well may still have x86 crap in them.
As I recall, if you asked Intel and/or MS fifteen years ago, by 1990 (or thereabouts), things were supposed to be fully 32-bit and multiprocesser. It wasn't until 2000 that MS produced a really was a viable, completely 32-bit OS for the desktop. (As good as NT4 was at the time, there were quite a few run of the mill home "desktop" tasks that simply couldn't be done.)
So sure, they'll tell us that in ten years, the legacy stuff will be gone, that chips will be at ten gigahertz, and that we'll all have web-enabled refrigeraters and a levitating car like the Jetsons. But if there's one thing that history has proven, it's that progress tends to move more slowly than the pundits (especially those with financial ties to the industry) would have us believe.
The reason that Alphas are in the state they're in now is purely economical, not technical.
They're great processers for floating-point work. For integer work, though, they're not competitive. I've beaten a $25,000 Alpha at RDBMS work with a $12,000 PC. Now that doesn't mean that the Alpha sucks, just that it only excels in certain areas.
Unfortunately, because it only excels in certain areas, it appeals to a much smaller audience. Things didn't work out, and it's sad.
Slashdot Mirror
For $11 million, not only would I shoot the movie in spite of back problems, I'd let the producer whack me in the spine with a baseball bat whenever he felt like it!
steve
And to think that they could have just spray-painted it reflective silver and added a few more fans.
steve
Remember that an Athlon on a *measly* 266-MHz bus can often out-outperform a P4 on a 400-MHz bus, and sometimes out-perform the P4 on a 533-MHz bus. Assuming they actually increase clock speed (and not another PR game), I'll bet that this will make the Athlons VERY competitive again.
steve
The real question, at least in my mind, is whether they will make AthlonMP's with the 400-MHz bus. While it's not a wrap-up, indications seem to say that they won't, because it would compete with the hammers.
Seeing as how the AthlonMP motherboards have seperate busses for each processer, imagine if Nvidia made an "nforce" chipset with dual-channel memory for dual Athlons - each processer could get full memory bandwidth at the same time. That would be truly impressive, especially for RDBMS servers where you live and die on bandwidth.
But, of course, such a monster would be a direct competitor with the Hammers - and AMD's got too much at stake to let the Hammers fail.
steve
Alrighty, look at the cost per port for those things. These people are charging $30 per month. After they pay for the investment in the fiber, their bandwidth, pay their employees, etc., just how long do you think it would take them to pay off those switches? A lot longer than they're willing to go for, I'll imagine.
Besides, simply putting all of those computers on the same L3 switch would be... well, quite ludicrous.
steve
Even then, are they going to have the switching capacity from within the network? My guess is that they won't. Again, it wouldn't take many people actually trying to use that much bandwidth to create some serious congestion.
steve
I've been in colocation facilities where you got a 100 mbit connection, and could push/pull 100 mbits to the outside world. Generally, though, you're buying a much smaller amount, and paying for that base +/ overage.
The difference is that in most upper-end colo facilities, you pay for BANDWIDTH, not TRANSFER. It's one thing to say "You get to mvoe 5 GB per month", it's another to say "You get to use X Mbits/second".
steve
The hippocampus integrates short-term memory into long-term. People who have had their hippocampus damaged (or removed) are unable to form any new long-term memories. They live incredibly interesting lives, because everyone they meet is a new person - every time they meet them. Why would you want to actually have yours replaced?
I told my wife that if I had my hippocampus removed, I'd get to sleep with a new woman every night, and not even be cheating on her! She didn't appreciate the comment so much, though....
steve
Five gigabytes per month for a server? That's only 2 kilobits/second. If you assume that all of your traffic will be during an 8-hour period, that's still only 6 kilobit/s second. That means that somebody on a dial-up modem can make you go over that amount.
I suppose that if it's a personal server that is just going to handle email and occasionaly web-surfing, it would work, but not for much more. If you're doing ANY appreciable amount of traffic on the server, you're going to use a lot more transfer than that.
(As an aside, my servers generally pump out 5 gigabytes every couple of hours, but that's probably not the level of serving that you were talking about.)
steve
The second problem is the routing/switching. Let's say that they signed up those 2,500 people on the service. If even one tenth of them actually tried to use even half of their bandwidth at the same time, you're looking at 12 gigabits per second, which is more than an OC192 can handle.
Yep, there are some serious problems here. The kind of problems that they will only overcome by one or more of the following:
It looks like it will still be as good (or better) than DSL, but don't cling to the hopes of actually using 100 mbits.
On the other hand, I *have* been in places where one person could actually use 100 mbits. I watched a single download from Microsoft coming along at 11 megabytes/second - 88 megabits/second. Of course, the place had a barely-used OC3.
steve
Pretty much everything Corel has touched has turned extremely mediocre. Corel Draw was a workable program, but nowhere near as good as the competition. The same was true for their photo editor and other side-apps.
When they bought WordPerfect, they took what was a very good product, and turned it into a workable, but mediocre product.
steve
That's not necessarily because they "couldn't get it right". A lot of actors have realized that folks really like the bonus features, like deleted scenes. So, what do they do? When they're not pretending to know about world politics, they're demanding that they be paid extra for anything used as bonus features on a DVD.
They're already getting paid to shoot scenese. Then they want MORE money if some of those scenes are used in the bonus features. My, isn't that an interesting economical perspective.
steve
Wow. 14 days between reboots? 90-day uptimes? Might I respectfully suggest that something on your systems sounds entirely broken?
Out of a pool of about 12 heavily-loaded servers that have been running for 4 years on 2.2 and 2.4 kernels, so far, I have had exactly *one* need to reboot that couldn't be positively traced to hardware problems. And that time I'm not entirely sure that it wasn't hardware-related, I just couldn't *prove* it.
The couple of times there have been hardware problems have been because of things like failed RAID cards or power supplies. I could count the number of incidents on one hand, and have at least one hand left over. A couple of the machines, in the 3 or 4 years they've been in service, have only been rebooted to switch colo facilities (twice) and for batched kernel+critical software (libc) upgrades (two or three times).
The last time I switched colocation facilities, *ALL* of the machines had been running for over a year. The thought of rebooting them never crossed my mind. And while some of them were very robust systems (triple-redundant power supplies, etc.), most of them were plain old commodity machines that I slapped together on my desk.
If you're really having to reboot those machines like that, you probably want to dig deeper and find out what the problems are. Chances are it's not just that one kernel version is more stable than another, it's that one kernel version doesn't exacerbate underlying, pre-existing problems as much as another.
steve
who else (besides me) out there still has machines running 2.2 and intends to keep it that way?"
Certainly not me. All of my machines are SMP machines, and 2.4 with the o(1) scheduler lets me get much more out of the hardware. I was very excited when I decided that the combination (2.4+o(1)) was stable enough, and upgraded my main database server (4 CPU's) from a 2.2 kernel. System loads dropped by around 15% or 20%. That may not sound like much on the surface, but when you consider the cost of upgrading the hardware at that level, it's a HUGE bonus.
steve
"Please don't make them, because we don't want any more competition."
Wow. This might be the first new land they've set foot on without surrendering!
*yawn*. What else did you expect from sendmail? With the viable (usually BETTER) alternatives out there, anybody still using sendmail kind of gets what they deserve.
steve
"enterprise" meant "reliable"? WD just ruined that gig.
steve
Serve out anonymous FTP through public file (http://cr.yp.to/publicfile.html). Then there aren't any security holes.
Really. The security holes in sendmail can be fixed by installing qmail. The security holes in BIND can be fixed by installing djbdns. The security holes in WuFTP (and most others) can be fixed by installing publicfile. There are also other good programs out there as well.
steve
Yeah, sure, we don't need it, even for gaming. I remember back when I didn't even need a Pentium, my AMD 486 knock-off running at 120 MHz played all of my games just fine! Why, we shouldn't even THINK of anything higher than, say, a Pentium Pro.
steve
I've seen animals get the hiccups. It happens to my ferrets quite frequently!
steve
The IO on a server is rarely going to run through an AGP port
No kidding. I just put that to show one of many I/O paths.
The V880 has several PCI busses for all of its PCI slots
I've got a PC with four different PCI busses. You've got to have some pretty serious data to saturate even the "measly" four PCI busses.
Some of the PCI slots are 66MHz 64 bit wide PCI slots
Old news. Those have been around on PC's for a good number of years now. I've got a three-year old, semi-retired PC that has a couple.
How can you possibly saturate that 533MHz FSB on the PC?
Um.... just about any memory-intensive application? Try using an RDBMS where you're potentially scanning through gigabytes of data. (even though that would generally indicate a lack of suitable indexes...)
Try loading up your PC with FCAL adapters, hooking them to smart disk arrays with gigs of write-through cache and see how much IO you can get.
Why would I need an FCAL adapter? I could stick in a couple of U320 SCSI adapters, or any of the hardware RAID controllers, and get just as much through. In either event, the 64/66 PCI bus is going to be the bottleneck, giving you a *sustained* average transfer of around 360-400 MB/s. You can do just as much on a PC. And putting the gigs of RAM into the controller probably isn't as efficient as putting the gigs of RAM into system memory, and letting the OS cache it. If you put it on the controller, your max bandwidth is still limitted by the PCI bus. If it's in the system, then a read (or write) that is cached has all the bandwidth of the system memory, which is going to be a lot faster than the PCI bus.
After all of that, let's look at the cost: A few thousand bucks for the PC I'm talking about (including a nice hardware RAID array), vs. $100,000 to $130,000 for a decked-out V880.
Yep, the V880 is a lot of iron. There aren't any PC's that will keep up with it. I'd expect nothing less, since the V880 you're talking about is at least a FULL ORDER OF MAGNITUDE MORE EXPENSIVE, for crying out loud. If the task is at all parallelizable, then guess what: For the same money as you'd spend on the Sun, you could deck the room out with enough clustered PC's to run circles around the V880. That's why all of the largest supercomputers now are... clusters of PC's. Of course, not all applications are parralelizable, hence the market for Suns, Alphas, IBM's, etc..
There are, of course, other benefits to owning a high-end Sun than just the processing power. Being able to have a motherboard burn out without taking down the system is one of them. Just be prepared to open the wallet and bend over when you buy one. My employer's largest competitor plonked down a couple of *million* dollars on Sun servers. I convinced my employer to plonk down about $25,000 on PC-based servers. While they were still in business, our site could dish out far more database-driven traffic than they could, and had better uptimes to boot. Of course, since they burned up all of their cash early and went out of business while we went on to become profitable, that's sort of a moot point.
steve
so I will attempt to make myself feel compatatively better by taking you down a notch with a nit-pick:
touché!
steve
Yes, ARM isn't x86, and Itanium's moving away. But I still believe that tens years from now, commodity desktop systems very well may still have x86 crap in them.
As I recall, if you asked Intel and/or MS fifteen years ago, by 1990 (or thereabouts), things were supposed to be fully 32-bit and multiprocesser. It wasn't until 2000 that MS produced a really was a viable, completely 32-bit OS for the desktop. (As good as NT4 was at the time, there were quite a few run of the mill home "desktop" tasks that simply couldn't be done.)
So sure, they'll tell us that in ten years, the legacy stuff will be gone, that chips will be at ten gigahertz, and that we'll all have web-enabled refrigeraters and a levitating car like the Jetsons. But if there's one thing that history has proven, it's that progress tends to move more slowly than the pundits (especially those with financial ties to the industry) would have us believe.
steve
The reason that Alphas are in the state they're in now is purely economical, not technical.
They're great processers for floating-point work. For integer work, though, they're not competitive. I've beaten a $25,000 Alpha at RDBMS work with a $12,000 PC. Now that doesn't mean that the Alpha sucks, just that it only excels in certain areas.
Unfortunately, because it only excels in certain areas, it appeals to a much smaller audience. Things didn't work out, and it's sad.
steve