from what I understand this is an unofficial patch for 2.2 kernel. Has it been merged in the main tree yet? Will 2.4 support it out of the box? Also, about the 64 GB support on ppro and p3, I understand that applications will still be limited to 4 Gb because they use 32 bit pointers. Am I right? What happens to the memory above 4 Gb? ___
I heard that on Alpha Linux supports only 1 gig of RAM because of something to do with PCI cards. If you put more then 1 gig of RAM in an Alpha box running Linux, the 32 bit PCI cards will stop working. Has this been fixed or what? What's the memory limit now? Is it the full 64 bit memory space?
Oh, also does anybody know when Debian 2.2 will be released? I'm itching to install this baby. In fact I actually did install it on one box and I like what I see so far. So how long till the release?
Your post is very informative, but there is one thing missing. You said you're using multiple Apache boxes which talk to the MySQL box. But how do you distribute the load among the Apache boxes? The incoming traffic needs to be somehow directed towards one of the Apache servers. Also, what if one of them dies? Will it kill the whole cluster or will the other boxes take over?
I know this is highly subjective, but what is, in your opinion, the best MTA?
I've been using exim, the default MTA that comes with Debian, and have been pretty happy with it. I also installed it on my Mandrake box cause I just couldn't figure out how to configure sendmail and I had no intention of spending lots of time on it.
I heard a few nice things about Postfix. Besides that there is smail, qmail, vmail, and whatever-mail. Does anybody have any experience with them?
Software is under license law. And specifically the license that accompanies the software.
That is incorrect. Software is under copyright law. The "licence" that accompanies the software (really, it's more like a unilateral contract), is valid only insofar that it restates the copyright law. If the licence says something like "if you use this product you must also buy Microsoft Word and get a lobotomy", it is full of shit.
I'm gonna be moderated way down for this, but honestly: who cares? We've already got bash, which is much better then ksh anyway. Besides, bash is GPL'd and has been GPL'd from day 1. ksh has just now been released under yet-another-open-source-license.
But license issues aside, bash is overall a better shell. So, anyone who cares about ksh, raise your hands.
Intel and AMD keep releasing faster and faster chips but
1. They have trouble producing them in quantity. 2. They prices are simply ridiculous. Who the hell needs a 1GHz CPU if it costs more then an average computer?
So, in light of this, I am wondering: do they actually manage to sell any of these "super-fast" CPUs? And if they do, what kind of luser would buy them? ___
I bet you can keep on stacking the cards up too, until you run out of IRQs...
Exactly. Until you run out of IRQs. I have never heard of more then 4 IDE controllers in a box, and even that is kind of a stretch.
Well, this is good. If what I think is true above (ie: the PIO modes are the only processor intensive ones) then this means that a UDMA hard drive is going to run at peak performane.
Well, DMA does offload CPU somewhat, but it's still not SCSI. SCSI offloads *all* the I/O work from the CPU. The UDMA HDs sure will work at peak performance (since the 33MB/s the UDMA33 can provide is usually at least twice as fast as HDs can sustain), provided that they have CPU's attention.
Once again, I am not a RAID guru, but even I can see that you are obviously wrong here.
1. IDE controllers are brain-dead. They do absolutely nothing and rely on the CPU to do everything. That was the intent of the design -- to make it as cheap as possible. They sure have achieved that, and it works rather well for desktops I must say. In and of itself it is not necessarily bad, but see #3.
2. DMA33 is actually 33 MB/s (hence the name...) The 25 MB/s transfer rate you are seeing is actually the HD limit. Even though the interface can sustain 33 MB/s, the HD is not as fast. 12.5 MB/s is actually pretty good for a HD.
3. (most important) Only *one* IDE HD per channel can work at a time. This means that if you have 2 HDs attached to the same IDE channel (i.e. master & slave), only *one* of them at a time will actually be able to transfer data. The second one will have to wait. Therefore, this defeats the whole point of RAID -- concurrency. The only way you can have concurrent reads/writes is if you connect 2 HDs to 2 different IDE channels. And since there is normally only 2 IDE channels in a box, your RAID would be kinda limited...
On the other hand, with SCSI you can connect up to 15 devices to one SCSI controller and have them *all* operate concurrently.
So, my conclusion is that, while software RAID may actually be a viable alternative to hardware RAID (as some people claim), IDE RAID is simply not suited for the job. ___
I have heard lots of times (even here on/.) frases like "avoid software RAID like the plague". Is the overhead really that small? Also, I understand that Linux does support some hardware RAID controllers (I heard Mylex something or other mentioned).
Could somebody else please comment on the issue? As you can see my knowledge RAID is quite limited.
First of all, why the hell was this post moderated to 5? Now, on to point out the obvious mistakes.
Slashdot has it wrong today. Microsoft has had the equivalent to Unix symlinks for a long time--they're called "shortcuts". Like a Unix symlink, a Windows shortcut is a small file that does nothing but point to another path where the real file is.
Huh? Please do not confuse shortcuts with symlinks. Symlink is a file system-level object. If I create a file called foo and make a symlink to it named bar, then, as far as any application is concerned, foo and bar are the same thing. I can open bar in an editor, for example, modify and save it. In fact *any* application that needs to read from/write to a file will not see the difference between foo and bar
If I create a directory called foo and make a symlink to it named bar, foo and bar will be equivalent as far as any application is concerned. Once again symlinks are file system level objects.
"Shortcuts", on the other hand are GUI-level objects. If you create a file foo and make a "shortcut" bar to it, you cannot treat it the same way as real files. Sure, you can create "shortcut" to a file and then double-click on it to open it in an application. But that's about all you can do with it. It's a GUI-level object. Anything that does not deal directly with GUI will not understand symlinks. That, for instance, includes daemons err... sorry "services".
As for automatic symlink creation (which is what it looks like Micro$oft has "innovated"), I find it of very low value. First of all, you do not want different files to be symlinked just because they have the same contents. In fact you often make copied of config files for backup and what not. But, once again, Microsoft decides to make decisions for you.
Secondly, the overhead of keeping hashes err... sorry "signatures" of files will likely outweigh the benefit of saving space. It will take up a lot of CPU cycles and memory. And HD space is much cheaper then memory and CPU cycles.
Windows 2000 is a piece of bloat as it is already, and it will become even more memory-hungry as a result of this "innovation". ___
Original Pentiums already had pipelined FPU. MMX has *nothing* to do with FPU. Cyrix has always sucked at FPU and integer performance was not as great as they claimed either. Just 3 month ago I upgraded from my olde crappy Cyrix "PR" 200 (which actually ran at 150) to AMD K6/2-300 and I am seeing a *huge* improvement in speed and, most importantly, *stability*. In addition to being slow, Cyrix CPUs are also very unreliable. I am never buying them again.
Intel *had to* release these chipsets & boards to get people to use Coppermine. That's because the price of RDRAM is over 6 *times* the price of standard SDRAM. The RDRAM-to-SDRAM translation was added as an afterthought when intel finally pulled its head out of its ass and realized people are not gonna pay 6 times the price for a product that has no real advantages over the existing one. ___
And gives almost as good performance when set up correctly as a RAMBUS setup.
Correction: DDR-DRAM is much faster then Rambus. 100MHz DDR-DRAM has bandwidth of 1.6GB/s, same as Rambus. 133MHz DDR-DRAM has a bandwidth of 2.1 GB/s (that's giga *bytes*, btw, not bits). DDR-DRAM, as well as regular SDRAM, also have a significantly lower latency.
And as it happens now, memory bandwidth is not the bottleneck. Even 800MB/s of regular PC100 SDRAM is plenty for 99% of applications, including the latest 3d games. Just about the only thing that would make use of the higher bandwidth is large databases. Too bad you can't put more than 512MB of RDRAM in a machine...;-)
However, lower latency is guaranteed to boost performance a bit, no matter what kind of application you are running. This is where standard SDRAM and the upcoming DDR-DRAM have an advantage over Rambus. Not to mention the cost...
So, the whole situation can be summed up in one sentence: Rambus is just an inferior product with a ridiculously high price. ___
I am perfectly happy with the way packaging system currently works. Granted, I am not an average newbie -- I've been running Linux for almost 2 years, so I may overlook something that a newbie would have trouble with.
rpms and debs make install/uninstall simple. I mean how hard can rpm -i be? Even way back when I first installed Linux (RH 5.0), I had no problem with that. Uninstall? No problem either: rpm -e. This works just as well as InstallShield, and doesn't waste download time by putting self-extracting code in every package.
Debian does an even better job. "apt-get install foo" will auto-magically *download* and *install* foo for you, as well as any other packages that foo needs in order to work. Give me an equivalent windows command for that. Similarly, "apt-get remove foo" will uninstall it.
So, I just don't see what the problem is.
What I would like to see though, is some kind of consolidation of debs and rpms into a single universal format.
Also, a GUI config tool for packages would be very nice. Newbies can get scared away by Debian's text-mode config scripts. But progress is already being made in this area. The frozen potato (Debian 2.2) already includes a front-end for package configuration.
To sum it up, package system can certainly use some improvement, but things are nowhere near as bad as the article would seem to imply. I would like to hear other opinions (esp. newbies) on the subject.
There's not a single question moderated in this article. In fact, I looked in other articles and found the same thing. Can anybody give more details about this? ___
Was it your idea to claim that algore2000.com web site is "Open Source"? Do you even understand what Open Source means, or did you just decide to put yet another buzz word on the site, along with "information superhighway", which Al Gore likes to use so often?
Also, who came up with the idea that Al Gore invented the internet? Was it you or Al Gore himself?
I certainly agree with you here. It's nice to finally read a comment from somebody who actually understands what they are talking about. However, I don't see how PC133 SDRAM or DDR DRAM would decrease latency. Wouldn't it just increase the bandwidth the same way Rambus does? Care to explain, please?
P.S. I should have said memory *bandwidth* is not the bottleneck. Lowering latency would certainly be helpful. Unfortunately Intel doesn't think so... or doesn't want to. Why does Intel insist on Rambus even now that it's clear the technology sucks?
Theoretically, what you are saying is true. However in practice it does not happen precisely because the curent memory bandwidth is enough. You also mention latency -- and yes, decreasing latency would benefit performance, but this is not what Rambus, PC133 SDRAM and DDR DRAM are designed to accomplish. Their goal is to increase the memory bandwidth which has nothing to do with latency.
In the benchmark I mentioned, Tom used 400MHz Rambus -- the fastest one currently available. It has exactly twice the bandwidth of PC100 SDRAM (800MB/s vs 1.6GB/s). And yet the performance difference was a whopping 5% on *some* benchmarks, even less on most. Keep in mind that Rambus is no less then *six times* more expensive then standard SDRAM.
Furthermore, there have been quite a number of benchmarks that show *no* difference in overall speed between 66MHz and 100MHz bus Pentium 2, given that the CPU speed is the same. Surprise surprise, cache is actually quite effective.
Now, when you have a SMP system, you may eventually run into memory bandwidth problems as the clock speed and the number of the CPUs increase. But it is a non-issue when it comes to single-CPU machines, even when playing 3d Games (Q3 comes to mind).
The real bottleneck is currently the video cards. NVidia GeForce and a few others include the geometry engine which takes care of *all* graphics related work. This is a step in the right direction. Even now the video card matter much more to a 3d game performance then the CPU and bus speed combined. And I expect the trend to continue.
But RAM technology is becoming the bottleneck lately.
Uhhh... I'm getting so tired of this. No RAM technology is NOT becomming a bottleneck. Tom (www.tomshardware.com) tested p3-600MHz systems with standard pc100 SDRAM and 400MHz Rambus. Well, the Rambus systems were about 5% faster. But considering also that they had newer chipsets and, most importantly, on-die full-speed cache (as opposed to halh-speed cache of the old P3-600), one has to wonder what exactly caused the speed increase. Also, considering that Rambus is 6 *times* more expensive then SDRAM, the 5% speed increase does not look attractive at all.
Slashdot Mirror
from what I understand this is an unofficial patch for 2.2 kernel. Has it been merged in the main tree yet? Will 2.4 support it out of the box?
Also, about the 64 GB support on ppro and p3, I understand that applications will still be limited to 4 Gb because they use 32 bit pointers. Am I right? What happens to the memory above 4 Gb?
___
I heard that on Alpha Linux supports only 1 gig of RAM because of something to do with PCI cards. If you put more then 1 gig of RAM in an Alpha box running Linux, the 32 bit PCI cards will stop working. Has this been fixed or what? What's the memory limit now? Is it the full 64 bit memory space?
Oh, also does anybody know when Debian 2.2 will be released? I'm itching to install this baby. In fact I actually did install it on one box and I like what I see so far. So how long till the release?
___
Your post is very informative, but there is one thing missing. You said you're using multiple Apache boxes which talk to the MySQL box. But how do you distribute the load among the Apache boxes? The incoming traffic needs to be somehow directed towards one of the Apache servers. Also, what if one of them dies? Will it kill the whole cluster or will the other boxes take over?
___
I know this is highly subjective, but what is, in your opinion, the best MTA?
I've been using exim, the default MTA that comes with Debian, and have been pretty happy with it. I also installed it on my Mandrake box cause I just couldn't figure out how to configure sendmail and I had no intention of spending lots of time on it.
I heard a few nice things about Postfix. Besides that there is smail, qmail, vmail, and whatever-mail. Does anybody have any experience with them?
___
the post must have been previously at 2
___
That is incorrect. Software is under copyright law. The "licence" that accompanies the software (really, it's more like a unilateral contract), is valid only insofar that it restates the copyright law. If the licence says something like "if you use this product you must also buy Microsoft Word and get a lobotomy", it is full of shit.
___
yes, but PlayStation has only one use -- playing games. PC stands for Personal Computer and there is a reason for that.
___
I'm gonna be moderated way down for this, but honestly: who cares? We've already got bash, which is much better then ksh anyway. Besides, bash is GPL'd and has been GPL'd from day 1. ksh has just now been released under yet-another-open-source-license.
But license issues aside, bash is overall a better shell. So, anyone who cares about ksh, raise your hands.
___
Intel and AMD keep releasing faster and faster chips but
1. They have trouble producing them in quantity.
2. They prices are simply ridiculous. Who the hell needs a 1GHz CPU if it costs more then an average computer?
So, in light of this, I am wondering: do they actually manage to sell any of these "super-fast" CPUs? And if they do, what kind of luser would buy them?
___
Exactly. Until you run out of IRQs. I have never heard of more then 4 IDE controllers in a box, and even that is kind of a stretch.
Well, this is good. If what I think is true above (ie: the PIO modes are the only processor intensive ones) then this means that a UDMA hard drive is going to run at peak performane.
Well, DMA does offload CPU somewhat, but it's still not SCSI. SCSI offloads *all* the I/O work from the CPU. The UDMA HDs sure will work at peak performance (since the 33MB/s the UDMA33 can provide is usually at least twice as fast as HDs can sustain), provided that they have CPU's attention.
___
Once again, I am not a RAID guru, but even I can see that you are obviously wrong here.
...) The 25 MB/s transfer rate you are seeing is actually the HD limit. Even though the interface can sustain 33 MB/s, the HD is not as fast. 12.5 MB/s is actually pretty good for a HD.
1. IDE controllers are brain-dead. They do absolutely nothing and rely on the CPU to do everything. That was the intent of the design -- to make it as cheap as possible. They sure have achieved that, and it works rather well for desktops I must say. In and of itself it is not necessarily bad, but see #3.
2. DMA33 is actually 33 MB/s (hence the name
3. (most important) Only *one* IDE HD per channel can work at a time. This means that if you have 2 HDs attached to the same IDE channel (i.e. master & slave), only *one* of them at a time will actually be able to transfer data. The second one will have to wait. Therefore, this defeats the whole point of RAID -- concurrency. The only way you can have concurrent reads/writes is if you connect 2 HDs to 2 different IDE channels. And since there is normally only 2 IDE channels in a box, your RAID would be kinda limited...
On the other hand, with SCSI you can connect up to 15 devices to one SCSI controller and have them *all* operate concurrently.
So, my conclusion is that, while software RAID may actually be a viable alternative to hardware RAID (as some people claim), IDE RAID is simply not suited for the job.
___
I have heard lots of times (even here on /.) frases like "avoid software RAID like the plague". Is the overhead really that small? Also, I understand that Linux does support some hardware RAID controllers (I heard Mylex something or other mentioned).
Could somebody else please comment on the issue? As you can see my knowledge RAID is quite limited.
___
Slashdot has it wrong today. Microsoft has had the equivalent to Unix symlinks for a long time--they're called "shortcuts". Like a Unix symlink, a Windows shortcut is a small file that does nothing but point to another path where the real file is.
Huh? Please do not confuse shortcuts with symlinks. Symlink is a file system-level object. If I create a file called foo and make a symlink to it named bar, then, as far as any application is concerned, foo and bar are the same thing. I can open bar in an editor, for example, modify and save it. In fact *any* application that needs to read from/write to a file will not see the difference between foo and bar
If I create a directory called foo and make a symlink to it named bar, foo and bar will be equivalent as far as any application is concerned. Once again symlinks are file system level objects.
"Shortcuts", on the other hand are GUI-level objects. If you create a file foo and make a "shortcut" bar to it, you cannot treat it the same way as real files. Sure, you can create "shortcut" to a file and then double-click on it to open it in an application. But that's about all you can do with it. It's a GUI-level object. Anything that does not deal directly with GUI will not understand symlinks. That, for instance, includes daemons err... sorry "services".
As for automatic symlink creation (which is what it looks like Micro$oft has "innovated"), I find it of very low value. First of all, you do not want different files to be symlinked just because they have the same contents. In fact you often make copied of config files for backup and what not. But, once again, Microsoft decides to make decisions for you.
Secondly, the overhead of keeping hashes err... sorry "signatures" of files will likely outweigh the benefit of saving space. It will take up a lot of CPU cycles and memory. And HD space is much cheaper then memory and CPU cycles.
Windows 2000 is a piece of bloat as it is already, and it will become even more memory-hungry as a result of this "innovation".
___
Original Pentiums already had pipelined FPU. MMX has *nothing* to do with FPU. Cyrix has always sucked at FPU and integer performance was not as great as they claimed either. Just 3 month ago I upgraded from my olde crappy Cyrix "PR" 200 (which actually ran at 150) to AMD K6/2-300 and I am seeing a *huge* improvement in speed and, most importantly, *stability*. In addition to being slow, Cyrix CPUs are also very unreliable. I am never buying them again.
___
Intel *had to* release these chipsets & boards to get people to use Coppermine. That's because the price of RDRAM is over 6 *times* the price of standard SDRAM. The RDRAM-to-SDRAM translation was added as an afterthought when intel finally pulled its head out of its ass and realized people are not gonna pay 6 times the price for a product that has no real advantages over the existing one.
___
Correction: DDR-DRAM is much faster then Rambus. 100MHz DDR-DRAM has bandwidth of 1.6GB/s, same as Rambus. 133MHz DDR-DRAM has a bandwidth of 2.1 GB/s (that's giga *bytes*, btw, not bits). DDR-DRAM, as well as regular SDRAM, also have a significantly lower latency.
And as it happens now, memory bandwidth is not the bottleneck. Even 800MB/s of regular PC100 SDRAM is plenty for 99% of applications, including the latest 3d games. Just about the only thing that would make use of the higher bandwidth is large databases. Too bad you can't put more than 512MB of RDRAM in a machine... ;-)
However, lower latency is guaranteed to boost performance a bit, no matter what kind of application you are running. This is where standard SDRAM and the upcoming DDR-DRAM have an advantage over Rambus. Not to mention the cost...
So, the whole situation can be summed up in one sentence: Rambus is just an inferior product with a ridiculously high price.
___
I am perfectly happy with the way packaging system currently works. Granted, I am not an average newbie -- I've been running Linux for almost 2 years, so I may overlook something that a newbie would have trouble with.
rpms and debs make install/uninstall simple. I mean how hard can rpm -i be? Even way back when I first installed Linux (RH 5.0), I had no problem with that. Uninstall? No problem either: rpm -e. This works just as well as InstallShield, and doesn't waste download time by putting self-extracting code in every package.
Debian does an even better job. "apt-get install foo" will auto-magically *download* and *install* foo for you, as well as any other packages that foo needs in order to work. Give me an equivalent windows command for that. Similarly, "apt-get remove foo" will uninstall it.
So, I just don't see what the problem is.
What I would like to see though, is some kind of consolidation of debs and rpms into a single universal format.
Also, a GUI config tool for packages would be very nice. Newbies can get scared away by Debian's text-mode config scripts. But progress is already being made in this area. The frozen potato (Debian 2.2) already includes a front-end for package configuration.
To sum it up, package system can certainly use some improvement, but things are nowhere near as bad as the article would seem to imply. I would like to hear other opinions (esp. newbies) on the subject.
___
There's not a single question moderated in this article. In fact, I looked in other articles and found the same thing. Can anybody give more details about this?
___
Was it your idea to claim that algore2000.com web site is "Open Source"? Do you even understand what Open Source means, or did you just decide to put yet another buzz word on the site, along with "information superhighway", which Al Gore likes to use so often?
Also, who came up with the idea that Al Gore invented the internet? Was it you or Al Gore himself?
___
I mean come on people. Is there anything else you expect from Microsoft?
___
What the hell are you talking about? Did you even read the article? They counted the number of *sales*, not virtual hosts.
___
but the bandwidth of PC100 SDRAM is 800MB/s.
___
I certainly agree with you here. It's nice to finally read a comment from somebody who actually understands what they are talking about.
However, I don't see how PC133 SDRAM or DDR DRAM would decrease latency. Wouldn't it just increase the bandwidth the same way Rambus does? Care to explain, please?
P.S. I should have said memory *bandwidth* is not the bottleneck. Lowering latency would certainly be helpful. Unfortunately Intel doesn't think so... or doesn't want to. Why does Intel insist on Rambus even now that it's clear the technology sucks?
___
Theoretically, what you are saying is true. However in practice it does not happen precisely because the curent memory bandwidth is enough. You also mention latency -- and yes, decreasing latency would benefit performance, but this is not what Rambus, PC133 SDRAM and DDR DRAM are designed to accomplish. Their goal is to increase the memory bandwidth which has nothing to do with latency.
In the benchmark I mentioned, Tom used 400MHz Rambus -- the fastest one currently available. It has exactly twice the bandwidth of PC100 SDRAM (800MB/s vs 1.6GB/s). And yet the performance difference was a whopping 5% on *some* benchmarks, even less on most. Keep in mind that Rambus is no less then *six times* more expensive then standard SDRAM.
Furthermore, there have been quite a number of benchmarks that show *no* difference in overall speed between 66MHz and 100MHz bus Pentium 2, given that the CPU speed is the same. Surprise surprise, cache is actually quite effective.
Now, when you have a SMP system, you may eventually run into memory bandwidth problems as the clock speed and the number of the CPUs increase. But it is a non-issue when it comes to single-CPU machines, even when playing 3d Games (Q3 comes to mind).
The real bottleneck is currently the video cards. NVidia GeForce and a few others include the geometry engine which takes care of *all* graphics related work. This is a step in the right direction. Even now the video card matter much more to a 3d game performance then the CPU and bus speed combined. And I expect the trend to continue.
___
Uhhh... I'm getting so tired of this. No RAM technology is NOT becomming a bottleneck. Tom (www.tomshardware.com) tested p3-600MHz systems with standard pc100 SDRAM and 400MHz Rambus. Well, the Rambus systems were about 5% faster. But considering also that they had newer chipsets and, most importantly, on-die full-speed cache (as opposed to halh-speed cache of the old P3-600), one has to wonder what exactly caused the speed increase. Also, considering that Rambus is 6 *times* more expensive then SDRAM, the 5% speed increase does not look attractive at all.
___