There are various channels from which to get the IOS. If you have a CCO account and know which version you want/need, you just log in and download it. There are also other ways of getting it, but as a "last-ditch" (or "too-lazy") method, you can email their support group directly.
You have either a bizarre definition of the phrase "extremely easy" or very little perspective on how easy it is to patch many other products.
I sent one email, and in return, got all of the IOS versions that I needed for my routers. I'd definitely say that was "extremely easy".
Maybe you mean that I can just tell Linus what kind of computer I have, and he'll send me over a tarball of 2.4.21, pre-configured with the options I'd like?
you don't have to email somebody and wait an hour to get the exploit
If you have a CCO account, then you don't have to wait an hour, you log in and pick it up. Super-mega-fabuloso-easy.
Wow. Yesterday, I just emailed TAC, gave them the output of "sh ver" for each router, and asked for the appropriate IOS. Within an hour, I had the files that I needed.
I'd just tell him "Look, this is what I have: (include the sh ver). Please tell me which IOS version I need, and please publish it for me."
The patch is extremely easy to come by. Do a "sh ver" on your router, and send the output to tac@cisco.com, and ask for an updated IOS. They'll likely be back to you within an hour or so.
If history repeats itself, my experience with 2.3/2.4 was that even late 2.3 kernels were buggy, and definitely not stable. 2.4.1, on the other hand, did me just fine, running perfectly stable on UP and SMP machines for long enough that I had no reason to upgrade until the o(1) scheduler was released.
As for scaling past 4 CPU's, that was much more true before 2.4. While it's still not going to scale linearly to an infinite number of processers, improvements along the way in the 2.4 series and the o(1) scheduler have helped out quite a bit.
I do believe that much of the non-scaling of Linux past 4 CPU's is, to some extent, actually the fault of the hardware, as the great majority of multiprocesser hardware has bottlenecks that impeded linear scaling.
As a simple example, take a look at the dual P4 Xeons on the 533 MHz bus. Sounds spiffy, right? Well, you're splitting the 533 FSB and memory busses between both processers, giving each one an effective *266 MHz* when under load. Seeing as how even the slowest single-proc P4 has a 400 MHz FSB, you can see off of the bat that you're hitting bottlenecks!
Look at the AthlonMP series: Each processer has it's own independent bus! However, the only available motherboards have a single-channel, 266 MHz memory architecture. That gives each processer only 133 MHz effective memory bus under load. The simple addition of a dual-channel memory controller (like the one on the NForce boards) would give the AthlonMP's a real shot in the arm.
Now, it may seem like I'm just talking about low-end multiprocesser machines, but here's another example: Even on some of the higher-end machines, there are restrictive bottlenecks. By naming names, I'll only start a flame-war with the zeolots, but suffice it to say that there are $35,000 "high-end" servers that have *less* total memory bandwidth than that $3,000 dual P4 Xeon. That is pretty pathetic!
It's pretty easy to see why someone who didn't realize that could plop $35,000 on a 4-way, big-name machine that had less memory bandwidth than a $3,000 dual P4 machine, see that under load both of them performed similarly, and say "Well, Linux must not scale well."
To make matters worse, the kind of applications that are run on multi-CPU machines tend to be things like RDBMS', which do not lend themselves well to clustering. Here's the catch: Those types of applications tend to be the most memory-demanding. So, take a single P4 with a 533 MHz bus, and install your RDBMS on it. Take a dual P4 Xeon with a 533 MHz bus, and try the RDBMS. You're certainly not going to scale linearly, but that's because you still haven't improved the memory bandwidth.
I only have one 4-processer machine, but the 2.4 kernels were wonderful on it. It got 2.4.3 when 2.4.3 was hot off of the presses, then ran without reboot or any glitch until it was shut down last month for hardware upgrades. At that point, I put 2.4.21 on it just for fun. Uptime was something like 1.5 years at that point. 2.4.3 is timestamped over 2 years ago, so it could be as long as that.
Our company drop-ships from many different suppliers. None of them have their act together with regards to shipping, but do just well enough to get by on intra-US shipping. However, *none* of them are able to RELIABLY ship outside of the US. That means that we'll LOSE money in headaches, hastles, lost merchandise, and support calls. It's unfortunate, because if these suppliers had their act together, they could exploit a global market, and make more money. There just aren't any suppliers in this market that are able to do it, the exporting is done by smaller fish down the food-chain.
There's also another factor: There are certain geographical areas (which shall remain unnamed) from where there are ten times more fraudulent orders than legitimate orders. In those areas, it's easiest (and usually most profitable) to simply not do business with ANYONE.
I was able to attend the "Windows NT 5.0 Rapid Deployment Conference" in San Jose. One of the talks given mentioned how they found something along the lines of 4,000 memory leaks in the *drivers alone* for NT4.0. REALLY scary.
The neat thing about the P4 2.8 Xeons is that they are hyperthreaded, so one could (try to) argue that really the box is 4 cpu's at once.
Well, I've played with HT, and it's nowhere near 30%. It's not really like having 4 processers, it's like speeding up the two that you have by 1%-5%. just because Linux shows you four processers doesn't mean that it really behaves that way.
'd rather have one box with 4 cpu's (or 2.6, depending on your math) than 4-5 boxes in the room.
Just because he used the stock Intel fans and a noisy SuperMicro case doesn't mean that anyone else would have to!
Now I'm not a network/beowulf geek, but wouldn't the network become the choke point for a distributed system?
Typically, yes. However, some tasks can be split up in such a way that you can send a relatively small amount of data to each node, and have it do a relatively large amount of computation on it. Then, the network isn't a problem. However, as another person pointed out to me, parallelising chess doesn't work as well as I thought it would.
Is it really all that bad? Fitting your OS onto a floppy disk no longer seems terribly important to me. A year or so ago, I built a complete, self-compiling LFS system that would fit onto a 64 meg flash drive. That's a *complete* system, including C libraries, compiler, LVS load-balancer, etc.. With hardware getting faster, larger, and cheaper, being able to fit things on a floppy doesn't seem quite as important.
That the software doesn't (seem) to exist to use a cluster instead.
No, really, this isn't one of the "imagine a Beowolf of these..." posts. Here's my point: For the cost of just one of the *processers* that he bought, you can build an *entire machine*, happily running an AthlonXP 2700+. An ENTIRE MACHINE. So, for the cost of the two processers, you've got two machines. For the cost of the SuperMicro motherboard and chassis, you can build two MORE machines. With the cost for the rest of the stuff, there's a fifth machine thrown in to boot.
So, what will be faster - a dual 2.8 GHz Xeon, or 5 AthlonXP 2700+ machines? My money's on the cluster, for this particular application. The Xeon machine has 533 MHz of total memory bandwidth, split between two processers, effectively 266 MHz each. The AthlonMP systems, with 333 MHz each, would have a combined bandwidth of 1,665 MHz - about three times that of the Xeon system.
To make it better, the Athlon is MUCH better than the P3 OR the P4 for integer work, which makes me wonder why he would choose the P4 in the first place. Furthermore, not only does the Athlon do much more in a clock cycle than a P4, you'd have a combined clock speed of 10.8 GHz with the Athlons instead of the 5.6 GHz of the Xeons. Twice the clock speed, AND more work per cycle!
Now, of course, being able to actually USE that clock speed would be dependent upon actually transmitting the messages back and forth, and efficiently dividing the work between the machines. In this sort of situation, where for any one point in time, there would be a great deal of possibilities to compute, it would seem like it would divide up very well.
I've got a number of dual-proc P3 systems in a rack that have gone for 3+ years without a crash, and not a one of them has ECC. In that time, they've been shut down about 3 or 4 times to move them and for kernel upgrades. I've also got an NT4 machine that hasn't crashed in about 4 years, it's been shut down twice - each time, to be moved to a different building.
Now, don't get me wrong - when something's critical, I do use ECC. But NOT using ECC isn't quite as bad as some people make it out to be.
Put your server in a colocation center. You can normally get deals where you pay for a low bandwidth regularly, but have the ability to burst quite high. As an example, you can be connected to a 100 megabit port on their router, but pay a base rate for, say, 1 or 2 megabits.
If that's not an option, you can always look into per-IP bandwidth limitting and QOS.
The companies that can't utilize their RAID controllers on a 133/64 pcix bus aren't using PC's anyway. Remember, 133/64 is nearly a gigaBYTE per second, and if you need to move that much, you're probably using a $1,000,000+ server.
HDTV recievers
Not true. HDTV utilizes much less than 100 megabits, around 18 megabits, if I recall.
Ethernet upwards of gigabit
Not true. While it's true that 10gig ethernet isn't much of a reality, it's not because of the bus. It's because (a) 10 gig ethernet over copper only works for a couple of feet, (b) average people have a tendency to dislike fiber, and (most importantly) (c) The average Joe doesn't need it.
Why don't they need it? Well, the average Joe won't even buy a gigabit switch. If you can't even sell them *ONE* gigabit, how are you going to sell them *TEN*?
high-speed tape drives
Again, that's not because of the bus. There are plenty of high-speed busses to choose from, but tape drives are inherantly slow, and unless you're sticking the ultra high-end drives on the slowest bus you can find, the bus isn't going to limit you.
It's all about economies of scale. If practically nobody has a bus that can handle it, you then have to really ramp up the price of the devices just to support the R&D costs, which then makes it harder to sell your product. It is just not the type of endeavor anyone is going go through.
That argument supports MY position more than yours. If it's all about the economies of scale, then it's cheaper for a company to make a 64-bit PCI card that can operate at 33, 66, 100, or 133 MHz, precisely because there is much less R&D. The controllers are already out there, and because it's also compatible with the slower busses, you can reach a larger target audience.
Think about it. You're in charge of making the new XYZ expansion card, which needs gobs of bandwidth. Do you (a) use an existing and fully adequit standard with very low R&D costs and backwards compatibility to boot, or do you (b) blow millions in R&D to try to use some new bus that it will be years before anyone adopts?
I don't expect people to use them because of the prohibitive costs,
It's cheaper to use the faster, existing PCI busses than to come up with new ones.
limited set of devices
They're much less limitted with faster PCI busses than they are with new ones. You can plug a 64-bit PCI device into a 32-bit PCI slot, and it will work, and vice-versa. That is NOT true if you move to a new bus, is it?
Consumers don't have 64-bit PCI slots because there are few 64-bit PCI devices. There are few 64-bit PCI devices because device makers know consumers don't have 64-bit PCI slots.
Please explain how that argument does NOT hold for the new, proposed busses.
First off, I sincerely doubt that number... Ethernet, Firewire, USB2, multiple IDE devices, etc... I'd say a great many users are nearing the high-end of the bus' capabilities.
Back it up with some numbers.
Manufacturers aren't going to make devices that need more bus bandwidth than just about any machines can provide (and mobo makers aren't going to invest in faster buses until devices need more bandwidth, ironically).
Tell me what kind of devices they would come up with. Your argument is starting to sound like "If you build it, they will come." You can't justify a new bus by just saying "Well, SOMEONE might use it." Tell me what kinds of devices these manufacturers are just DYING to make, but don't have the bandwidth for.
Obviously, the answer is "none" because people don't buy things that they can't actually use yet.
That's entirely false. If nobody has a tape backup that will do a gigabyte per second, it's not because they couldn't do it. They *can*, on a PC, with 133/64 pcix. And on other architectures, there are even faster I/O mechanisms. Don't blame the lack of a fast tape on the bus, 'cuz it just ain't true.
for one thing, you see very few 64-bit PCI devices, and I don't expect any home users to have them
You're talking in circles here. You say that we should come up with a faster bus, so that people can take advantage of it. Yet you say that you DON'T expect people to use faster busses that *ALREADY EXIST*, and are very economical to produce.
Face it, busses faster than a 32/33 PCI bus are already here, and have been here for years. Why aren't they on most motherboards? Because people don't want them badly enough to pay for them. If the average Joe would really benefit from a faster PCI bus, then you'd see companies putting them on their motherboards and throwing the sales pitches left and right.
Really. If most people aren't even interested in using a 64-bit PCI bus, then do we really need anything faster?
It isn't easy to choke a gigabit link, but it can be done. The controllers that are on 32/33 PCI busses typically top out somewhere in the 300-500 Mbit region (total throughput, ins and outs)
It sounds like something's not quite right in your setup. Good cards, like the Acenic cards, can easily max out the PCI bus when you're testing *only* the network, and the disk subsystem isn't involved. That means 80-100 MB/s (640-800 mb/s) throughput on a 32/33 bus, and they hit as closely to a gigabit as can be had on a 64-bit bus. If you're only getting a max of 500 mbits/sec, then something's off.
You're moving the choke point around, but not eliminating it. If I've got a series of PCI bridges (careful about your terminology- controller is generally used to refer to an end-point, not the bridge), everything still needs to go through the north-bridge, and if you are hooked up to that with a 32/33 PCI bus- you're majorly choked right there.
Luckily, pretty much ever chipset manufacturer has gotten away from using a 32/33 PCI bus to talk to the northbridge, so that's not a problem.
99% of all home users don't utilize resources that aren't there. In other words, you aren't going to see seriously resource hungry apps becomming popular until the resources are there...
Oh, please. When the average home user never uses more than 1/3 of the bus speed - EVER - there's simply no reason to build something faster. Sure, you could deck out every board with a faster bus, but it still wouldn't matter, they wouldn't use it.
Or, are you suggesting that there are "killer apps", just around the corner, that just won't work for a home user unless he gets a faster PCI bus?
Not "awfully tough" really. Just backup your RAID array to a fast tape (or other backup method).
Umm... show me a tape that can back up 250 megabytes/second. I guarantee that's not in use in home systems. And even if you do have one, no sweat - use a 133 PCIx bus. Now, you're at nearly two gigabytes/second. That means you have to pull a full gigabyte/second from your disk (*minimum* of 26 disks!), and then still pump a gigabyte/second to the tape drive. So, tell me: How many people have a tape drive that can back up a gigabyte per second?
Having said that, perhaps the first task should be speeding-up the interrupt system somehow, so a computer can actually handle all the data it is recieving, without bringing the system to a craw.
That's mostly a problem with gigE, and the problem isn't so much the interrupt system (although it COULD use improvements), it's that gigE is still using the same MTU that 10 megabit ethernet was using. You can get around that if you're using gigE end-to-end, and have nics and switches that support jumbo frames, but relatively few switches do. On the other hand, if you want to be able to handle huge numbers of interrupts, there is a relatively easy way to do it: Use an SMP board. : )
At the same time, maybe you can possibly also be interleaving your own system backup with data from other systems you recieve over your gigibit NIC...
On even a 64/66 PCI bus, there's still plenty of bandwidth for that, until you get to the stratospheric-costing equipment - and even then, 64/133 is still going to handle it easily.
Not quite. To get two full gigabit controllers working full tilt, you will need two ports off of the bridge, and even then, the bridge has to talk to the CPU, so you may be limited by the CPU bus speeds. 2 gigabit controllers running full tilt (full duplex, of course) is 4 gigabit of raw bus bandwidth (not counting overhead, of course).
2 gigabit controllers is 4 gigabits? Assuming that you're really doing a full gigabit in *each* direction on both NICs (and with some gigabit nics, you simply won't), and that you aren't being swamped by interrupts, that's still only ~500 MB/s. barely more than a 64/66 PCI bus. Easily within the reach of a 64/100 bus.
One thing you aren't taking into account is that PCI is a bus
Sure, I did. I never said differently. Perhaps you're forgetting that a lot of motherboards now have more than one PCI controller, and hence, more than one PCI bus? I've got a 4-year old machine that has 4 seperate PCI controllers, of varying speeds and widths. That means that you don't need to put all of your high-bandwidth devices on the same bus, giving you more total bandwidth, and less overhead/contention from sharing.
But PCI is not used solely for outside bandwidth
Aside from disks, pretty much anything you'll hook to a PCI bus that uses any significant bandwidth is going to be to the outside. Sure, your USB, serial, and even ISA busses are usually done through bridges on a PCI bus... but how much bandwidth do they use? Not a whole lot. The real bandwidth users are disks, with networks in second, and the rest far in the distance.
I'd really like to see more optical interconnects- but the infrastructure is just too expensive. People aren't willing to buy it, and far too expensive to put on a motherboard (Are you willing to pay $1500-$2000 per motherboard?)
One of us must be incredibly mistaken. $1500 for optical interconnects? Optical interconnects are getting cheap enough that there's even talk of building them right into processers.
Even more than that, going to optical simplifies the routing and circuitry on a motherboard. Instead of having to draw out 32, 64, or 100+ traces, paying close attention to keeping trace lengths similar, and worrying about crosstalk, etc., you draw 2 or 4 traces to your tranceiver, and boom, you're done.
"We" haven't "just begun to realize the depth and tangled nature of the gene pool". "You", and other uninformed consumes, might have.
People who work with genetics have been aware of it for a long, long time. They've been aware of the methods of gene transmission in a LOT of different organisms. In a lot of cases, they EXPLOIT them to get what they want.
Genetics and evolution are some of the least-understood fields. Now, don't get me wrong, nearly everyone *thinks* that they understand them, because they got to do punnit squares in high school biology, and they heard some stuff about Gregor Mendel and Charles Darwin. However, people who actually *do* know any amount of useful, detailed information about them are in incredibly short supply.
To make things worse, finding a *journalist* that has any sort of grasp of the subject they're writing about is an incredibly rare find. By the time these things hit public consumption, they're usually either greatly distorted, or dumbed-down to an incredible degree.
Witness the great hype and hysteria about "mapping the human genome". Sure, it's mapped. And the way it was announced, you'd think that we'd just solved the greatest problem in the world. Quite the contrary... now comes the REAL work, exploring what each gene actually does, and how they work together. It'll take thousands of times more work to get that done. Getting things mapped was the easy part.
PCI has been with us for around ten years now, and is rapidly running out of bandwidth
Are you *sure* it's running out of bandwidth?
The old-time, 10-year old 33 MHz, 32-bit PCI bus is still handles 99% of all home users just fine. However, for the more bandwidth-hungry users, you can increase the width to 64 bits. Not enough? Double the frequency. Still not enough? PCI-X will run them at up to *133 MHz*.
Let's put some numbers to that. On a 32/33 bus, you're looking at a maximum real-world, sustained throughput of about 100 megabytes/second. Double the width, that's 200 megabytes/second. Double the frequency, that's 400 megabytes/second.
Alrighty, then. Nearly a half of a gigabyte per second. That's awfully tough to fill. That will handle two gigabit ethernet controllers running full-tilt, and still have enough bandwidth left over that you'd need at least an INCREDIBLY fast RAID array to fill it.
But, just for fun, let's say it's still not enough. PCI-x, at 133 MHz, will double that *again*, to a full gigabyte per second. On a single controller. You're going to have an *INCREDIBLY* tough time actually using that - you'd be very hard pressed to actually get that much to move over a network and/or disk.
Still, you need more? No sweat. Many boards offer more than one controller. With two PCI-x controllers, that's two gigabytes/second of bandwidth. Not two gigaBITS, but rather two gigaBYTES.
Tyan recently introduced a board that has four gigabit controllers, each on their own PCI-x controller, with an additional 64/133 controller, a 64/100 controller, and a 32/33 controller. Again, let's put some numbers to that:
At 100 MB/s for each of the gigE controllers, that's 400 MB/s right off the bat. Add in the 64/133 controller, that's about 1400 MB/sec. Add in the 64/100, you're looking at about 2200 megaBYTES per second.
Now, really... can *anyone* here raise their hand and say that they could actually *utilize* 2200 megabytes/second of bandwidth to the outside world, either via network or disk?
Despite all of the ideas of the sky falling, PCI has done a very good job for the last decade, and amazingly enough, is still going strong. Strong enough that it will be quite a while before it truly NEEDS to be replaced.
Now, when it *IS* replaced, I'd much rather see the interconnects being optical, not electrical. Instead of cracking open the case, shutting off the power, and trying to wedge yet another card inside (especially in low-height rackmounts), I'd much rather set the device on a shelf, and run a fiber patch cable over to the computer. No shutting down, and a whole lot more simple.
I once worked in an IT department with around 1,000 people. They wouldn't hire the "youngsters", the youngest person there was about 26. In fact, a good number of people were over 40.
I guess it's sort of the opposite of what you were complaining about. : )
If Egypt's government has such a weak grasp, that letting their citizens/subjects think about alternative religions could present "crises", then it looks like they probably have some larger problems to tackle first.
Slashdot Mirror
There are various channels from which to get the IOS. If you have a CCO account and know which version you want/need, you just log in and download it. There are also other ways of getting it, but as a "last-ditch" (or "too-lazy") method, you can email their support group directly.
steve
You have either a bizarre definition of the phrase "extremely easy" or very little perspective on how easy it is to patch many other products.
I sent one email, and in return, got all of the IOS versions that I needed for my routers. I'd definitely say that was "extremely easy".
Maybe you mean that I can just tell Linus what kind of computer I have, and he'll send me over a tarball of 2.4.21, pre-configured with the options I'd like?
you don't have to email somebody and wait an hour to get the exploit
If you have a CCO account, then you don't have to wait an hour, you log in and pick it up. Super-mega-fabuloso-easy.
steve
Wow. Yesterday, I just emailed TAC, gave them the output of "sh ver" for each router, and asked for the appropriate IOS. Within an hour, I had the files that I needed.
I'd just tell him "Look, this is what I have: (include the sh ver). Please tell me which IOS version I need, and please publish it for me."
steve
The patch is extremely easy to come by. Do a "sh ver" on your router, and send the output to tac@cisco.com, and ask for an updated IOS. They'll likely be back to you within an hour or so.
steve
If history repeats itself, my experience with 2.3/2.4 was that even late 2.3 kernels were buggy, and definitely not stable. 2.4.1, on the other hand, did me just fine, running perfectly stable on UP and SMP machines for long enough that I had no reason to upgrade until the o(1) scheduler was released.
steve
As for scaling past 4 CPU's, that was much more true before 2.4. While it's still not going to scale linearly to an infinite number of processers, improvements along the way in the 2.4 series and the o(1) scheduler have helped out quite a bit.
I do believe that much of the non-scaling of Linux past 4 CPU's is, to some extent, actually the fault of the hardware, as the great majority of multiprocesser hardware has bottlenecks that impeded linear scaling.
As a simple example, take a look at the dual P4 Xeons on the 533 MHz bus. Sounds spiffy, right? Well, you're splitting the 533 FSB and memory busses between both processers, giving each one an effective *266 MHz* when under load. Seeing as how even the slowest single-proc P4 has a 400 MHz FSB, you can see off of the bat that you're hitting bottlenecks!
Look at the AthlonMP series: Each processer has it's own independent bus! However, the only available motherboards have a single-channel, 266 MHz memory architecture. That gives each processer only 133 MHz effective memory bus under load. The simple addition of a dual-channel memory controller (like the one on the NForce boards) would give the AthlonMP's a real shot in the arm.
Now, it may seem like I'm just talking about low-end multiprocesser machines, but here's another example: Even on some of the higher-end machines, there are restrictive bottlenecks. By naming names, I'll only start a flame-war with the zeolots, but suffice it to say that there are $35,000 "high-end" servers that have *less* total memory bandwidth than that $3,000 dual P4 Xeon. That is pretty pathetic!
It's pretty easy to see why someone who didn't realize that could plop $35,000 on a 4-way, big-name machine that had less memory bandwidth than a $3,000 dual P4 machine, see that under load both of them performed similarly, and say "Well, Linux must not scale well."
To make matters worse, the kind of applications that are run on multi-CPU machines tend to be things like RDBMS', which do not lend themselves well to clustering. Here's the catch: Those types of applications tend to be the most memory-demanding. So, take a single P4 with a 533 MHz bus, and install your RDBMS on it. Take a dual P4 Xeon with a 533 MHz bus, and try the RDBMS. You're certainly not going to scale linearly, but that's because you still haven't improved the memory bandwidth.
steve
Wait until you buy some cutting-edge hardware that doesn't yet have full kernel support, *then* see how excited you get about a new release! ; )
steve
I only have one 4-processer machine, but the 2.4 kernels were wonderful on it. It got 2.4.3 when 2.4.3 was hot off of the presses, then ran without reboot or any glitch until it was shut down last month for hardware upgrades. At that point, I put 2.4.21 on it just for fun. Uptime was something like 1.5 years at that point. 2.4.3 is timestamped over 2 years ago, so it could be as long as that.
steve
Our company drop-ships from many different suppliers. None of them have their act together with regards to shipping, but do just well enough to get by on intra-US shipping. However, *none* of them are able to RELIABLY ship outside of the US. That means that we'll LOSE money in headaches, hastles, lost merchandise, and support calls. It's unfortunate, because if these suppliers had their act together, they could exploit a global market, and make more money. There just aren't any suppliers in this market that are able to do it, the exporting is done by smaller fish down the food-chain.
There's also another factor: There are certain geographical areas (which shall remain unnamed) from where there are ten times more fraudulent orders than legitimate orders. In those areas, it's easiest (and usually most profitable) to simply not do business with ANYONE.
steve
I was able to attend the "Windows NT 5.0 Rapid Deployment Conference" in San Jose. One of the talks given mentioned how they found something along the lines of 4,000 memory leaks in the *drivers alone* for NT4.0. REALLY scary.
steve
The neat thing about the P4 2.8 Xeons is that they are hyperthreaded, so one could (try to) argue that really the box is 4 cpu's at once.
Well, I've played with HT, and it's nowhere near 30%. It's not really like having 4 processers, it's like speeding up the two that you have by 1%-5%. just because Linux shows you four processers doesn't mean that it really behaves that way.
'd rather have one box with 4 cpu's (or 2.6, depending on your math) than 4-5 boxes in the room.
Just because he used the stock Intel fans and a noisy SuperMicro case doesn't mean that anyone else would have to!
Now I'm not a network/beowulf geek, but wouldn't the network become the choke point for a distributed system?
Typically, yes. However, some tasks can be split up in such a way that you can send a relatively small amount of data to each node, and have it do a relatively large amount of computation on it. Then, the network isn't a problem. However, as another person pointed out to me, parallelising chess doesn't work as well as I thought it would.
Is it really all that bad? Fitting your OS onto a floppy disk no longer seems terribly important to me. A year or so ago, I built a complete, self-compiling LFS system that would fit onto a 64 meg flash drive. That's a *complete* system, including C libraries, compiler, LVS load-balancer, etc.. With hardware getting faster, larger, and cheaper, being able to fit things on a floppy doesn't seem quite as important.
steve
That the software doesn't (seem) to exist to use a cluster instead.
No, really, this isn't one of the "imagine a Beowolf of these..." posts. Here's my point: For the cost of just one of the *processers* that he bought, you can build an *entire machine*, happily running an AthlonXP 2700+. An ENTIRE MACHINE. So, for the cost of the two processers, you've got two machines. For the cost of the SuperMicro motherboard and chassis, you can build two MORE machines. With the cost for the rest of the stuff, there's a fifth machine thrown in to boot.
So, what will be faster - a dual 2.8 GHz Xeon, or 5 AthlonXP 2700+ machines? My money's on the cluster, for this particular application. The Xeon machine has 533 MHz of total memory bandwidth, split between two processers, effectively 266 MHz each. The AthlonMP systems, with 333 MHz each, would have a combined bandwidth of 1,665 MHz - about three times that of the Xeon system.
To make it better, the Athlon is MUCH better than the P3 OR the P4 for integer work, which makes me wonder why he would choose the P4 in the first place. Furthermore, not only does the Athlon do much more in a clock cycle than a P4, you'd have a combined clock speed of 10.8 GHz with the Athlons instead of the 5.6 GHz of the Xeons. Twice the clock speed, AND more work per cycle!
Now, of course, being able to actually USE that clock speed would be dependent upon actually transmitting the messages back and forth, and efficiently dividing the work between the machines. In this sort of situation, where for any one point in time, there would be a great deal of possibilities to compute, it would seem like it would divide up very well.
steve
So you've gone a year without a crash. Big deal.
I've got a number of dual-proc P3 systems in a rack that have gone for 3+ years without a crash, and not a one of them has ECC. In that time, they've been shut down about 3 or 4 times to move them and for kernel upgrades. I've also got an NT4 machine that hasn't crashed in about 4 years, it's been shut down twice - each time, to be moved to a different building.
Now, don't get me wrong - when something's critical, I do use ECC. But NOT using ECC isn't quite as bad as some people make it out to be.
steve
Here's the easiest solution yet: Distribute your file via BitTorrent. Problem solved!
steve
Put your server in a colocation center. You can normally get deals where you pay for a low bandwidth regularly, but have the ability to burst quite high. As an example, you can be connected to a 100 megabit port on their router, but pay a base rate for, say, 1 or 2 megabits.
If that's not an option, you can always look into per-IP bandwidth limitting and QOS.
steve
RAID controllers
The companies that can't utilize their RAID controllers on a 133/64 pcix bus aren't using PC's anyway. Remember, 133/64 is nearly a gigaBYTE per second, and if you need to move that much, you're probably using a $1,000,000+ server.
HDTV recievers
Not true. HDTV utilizes much less than 100 megabits, around 18 megabits, if I recall.
Ethernet upwards of gigabit
Not true. While it's true that 10gig ethernet isn't much of a reality, it's not because of the bus. It's because (a) 10 gig ethernet over copper only works for a couple of feet, (b) average people have a tendency to dislike fiber, and (most importantly) (c) The average Joe doesn't need it.
Why don't they need it? Well, the average Joe won't even buy a gigabit switch. If you can't even sell them *ONE* gigabit, how are you going to sell them *TEN*?
high-speed tape drives
Again, that's not because of the bus. There are plenty of high-speed busses to choose from, but tape drives are inherantly slow, and unless you're sticking the ultra high-end drives on the slowest bus you can find, the bus isn't going to limit you.
It's all about economies of scale. If practically nobody has a bus that can handle it, you then have to really ramp up the price of the devices just to support the R&D costs, which then makes it harder to sell your product. It is just not the type of endeavor anyone is going go through.
That argument supports MY position more than yours. If it's all about the economies of scale, then it's cheaper for a company to make a 64-bit PCI card that can operate at 33, 66, 100, or 133 MHz, precisely because there is much less R&D. The controllers are already out there, and because it's also compatible with the slower busses, you can reach a larger target audience.
Think about it. You're in charge of making the new XYZ expansion card, which needs gobs of bandwidth. Do you (a) use an existing and fully adequit standard with very low R&D costs and backwards compatibility to boot, or do you (b) blow millions in R&D to try to use some new bus that it will be years before anyone adopts?
I don't expect people to use them because of the prohibitive costs,
It's cheaper to use the faster, existing PCI busses than to come up with new ones.
limited set of devices
They're much less limitted with faster PCI busses than they are with new ones. You can plug a 64-bit PCI device into a 32-bit PCI slot, and it will work, and vice-versa. That is NOT true if you move to a new bus, is it?
Consumers don't have 64-bit PCI slots because there are few 64-bit PCI devices. There are few 64-bit PCI devices because device makers know consumers don't have 64-bit PCI slots.
Please explain how that argument does NOT hold for the new, proposed busses.
steve
First off, I sincerely doubt that number... Ethernet, Firewire, USB2, multiple IDE devices, etc... I'd say a great many users are nearing the high-end of the bus' capabilities.
Back it up with some numbers.
Manufacturers aren't going to make devices that need more bus bandwidth than just about any machines can provide (and mobo makers aren't going to invest in faster buses until devices need more bandwidth, ironically).
Tell me what kind of devices they would come up with. Your argument is starting to sound like "If you build it, they will come." You can't justify a new bus by just saying "Well, SOMEONE might use it." Tell me what kinds of devices these manufacturers are just DYING to make, but don't have the bandwidth for.
Obviously, the answer is "none" because people don't buy things that they can't actually use yet.
That's entirely false. If nobody has a tape backup that will do a gigabyte per second, it's not because they couldn't do it. They *can*, on a PC, with 133/64 pcix. And on other architectures, there are even faster I/O mechanisms. Don't blame the lack of a fast tape on the bus, 'cuz it just ain't true.
for one thing, you see very few 64-bit PCI devices, and I don't expect any home users to have them
You're talking in circles here. You say that we should come up with a faster bus, so that people can take advantage of it. Yet you say that you DON'T expect people to use faster busses that *ALREADY EXIST*, and are very economical to produce.
Face it, busses faster than a 32/33 PCI bus are already here, and have been here for years. Why aren't they on most motherboards? Because people don't want them badly enough to pay for them. If the average Joe would really benefit from a faster PCI bus, then you'd see companies putting them on their motherboards and throwing the sales pitches left and right.
Really. If most people aren't even interested in using a 64-bit PCI bus, then do we really need anything faster?
It isn't easy to choke a gigabit link, but it can be done. The controllers that are on 32/33 PCI busses typically top out somewhere in the 300-500 Mbit region (total throughput, ins and outs)
It sounds like something's not quite right in your setup. Good cards, like the Acenic cards, can easily max out the PCI bus when you're testing *only* the network, and the disk subsystem isn't involved. That means 80-100 MB/s (640-800 mb/s) throughput on a 32/33 bus, and they hit as closely to a gigabit as can be had on a 64-bit bus. If you're only getting a max of 500 mbits/sec, then something's off.
You're moving the choke point around, but not eliminating it. If I've got a series of PCI bridges (careful about your terminology- controller is generally used to refer to an end-point, not the bridge), everything still needs to go through the north-bridge, and if you are hooked up to that with a 32/33 PCI bus- you're majorly choked right there.
Luckily, pretty much ever chipset manufacturer has gotten away from using a 32/33 PCI bus to talk to the northbridge, so that's not a problem.
steve
99% of all home users don't utilize resources that aren't there. In other words, you aren't going to see seriously resource hungry apps becomming popular until the resources are there...
Oh, please. When the average home user never uses more than 1/3 of the bus speed - EVER - there's simply no reason to build something faster. Sure, you could deck out every board with a faster bus, but it still wouldn't matter, they wouldn't use it.
Or, are you suggesting that there are "killer apps", just around the corner, that just won't work for a home user unless he gets a faster PCI bus?
Not "awfully tough" really. Just backup your RAID array to a fast tape (or other backup method).
Umm... show me a tape that can back up 250 megabytes/second. I guarantee that's not in use in home systems. And even if you do have one, no sweat - use a 133 PCIx bus. Now, you're at nearly two gigabytes/second. That means you have to pull a full gigabyte/second from your disk (*minimum* of 26 disks!), and then still pump a gigabyte/second to the tape drive. So, tell me: How many people have a tape drive that can back up a gigabyte per second?
Having said that, perhaps the first task should be speeding-up the interrupt system somehow, so a computer can actually handle all the data it is recieving, without bringing the system to a craw.
That's mostly a problem with gigE, and the problem isn't so much the interrupt system (although it COULD use improvements), it's that gigE is still using the same MTU that 10 megabit ethernet was using. You can get around that if you're using gigE end-to-end, and have nics and switches that support jumbo frames, but relatively few switches do. On the other hand, if you want to be able to handle huge numbers of interrupts, there is a relatively easy way to do it: Use an SMP board. : )
At the same time, maybe you can possibly also be interleaving your own system backup with data from other systems you recieve over your gigibit NIC...
On even a 64/66 PCI bus, there's still plenty of bandwidth for that, until you get to the stratospheric-costing equipment - and even then, 64/133 is still going to handle it easily.
steve
Not quite. To get two full gigabit controllers working full tilt, you will need two ports off of the bridge, and even then, the bridge has to talk to the CPU, so you may be limited by the CPU bus speeds. 2 gigabit controllers running full tilt (full duplex, of course) is 4 gigabit of raw bus bandwidth (not counting overhead, of course).
2 gigabit controllers is 4 gigabits? Assuming that you're really doing a full gigabit in *each* direction on both NICs (and with some gigabit nics, you simply won't), and that you aren't being swamped by interrupts, that's still only ~500 MB/s. barely more than a 64/66 PCI bus. Easily within the reach of a 64/100 bus.
One thing you aren't taking into account is that PCI is a bus
Sure, I did. I never said differently. Perhaps you're forgetting that a lot of motherboards now have more than one PCI controller, and hence, more than one PCI bus? I've got a 4-year old machine that has 4 seperate PCI controllers, of varying speeds and widths. That means that you don't need to put all of your high-bandwidth devices on the same bus, giving you more total bandwidth, and less overhead/contention from sharing.
But PCI is not used solely for outside bandwidth
Aside from disks, pretty much anything you'll hook to a PCI bus that uses any significant bandwidth is going to be to the outside. Sure, your USB, serial, and even ISA busses are usually done through bridges on a PCI bus... but how much bandwidth do they use? Not a whole lot. The real bandwidth users are disks, with networks in second, and the rest far in the distance.
I'd really like to see more optical interconnects- but the infrastructure is just too expensive. People aren't willing to buy it, and far too expensive to put on a motherboard (Are you willing to pay $1500-$2000 per motherboard?)
One of us must be incredibly mistaken. $1500 for optical interconnects? Optical interconnects are getting cheap enough that there's even talk of building them right into processers.
Even more than that, going to optical simplifies the routing and circuitry on a motherboard. Instead of having to draw out 32, 64, or 100+ traces, paying close attention to keeping trace lengths similar, and worrying about crosstalk, etc., you draw 2 or 4 traces to your tranceiver, and boom, you're done.
steve
"We" haven't "just begun to realize the depth and tangled nature of the gene pool". "You", and other uninformed consumes, might have.
People who work with genetics have been aware of it for a long, long time. They've been aware of the methods of gene transmission in a LOT of different organisms. In a lot of cases, they EXPLOIT them to get what they want.
Genetics and evolution are some of the least-understood fields. Now, don't get me wrong, nearly everyone *thinks* that they understand them, because they got to do punnit squares in high school biology, and they heard some stuff about Gregor Mendel and Charles Darwin. However, people who actually *do* know any amount of useful, detailed information about them are in incredibly short supply.
To make things worse, finding a *journalist* that has any sort of grasp of the subject they're writing about is an incredibly rare find. By the time these things hit public consumption, they're usually either greatly distorted, or dumbed-down to an incredible degree.
Witness the great hype and hysteria about "mapping the human genome". Sure, it's mapped. And the way it was announced, you'd think that we'd just solved the greatest problem in the world. Quite the contrary... now comes the REAL work, exploring what each gene actually does, and how they work together. It'll take thousands of times more work to get that done. Getting things mapped was the easy part.
steve
PCI has been with us for around ten years now, and is rapidly running out of bandwidth
Are you *sure* it's running out of bandwidth?
The old-time, 10-year old 33 MHz, 32-bit PCI bus is still handles 99% of all home users just fine. However, for the more bandwidth-hungry users, you can increase the width to 64 bits. Not enough? Double the frequency. Still not enough? PCI-X will run them at up to *133 MHz*.
Let's put some numbers to that. On a 32/33 bus, you're looking at a maximum real-world, sustained throughput of about 100 megabytes/second. Double the width, that's 200 megabytes/second. Double the frequency, that's 400 megabytes/second.
Alrighty, then. Nearly a half of a gigabyte per second. That's awfully tough to fill. That will handle two gigabit ethernet controllers running full-tilt, and still have enough bandwidth left over that you'd need at least an INCREDIBLY fast RAID array to fill it.
But, just for fun, let's say it's still not enough. PCI-x, at 133 MHz, will double that *again*, to a full gigabyte per second. On a single controller. You're going to have an *INCREDIBLY* tough time actually using that - you'd be very hard pressed to actually get that much to move over a network and/or disk.
Still, you need more? No sweat. Many boards offer more than one controller. With two PCI-x controllers, that's two gigabytes/second of bandwidth. Not two gigaBITS, but rather two gigaBYTES.
Tyan recently introduced a board that has four gigabit controllers, each on their own PCI-x controller, with an additional 64/133 controller, a 64/100 controller, and a 32/33 controller. Again, let's put some numbers to that:
At 100 MB/s for each of the gigE controllers, that's 400 MB/s right off the bat. Add in the 64/133 controller, that's about 1400 MB/sec. Add in the 64/100, you're looking at about 2200 megaBYTES per second.
Now, really... can *anyone* here raise their hand and say that they could actually *utilize* 2200 megabytes/second of bandwidth to the outside world, either via network or disk?
Despite all of the ideas of the sky falling, PCI has done a very good job for the last decade, and amazingly enough, is still going strong. Strong enough that it will be quite a while before it truly NEEDS to be replaced.
Now, when it *IS* replaced, I'd much rather see the interconnects being optical, not electrical. Instead of cracking open the case, shutting off the power, and trying to wedge yet another card inside (especially in low-height rackmounts), I'd much rather set the device on a shelf, and run a fiber patch cable over to the computer. No shutting down, and a whole lot more simple.
steve
I once worked in an IT department with around 1,000 people. They wouldn't hire the "youngsters", the youngest person there was about 26. In fact, a good number of people were over 40.
I guess it's sort of the opposite of what you were complaining about. : )
steve
If Egypt's government has such a weak grasp, that letting their citizens/subjects think about alternative religions could present "crises", then it looks like they probably have some larger problems to tackle first.
steve