Well, if it's something like Apache, then you just put a traffic director (like the Linux Virtual Server) in front of the cluster, and yes, it is as simple as plugging in N more machines, and up to the limit of your traffic director, it will scale pretty much linearly. And if you can't get your hands on a machine or two to use as traffic directors, even round-robin DNS can do somewhat effective load-balancing.
>anyone have good reason now (other than slightly superior seek times) to stay with SCSI solutions?
Sure. multi-tasking, concurrent multi-device access. I'll avoid the arguments that have been hashed out time and time again, but when your machine has several different processes all competing for I/O, the difference in responsiveness becomes immediately apparant between the two.
SCSI was designed from the ground up to allow fast, efficient concurrent use of the bus by many different devices and processes. IDE was designed to be inexpensive. SCSI still has some very nice features (beyond the number of devices) that IDE will never have.
Does that mean that everyone should use SCSI? No. Nor should everyone use IDE. They're different tools for different jobs. Pick the one that's appropriate for yout task.
One reason, which others have hit on, is that it's nothing more than an ego-match with SCSI's 160 MB/sec bus speed. However, there is a semi-valid reason: The spec includes a addressing extension which increases the maximum size of a drive into the petabyte range.
The smaller the design, the lower the voltage you need, and the less power you consume.
However, manufacturers also take advantage of the shrink to up the frequency, bringing up the power consumption. We're still a ways off from having a thermal crisis. AMD still hasn't started using "thermal spreaders", and they're doing fine. Once they put the thermal spreaders on, they will be able to dissipate heat more quickly.
For those that think we're to the end of the road for air-cooled processors, no, there are heat sinks/fan combos today that are much more powerful than a chip needs without overclocking - and there are still many improvements to be made. For example, we could use larger fans at lower RPMs to move lots and lots of air without much noise at all - how does 60 CFM at 32 dB sound? (it sounds pretty quiet.)
Also, there are other ways of getting more benefit from air-cooled heat sinks. Most heat sinks do well with the addition of a copper plate on the bottom, for reasons too lengthy to go into here. And, by using well-designed shrouds, you can up the effectiveness even more.
So, why don't they make heat sinks like that today? The same reason they didn't make modern heat sinks 5 years ago - they didn't need them. With a small amount of thought and engineering, I believe that we can at least double the wattage of a chip without too many problems.
There are plenty of reasons to buy a SPARC, and to use Solaris, and to use Sun's software
Yeah, because it looks good to venture capitalists. : )
Most of our competitors went the "big money, big hype" route. They spent millions (literally) on very large Sun machines, and wrote all of their backends in Java. We spent ~$30,000 on commodity hardware, using Linux, and our setup dishes out many times more than theirs - at a much lower latency and load. And, of course, after spending all that money, they are now almost out of business.
Even funnier is that all of the venture capitalists that we spoke to wanted to know why we weren't using Sun and Oracle - and said that they'd probably want us to switch. The VC's put three rounds of funding into our next closest competitor, they're still floundering. They never gave us squat, and now we're turning a profit.
Another reason for my negative view of Sun's software is the fact that at a previous job, we spent over half of a year dealing directly with their programmers to try and get a critical bug fixed - to no avail. Finally, we got tired of rebooting the machine several times per week because of it, and used open-source software.
Sun's kernel may have some nifty programming features, but I'd much rather have the ability to get bugs fixed in a timely manner.
I don't see that as much of an issue. Why not? Well, I've been waiting for the VM thing to settle down, and a week ago I decided to check a couple of my production servers. What kernel did I find? 2.4.0. And they had been up since that was released. With 512M, swap usage was still at zero.
In business, you don't usually just upgrade every time a new -preX release comes out. You find something that works, and use it until you either it's broke, or you find something much better that you also know to work.
Civ games have always had great gameplay, and horrible coding. You know, like getting more than 256(?) military units in Civ 1, getting more than 128 cities in Civ 2, more than 32,000 in gold (Come on, use a real int for once!), the "go-to" getting in an infinite loop, network code not working, and Civ2 always taking 100% CPU while just sitting there blinking an icon.
So.... how did they do on this one? I'll hate it if I have to wait for the first update before I can buy the game.
Well, I'd almost never want it to propagate up the stack. Why not? Well, if my app can't open a file that it needs, it's awful to just let the OS give a generic, useless error to the user. I'd much rather handle things right there, and give them some useful information. But hey, that's just me.
Interesting. I've never run across an example of using exceptions that can't be done more cleanly, quickly, and efficiently by simply using (and checking) result codes.
To show that there's been an error, I'd much rather do this:
return undef;
than this:
raise Exception.Create('This didn't work');
And to check for an error, I'd MUCH rather do this:
die unless defined(do_something);
than this:
try
do_something
except
on e.excpetion do
exit;
end;
end;
In fact, the programmers that I've seen use exceptions tend to be less careful than those that simply check result codes.
AIUI, there are two competing methods of scaling CPUs now - Symmetric Multi-threading (SMT), and Chip-level Multi Processing (CMP).
Are they really competing technologies? I can't think of why SMT cpu's couldn't be used in SMP systems. SMP is a way of adding more CPU's, SMT is a way to keep each CPU busy more of the time. They sound kind of complementary to me.
It doesn't seem too practical to me. Most apps don't benefit greatly from SMP anyway.
They don't? What kind of server do you run? Most all pieces of production-class server software that I know of benefit from multiple processes. Look at Apache, forking off five, ten, or even more processes to handle requests. MySQL, I believe, uses threads. PostgreSQL forks off a new backend for each connection. Shoot, even your telnet, ftp, ssh, and mail daemons will fork off for each connection, allowing you to take advantage of more than one CPU.
If you're sitting at home working on a spreadsheet, you're right, SMP isn't for you - and this machine isn't targetted at you. When you're running a server that may have tens, hundreds, or thousands of SIMULTANEOUS processes fighting for CPU time, every processor counts.
And, to make things even better, even if you're only running a single, non-threaded process, having two processors still makes the machine much more "responsive", as the second CPU can handle kernel code for file IO, network code, interrupt handling, writing to logs, and a lot of other tasks. Ever seen how much CPU time even syslog can chew up?
As the CPU frequencies outstrip memory frequencies by larger and larger margins, the cost of a cache-miss increases - and so does the number of cycles a chip can afford to use looking through the cache. Because of that, the amount of cache where it stops making sense to add more is much, much higher than it was five years ago.
Intel chips, though, keep using about the same overall amount of cache, to keep costs down.
If you had taken even thirty seconds to read the blurb, you would see that they have indeed put two cores on one chip, which gives you two processors on a chip. Remember, "processor" != "chip".
It's the same idea as Via combining the north and south bridges on some of their motherboard chipsets. They take the two cores, and put them on a single wafer, with a bus (still on the same wafer) between them.
The idea really isn't revolutionary. Ever since microprosessors were invented, the trend has been to pack more and more onto a single chip, as it reduces cost, complexity, and design complexity while increasing compatibility and (most importantly) bandwidth. While your fastest P4 front-side bus chugs along at 400 MHz, busses that are kept on the wafer can run at full core frequency, even in the gigahertz range. Plus, you can run a lot more of them, and since the distances covered are shorter, it's easier to avoid external RF interference. And in multi-processing computers, the connectivity between cores is vitally important.
Look at a lot of motherboard chipsets these days. In one or two chips, they'll have circuitry for video, audio, modem, network, IDE, floppy, serial, USB, PCI, and memory controllers, to name just a few. One of the long-term goals that some companies have been talking about is "SOC", or "System On A Chip", where a single chip will have everything you need for a computer. At the point where the CPU has all of the other controllers inside of it, not only could performance increase dramatically, you could potentially use a motherboard for any CPU that you wanted, as all the motherboard would do is provide power to the CPU and traces from the CPU to the connectors for external componants.
Alan Cox said on the XFS list that it's because the XFS for Linux project has a lot of functions brought over from the SGI port which are duplications of Linux kernel functions. Before it will be put into regular kernels, those (as well as a few other issues) will have to be taken care of. I'd like it to happen, but I don't think that it will be any time soon.
> I cannot believe they are releases of stable branch, Sigh.
According to Alan Cox, in a message to the XFS list, he mentions that 2.4.10 is kindof 2.5 in disguise. It looks like Linus is making some fairly large changes that aren't as proven as those which he normally includes in production releases.
Does that bother me? Not really. I still have 2.4.0 running on my servers, and that only because it was reputed to do better on multiprocessor machines. Maybe the next time I do hardware upgrades I'll think about a newer kernel.
We already have much more fiber capacity than we can use. The real bottleneck of the Internet right now is... the switching. OC-768 units (38.8 gigabits/sec) won't even reach volume production until 2003 or later, and they wouldn't even handle half of one of these fibers, let alone multiple fibers coming from various locations. It's like running a 2" diameter fuel line to the engine of your Hyundai.
All-optical switches have been developed, but are not going to be widely deployed for some time. I have a feeling that even all-optical switches will be many years before they reach the speeds needed for 80 gb/s fibers.
The true improvement of the Internet will occur when switching capacity increases by at least an order of magnitude in a very short amount of time. Right now, good, guaranteed bandwidth is barely any less than it was back in 1997. Sure, as switching capacity slowly progresses to fill the needs of the backbone providers, the Internet keeps running - but you still end up paying out the nose for guaranteed bandwidth. Once the switches catch up with the fibers, however, that *might* change. Maybe.
These large-scale lan-parties need to organize a little bit between themselves - like holding the parties at the same time, and having some high-speed links between them. Then, you're not playing with 100, or 200, or even 400 people, you could be playing with 1,000 or more. Done right, it could be implemented without a terrible increase in cost, but make things a lot more fun.
Once I put some entries for various ad servers into my hosts file as 127.0.0.1. I tried surfing either CNN or NY Times (it's been a while), and guess what? I got a page that said that if I didn't look at the ads, I couldn't view the site. And these guys think they invented it. Sheesh.
Now maybe Linus will be more willing to start supporting "big iron" a little more. Yes, it's cool that Linux still runs on 386's, but isn't making an OS partially crippled for backwards-compatibility the arena of MicroSoft?
Using your processing cycles, bandwidth, and connection time for their own purposes? Sounds like "Theft of computers services" to me. It would be interesting to see that used *against* corporate computer stupidity.
The MLS service (at least here, I'm not sure about other locations) actually has the most powerful and useful web site that I have *ever* seen. It's a serious piece of work. The bad part? You have to be a realtor to get access.
Yes, it has a public interface - a vastly stripped-down version. The nice part is letting the agent do the searches *for* you, and emailing you the results each day. : )
Slashdot Mirror
Well, if it's something like Apache, then you just put a traffic director (like the Linux Virtual Server) in front of the cluster, and yes, it is as simple as plugging in N more machines, and up to the limit of your traffic director, it will scale pretty much linearly. And if you can't get your hands on a machine or two to use as traffic directors, even round-robin DNS can do somewhat effective load-balancing.
Not magic, but darn nice.
steve
>anyone have good reason now (other than slightly superior seek times) to stay with SCSI solutions?
Sure. multi-tasking, concurrent multi-device access. I'll avoid the arguments that have been hashed out time and time again, but when your machine has several different processes all competing for I/O, the difference in responsiveness becomes immediately apparant between the two.
SCSI was designed from the ground up to allow fast, efficient concurrent use of the bus by many different devices and processes. IDE was designed to be inexpensive. SCSI still has some very nice features (beyond the number of devices) that IDE will never have.
Does that mean that everyone should use SCSI? No. Nor should everyone use IDE. They're different tools for different jobs. Pick the one that's appropriate for yout task.
steve
One reason, which others have hit on, is that it's nothing more than an ego-match with SCSI's 160 MB/sec bus speed. However, there is a semi-valid reason: The spec includes a addressing extension which increases the maximum size of a drive into the petabyte range.
steve
The smaller the design, the lower the voltage you need, and the less power you consume.
However, manufacturers also take advantage of the shrink to up the frequency, bringing up the power consumption. We're still a ways off from having a thermal crisis. AMD still hasn't started using "thermal spreaders", and they're doing fine. Once they put the thermal spreaders on, they will be able to dissipate heat more quickly.
For those that think we're to the end of the road for air-cooled processors, no, there are heat sinks/fan combos today that are much more powerful than a chip needs without overclocking - and there are still many improvements to be made. For example, we could use larger fans at lower RPMs to move lots and lots of air without much noise at all - how does 60 CFM at 32 dB sound? (it sounds pretty quiet.)
Also, there are other ways of getting more benefit from air-cooled heat sinks. Most heat sinks do well with the addition of a copper plate on the bottom, for reasons too lengthy to go into here. And, by using well-designed shrouds, you can up the effectiveness even more.
So, why don't they make heat sinks like that today? The same reason they didn't make modern heat sinks 5 years ago - they didn't need them. With a small amount of thought and engineering, I believe that we can at least double the wattage of a chip without too many problems.
steve
>Isn't it high time, so long as we're zipping people around via particle beams, to find a fresher weapon than the .9mm pistol
Isn't it about time that people stopped saying ".9mm"? Being shot with a 0.03-caliber pistol doesn't sound very painful.
steve
There are plenty of reasons to buy a SPARC, and to use Solaris, and to use Sun's software
Yeah, because it looks good to venture capitalists. : )
Most of our competitors went the "big money, big hype" route. They spent millions (literally) on very large Sun machines, and wrote all of their backends in Java. We spent ~$30,000 on commodity hardware, using Linux, and our setup dishes out many times more than theirs - at a much lower latency and load. And, of course, after spending all that money, they are now almost out of business.
Even funnier is that all of the venture capitalists that we spoke to wanted to know why we weren't using Sun and Oracle - and said that they'd probably want us to switch. The VC's put three rounds of funding into our next closest competitor, they're still floundering. They never gave us squat, and now we're turning a profit.
Another reason for my negative view of Sun's software is the fact that at a previous job, we spent over half of a year dealing directly with their programmers to try and get a critical bug fixed - to no avail. Finally, we got tired of rebooting the machine several times per week because of it, and used open-source software.
Sun's kernel may have some nifty programming features, but I'd much rather have the ability to get bugs fixed in a timely manner.
steve
I don't see that as much of an issue. Why not? Well, I've been waiting for the VM thing to settle down, and a week ago I decided to check a couple of my production servers. What kernel did I find? 2.4.0. And they had been up since that was released. With 512M, swap usage was still at zero.
In business, you don't usually just upgrade every time a new -preX release comes out. You find something that works, and use it until you either it's broke, or you find something much better that you also know to work.
Steve
Civ games have always had great gameplay, and horrible coding. You know, like getting more than 256(?) military units in Civ 1, getting more than 128 cities in Civ 2, more than 32,000 in gold (Come on, use a real int for once!), the "go-to" getting in an infinite loop, network code not working, and Civ2 always taking 100% CPU while just sitting there blinking an icon.
So.... how did they do on this one? I'll hate it if I have to wait for the first update before I can buy the game.
steve
Well, I'd almost never want it to propagate up the stack. Why not? Well, if my app can't open a file that it needs, it's awful to just let the OS give a generic, useless error to the user. I'd much rather handle things right there, and give them some useful information. But hey, that's just me.
steve
Interesting. I've never run across an example of using exceptions that can't be done more cleanly, quickly, and efficiently by simply using (and checking) result codes.
To show that there's been an error, I'd much rather do this:
return undef;
than this:
raise Exception.Create('This didn't work');
And to check for an error, I'd MUCH rather do this:
die unless defined(do_something);
than this:
try
do_something
except
on e.excpetion do
exit;
end;
end;
In fact, the programmers that I've seen use exceptions tend to be less careful than those that simply check result codes.
steve
AIUI, there are two competing methods of scaling CPUs now - Symmetric Multi-threading (SMT), and Chip-level Multi Processing (CMP).
Are they really competing technologies? I can't think of why SMT cpu's couldn't be used in SMP systems. SMP is a way of adding more CPU's, SMT is a way to keep each CPU busy more of the time. They sound kind of complementary to me.
steve
It doesn't seem too practical to me. Most apps don't benefit greatly from SMP anyway.
They don't? What kind of server do you run? Most all pieces of production-class server software that I know of benefit from multiple processes. Look at Apache, forking off five, ten, or even more processes to handle requests. MySQL, I believe, uses threads. PostgreSQL forks off a new backend for each connection. Shoot, even your telnet, ftp, ssh, and mail daemons will fork off for each connection, allowing you to take advantage of more than one CPU.
If you're sitting at home working on a spreadsheet, you're right, SMP isn't for you - and this machine isn't targetted at you. When you're running a server that may have tens, hundreds, or thousands of SIMULTANEOUS processes fighting for CPU time, every processor counts.
And, to make things even better, even if you're only running a single, non-threaded process, having two processors still makes the machine much more "responsive", as the second CPU can handle kernel code for file IO, network code, interrupt handling, writing to logs, and a lot of other tasks. Ever seen how much CPU time even syslog can chew up?
steve
As the CPU frequencies outstrip memory frequencies by larger and larger margins, the cost of a cache-miss increases - and so does the number of cycles a chip can afford to use looking through the cache. Because of that, the amount of cache where it stops making sense to add more is much, much higher than it was five years ago.
Intel chips, though, keep using about the same overall amount of cache, to keep costs down.
steve
If you had taken even thirty seconds to read the blurb, you would see that they have indeed put two cores on one chip, which gives you two processors on a chip. Remember, "processor" != "chip".
It's the same idea as Via combining the north and south bridges on some of their motherboard chipsets. They take the two cores, and put them on a single wafer, with a bus (still on the same wafer) between them.
The idea really isn't revolutionary. Ever since microprosessors were invented, the trend has been to pack more and more onto a single chip, as it reduces cost, complexity, and design complexity while increasing compatibility and (most importantly) bandwidth. While your fastest P4 front-side bus chugs along at 400 MHz, busses that are kept on the wafer can run at full core frequency, even in the gigahertz range. Plus, you can run a lot more of them, and since the distances covered are shorter, it's easier to avoid external RF interference. And in multi-processing computers, the connectivity between cores is vitally important.
Look at a lot of motherboard chipsets these days. In one or two chips, they'll have circuitry for video, audio, modem, network, IDE, floppy, serial, USB, PCI, and memory controllers, to name just a few. One of the long-term goals that some companies have been talking about is "SOC", or "System On A Chip", where a single chip will have everything you need for a computer. At the point where the CPU has all of the other controllers inside of it, not only could performance increase dramatically, you could potentially use a motherboard for any CPU that you wanted, as all the motherboard would do is provide power to the CPU and traces from the CPU to the connectors for external componants.
steve
> Why not XFS inaddition to ext3 ?
Alan Cox said on the XFS list that it's because the XFS for Linux project has a lot of functions brought over from the SGI port which are duplications of Linux kernel functions. Before it will be put into regular kernels, those (as well as a few other issues) will have to be taken care of. I'd like it to happen, but I don't think that it will be any time soon.
steve
> I cannot believe they are releases of stable branch, Sigh.
According to Alan Cox, in a message to the XFS list, he mentions that 2.4.10 is kindof 2.5 in disguise. It looks like Linus is making some fairly large changes that aren't as proven as those which he normally includes in production releases.
Does that bother me? Not really. I still have 2.4.0 running on my servers, and that only because it was reputed to do better on multiprocessor machines. Maybe the next time I do hardware upgrades I'll think about a newer kernel.
steve
We already have much more fiber capacity than we can use. The real bottleneck of the Internet right now is... the switching. OC-768 units (38.8 gigabits/sec) won't even reach volume production until 2003 or later, and they wouldn't even handle half of one of these fibers, let alone multiple fibers coming from various locations. It's like running a 2" diameter fuel line to the engine of your Hyundai.
All-optical switches have been developed, but are not going to be widely deployed for some time. I have a feeling that even all-optical switches will be many years before they reach the speeds needed for 80 gb/s fibers.
The true improvement of the Internet will occur when switching capacity increases by at least an order of magnitude in a very short amount of time. Right now, good, guaranteed bandwidth is barely any less than it was back in 1997. Sure, as switching capacity slowly progresses to fill the needs of the backbone providers, the Internet keeps running - but you still end up paying out the nose for guaranteed bandwidth. Once the switches catch up with the fibers, however, that *might* change. Maybe.
steve
These large-scale lan-parties need to organize a little bit between themselves - like holding the parties at the same time, and having some high-speed links between them. Then, you're not playing with 100, or 200, or even 400 people, you could be playing with 1,000 or more. Done right, it could be implemented without a terrible increase in cost, but make things a lot more fun.
steve
Once I put some entries for various ad servers into my hosts file as 127.0.0.1. I tried surfing either CNN or NY Times (it's been a while), and guess what? I got a page that said that if I didn't look at the ads, I couldn't view the site. And these guys think they invented it. Sheesh.
steve
You might do more good be telling us just what you think is mis-informed.
steve
Now maybe Linus will be more willing to start supporting "big iron" a little more. Yes, it's cool that Linux still runs on 386's, but isn't making an OS partially crippled for backwards-compatibility the arena of MicroSoft?
steve
As if Dell were the only place to get a computer. As if Dell were a *decent* place to get a computer. Sheesh.
steve
Using your processing cycles, bandwidth, and connection time for their own purposes? Sounds like "Theft of computers services" to me. It would be interesting to see that used *against* corporate computer stupidity.
steve
I want to be the first to litter on an otherwise un-inhabitted planet...
steve
The MLS service (at least here, I'm not sure about other locations) actually has the most powerful and useful web site that I have *ever* seen. It's a serious piece of work. The bad part? You have to be a realtor to get access.
Yes, it has a public interface - a vastly stripped-down version. The nice part is letting the agent do the searches *for* you, and emailing you the results each day. : )
steve