I think he was referring to existing systems not the new "all optical" generation. It's the older systems which aren't all optical that convert to electrical, then route/switch, then convert back to optical.
I disagree with your placement of absolute value on "cpu diagnostics" like AMI diag. They are useful in troubleshooting a system with obviously faulty hardware, and narrowing it down to which hardware is faulty, but are far from a all-inclusive test.
These tools are quite good for finding a CPU problem which is always present. They are WONDERFUL at finding intermittent memory problems. They suck at finding intermittent cpu problems or system load related problems. why? They only test one subsystem at a time (which they have to do if they want to isolate the problem).
System diagnostics, like AMI diag and others, tend test one subsystem of the computer at a time. It does a quick processor check and confirms the FPU doesn't have any documented bugs (ie: test for fdiv bug, F00F bug, etc. Stuff that the linux kernel does on boot anyway), then it does a extensive memory check, then an extensive video check, and maybe an extensive disk check. This will detect most errors in any given subsystem, and will isolate the problem since you are testing it by itself.
It does not however tend to find problems like the ones Tom was experiencing. The ones that only crop up after 20 minutes of combined heavy use of multiple subsystems at the same time. And yes, different problems do occur under these conditions. For example heavy disk access tends to very slightly increase the amount of voltage ripple on the power supply. This may or may not be a problem if all you are doing is reading the disk and checking the bytes. There is the possibility of this causing problems if, say, a memory write happens to be occurring within 20ns of the start of a disk head-seek. Onboard capacitors might level out the voltage problem somewhat, but it might only fall into the trouble zone if several such memory transactions occur within a certain time frame (ie: 50 within 200ms).
Since Tom was actually able to boot the system and run it under light to moderate load tests, I would be very surprised if a simple "one subsystem at a time" system diagnostic detected the problem.
Single-step diagnostics are akin to turning each light in the building on and off 50 times one at a time. This will likely find all problems with burnt out bulbs, bad switches, bad wiring, bad ballasts, etc. This is certainly a very valuable test to perform, but it is by no means all inclusive. You may later discover that turning all 20 lights in one circuit on at the exact same time will cause a circuit breaker to trip as all 20 starter ballasts kick in at the same time.
In case anyone is wondering I did wind up getting an eclipse light. It arrived this morning via UPS (gotta love living close to thinkgeek).
The lighting provided is very nice. There is no screen glare, a moderate pool of light on the computer desk, and quite a bit of extra light that hits the ceiling and illuminates the room.
I really like the light quite a lot, and there are only a few things I can complain about, none of which I consider severe:
The mounting of the unit leaves a little to be desired. It needs to be double-stick-taped to your monitor, and doesn't stand well without. This gets to be a problem when experimenting with positions to put it in. The thick cord sticks directly out of the bottom of the body, and does not get much clearance to bend in (it has to fit between the lamp body and the monitor top) when the lamp body is not leaning forward. If you don't have the base taped down yet, the cord tends to push the lamp over.
It would be really nice to see this unit have a more substantial base so you can experiment with positioning more easily, and have the cord come out of the back of the body, not the bottom.
My other complaint is about the start-up. The lamp flickers pretty violently before becoming stable. No-flicker lamp starting is a pretty common fluorescent technology these days... even turning it off for 20 seconds and back-on half warm will cause a 3-4 strobe flicker.
Use of a warm-white fluorescent tube might also be a welcome change, but that can always be changed by the end user.
This might be true, but then again I am replacing 320w of fluorescent with 75w of incandescent lighting. From the 75w of electrical power it consumes the incandescent will turn a considerable portion of it directly to heat, only producing about ~1000 lumens. The 320w fluorescent bulbs consume more electricity, but also produce substantially less heat and IR from that energy than incandescent do. They probably do produce more heat overall, but it is probably only by a smallish margin. Certianly not as much as 320w-75w =245w. The difference is probably more like 50-100w given the efficiencies of the bulbs.
I think my body being present in the room will make much more of a difference to the AC than those two lighting arrangements.
I never said that the tank would rupture explosively (I casualy glanced on it as a separate concept, but did not go into it in depth, see a bit more at the bottom)
I was taking the possibility of the tank rupturing and spilling the liquid nitrogen into the cabin of the car. it would boil rapidly upon contact with the seats/floor, driving the oxygen out of of the cabin.
I did not claim that this would "happen every time" but it is indeed a possible hazard. The posts above me were claiming that it is pretty safe, and that freezing is the only worry.
Now yes, I do agree with you that a forceful rupture of the tank is unlikely. Unless they are using pressurized liquid nitrogen, like we use at my work. These can be pretty dangerous if the vent valves fail, but they do have the ability to produce hose-lines of pressurized nitrogen gas (which we use it for). I doubt anyone would be crazy enough to use such an item in a car.
Please don't think me foolish enough to belive that all LN tanks will blow up if punctured. I have seen a dewar before.
I work at a "hi tech" company that uses nitrogen gas in considerable quantities to prevent parts from oxidizing (we store them in containers filled with nitrogen gas instead of air). To this end we have several cryogenic liquid nitrogen tanks that are about the size of a 55gal oil drum. These tanks are slowly tapped for a supply of nitrogen gas. To this end I have a fairly good understanding of the hazards of liquid nitrogen.
In the event of a tank rupture (I'm assuming a car would be carrying a good quantity of liquid nitrogen, but perhaps I'm wrong) the hazards from liquid nitrogen are twofold: Freezing and suffocation.
If you are really close to the tank when it ruptures, you have a good chance of getting frozen. If the nitrogen has to fly through air as a thin stream for several feet, it won't likely hurt you. I've had liquid nitrogen poured (purposefully) onto my hand in a pencil thick stream from about 4 feet above it. By the time it had reached my hand it was very close to boiling and vaporized quite rapidly in my hand. It "danced" in my hand like water on a hot skillet (CMA disclaimer: I do not recommend repeating this without a trained cryogenic gas safety expert present, you could be seriously injured if you mess this up). However, having 20 gallons of liquid N dumped in your lap from 1' away would be quite lethal. It is all a matter of range and quantity.
However being in a nice enclosed space like a car presents another hazard from liquid nitrogen. Liquid nitrogen expands a LOT, and strangely does not contain any oxygen. If your nitrogen tank bursts and vents into the cabin of your car, it will drive all the air out of it. If you are unconscious or too dazed to get out of the car quickly you could suffocate very quickly. (it does not take more than 2 or 3 breaths of pure nitrogen before your blood O2 drops enough to make you pass out anyway). The resulting gas is also cold, thus denser than air and will not "float away" on it's own.
Admittedly CO2 presents a much bigger suffocation hazard, but that too is generally not used in enclosed spaces.
I guess I am also ignoring the forceful explosion hazzard caused by the rapid expansion of liquid nitrogen insided an enclosed space, but this post is getting too long:)
A fuller outlook may be had by consulting the international chemical safety card for nitrogen (courtesy of the CDC).
I'm (for some god forsaken reason) lucky enough to have my own office. This office has 2 panels of 4, 40w bulbs each. That's 320w worth of fluorescent lighting in a small (~10x10) office. I find this way too bright (and wasteful of power) and I also find "cool white" fluorescent lighting to be bothersome after a long time (warm white fluorescent are less bothersome to me, must be a red balance thing).
Thus my approach is to use a single 75w desk lamp. This shines light where I need it, is easier on my eyes, and saves 245w all at the same time. If for some reason I need my whole office as bright as the sun (ie: finding a screw lost behind my desk) I turn on the fluorescent units.
Admittedly I could probably save more power by using a small 20w fluorescent desk lamp, but I certainly wouldn't consider my current approach "environmentally unfriendly". It is certainly much more friendly than the typical USA "flood the office senseless with fluorescent lighting."
I am considering ordering and trying out an eclipse light, a specialized indirect 13w fluorescent unit.
Just a little historical perspective (as I recall it, correct me if I'm wrong):
Hotmail was NOT originally created by MS. When it was originally created, it was built on non Microsoft *nix type systems. Microsoft bought hotmail and shortly afterward investigated moving it to NT4.
During their testing they had a hard time getting NT4 boxes to handle the load of hotmail. I'd also say it is safe to assume that the existing hotmail code was written for, and tuned for *nix and not NT, meaning they would need at least some (and probably extensive) re-write to run well on NT. They probably could have moved it to NT at considerable expense, but given the cost and difficulty they decided to leave hotmail as-is. Even though leaving hotmail on *nix systems cost them some face (even MS couldn't get a large scale site to run on NT4), they still decided it would be better to leave well enough alone (for the time being).
Now they have a better (?) version of their flagship OS, and are taking another stab at moving hotmail onto their servers.
Not much of this seems very surprising..
Re:question and a half: (print books ok to export)
on
The Code Book
·
· Score: 2
Printed books generally do not have a problem with export from the US, finding protection under freedom of the press.
It is only digital media that has had a problem, since the argument is that source code on disk is a tool, not an expressive essay. Apparently the assumption is that OCR software doesn't exist outside the US either:)
Hence Applied Cryptography with detailed descriptions of strong algorithms can be exported by US booksellers, since there is no companion CD with it. The CD is sold only directly from the author (in MN), and only to US and Canadian buyers with check or money order drawn from a US bank. The CD is restricted from export, but the book is not. See http://www.counterpane.com/scode.html for more detail.
It is a strange country we live in where what format a book is in has great impact on where you can sell it.
I'm no OS expert, but as best I can figure your largest gains in using 64bits as your native word size in an os come from two things.
One is the ability to address more than 4GB of physical ram (which 32bit addressing is limited to). Linux already does this on alpha's.
The ability to seek more than 4GB into a file (ie: fseek takes a 64bit offset, not a 32bit one). I'm pretty sure alpha linux has this too.
I'm not sure what areas (if any at all) that alpha linux is 32bit where it should be 64, but I've been led to belive it is a full 64bit os (with exceptions of things that *have* to be done in smaller word sizes, like ipv4 addresses.. which must be 32 bit).
I'd agree mostly.. but there are some possible usefulness to this stuff too.
The coffee pot could be turned on by your pc before you wake up. Admittedly you can already buy coffee pots with timers that will do this, but it would be easier if you could get your PC to read what time your alarm clock is set for, and adjust the coffee pot to match.
Another possible use I see is monitoring things. A small temperature sensor in each room of your house, one in the fridge, one in the freezer, etc. Your PC could poll this stuff and email you at the office, or beep to indicate that something is out-of-whack.
The first class of devices controls things, and that's at risk to hackers causing some noticeable damage. But the monitor devices are less of a problem. The worst that can happen there is a hacker disables the monitoring devices.
Even those devices would be better implemented using some form of one-wire serial interface, perhaps with a simple converter box to rs-232. The only advantage to IP is that most computers can speak it, making it more "cross platform". Unfortunately most devicemakers will decide to keep their specs closed so they may as well use a proprietary interface.
I would argue that to assume that an app will scale to four processors is quite ignorant, not the other way arround as you claim. In order to scale nicely to multiple processors your work needs to be dividable amongst processors. Some applications achieve this through threading, and others use multiple processes to get the job done but not all applications are coded to do this. One of the big improvements in the 2.2 kernel was improvements to allow more of the kernel code to spread nicely over multiple cpu's. This work on the kernel is by no means complete, so even the kernel is unlikely to be as scalable as it could be.
Sometimes dividing a job up into multiple tasks to work on multiple processors can even cause a *decrease* in overall performance compared to a single cpu box. This is mostly seen in systems such as the orignial pentium (not ppro or pII) on a HX or similar chipset. This arangement has its l2 cache shared by both processors and accesing it causes somewhat expensive bus contention. Should both processors be working on a computation involving a dataset/codeset much larger than the L1 cpu cache they can degrade performance to a point where it would be faster to remove the extra cpu. Now I'll agree this is a much more difficult condition to create within the ppro/pII processor family, but it does outline that scaling to multiple cpu's is not a trivial task.
But really weather or not it scales to four cpu's efficently isn't the point of the article. As I see it the point is that for this particular test, linux performs better than it's competition on a quad-xeon. This would imply that linux is scaling to the four cpu's better, and taking better advantage of them.
Dual PII is *very* well worth it. Each processor has its own L2 cache and that helps avoid the problems seen in pentium SMP - memory access.
With a dual P1, it is possible to be *slower* even with smp aware code than a single p1 at the same clock.. dual p-133's can be slower than a single p-133.. nonsense you say? Take a memory IO bound process operating randomly and heavily over a 400k dataset and a 128k code loop. Each processor has 8-16k (classic vs mmx) of local L1 cache onboard. Anything not in the L1 cache must be accessed from L2 cache, which is shared between the 2 processors. Acessing the shared cache requires contention against the other processor for control of the memory/l2 cache bus, which is not a trivial overhead. In the case of a large dataset and codeset, dual p1's can be slower than a single p1 of the same clockrate, because most of the time is spent arbitrating access to the l2 cache. Admittedly data/code loops this large aren't common in PC apps.
Even in the *best case* scenario you expect a 70 or 80% boost from the second pentium.. thus dual p-233's would at best perform like a single pentium 413, which is *vastly* slower than a pII-450.
Dual pII's do not suffer this memory contention problem as easily, since each processor has 512k of l2 cache onboard. You'd need a code/dataset significantly larger than 512k to cause the problem (random access over a 3-4meg working dataset and 1-2meg working code loop with lots of weird branching could cause the problem on dual PII's but it's really hard to find real problems with codeloops that big. And even with that, the 512k l2 cache may keep the processors busy enough they aren't in contention for memory all the time.)
Personaly, I'm considering building a SMP p1 system despite these caveats.. but I *know* that under no conditions will it be faster than a pII-450... I'm considering it for the geek factor.
And the intel PII 400's going for ~$300 (US) vs the PII 450's going for ~$480 (US) isn't almost a $200 price gap (source: 3rd lowest price on pricewatch.com). Also looking at most places on a singular basis (memory-man.com and paragoncomp.com among others) most vendors have the PII-450 about $210 over their price for the PII-400... CPU pricing is usualy exponential with clock rate, not linear.. the top few MHz of a particular CPU line often doubles the price of the CPU, while increasing speed by 10%
Slashdot Mirror
I think he was referring to existing systems not the new "all optical" generation. It's the older systems which aren't all optical that convert to electrical, then route/switch, then convert back to optical.
I disagree with your placement of absolute value on "cpu diagnostics" like AMI diag. They are useful in troubleshooting a system with obviously faulty hardware, and narrowing it down to which hardware is faulty, but are far from a all-inclusive test.
These tools are quite good for finding a CPU problem which is always present. They are WONDERFUL at finding intermittent memory problems. They suck at finding intermittent cpu problems or system load related problems. why? They only test one subsystem at a time (which they have to do if they want to isolate the problem).
System diagnostics, like AMI diag and others, tend test one subsystem of the computer at a time. It does a quick processor check and confirms the FPU doesn't have any documented bugs (ie: test for fdiv bug, F00F bug, etc. Stuff that the linux kernel does on boot anyway), then it does a extensive memory check, then an extensive video check, and maybe an extensive disk check. This will detect most errors in any given subsystem, and will isolate the problem since you are testing it by itself.
It does not however tend to find problems like the ones Tom was experiencing. The ones that only crop up after 20 minutes of combined heavy use of multiple subsystems at the same time. And yes, different problems do occur under these conditions. For example heavy disk access tends to very slightly increase the amount of voltage ripple on the power supply. This may or may not be a problem if all you are doing is reading the disk and checking the bytes. There is the possibility of this causing problems if, say, a memory write happens to be occurring within 20ns of the start of a disk head-seek. Onboard capacitors might level out the voltage problem somewhat, but it might only fall into the trouble zone if several such memory transactions occur within a certain time frame (ie: 50 within 200ms).
Since Tom was actually able to boot the system and run it under light to moderate load tests, I would be very surprised if a simple "one subsystem at a time" system diagnostic detected the problem.
Single-step diagnostics are akin to turning each light in the building on and off 50 times one at a time. This will likely find all problems with burnt out bulbs, bad switches, bad wiring, bad ballasts, etc. This is certainly a very valuable test to perform, but it is by no means all inclusive. You may later discover that turning all 20 lights in one circuit on at the exact same time will cause a circuit breaker to trip as all 20 starter ballasts kick in at the same time.
In case anyone is wondering I did wind up getting an eclipse light. It arrived this morning via UPS (gotta love living close to thinkgeek).
The lighting provided is very nice. There is no screen glare, a moderate pool of light on the computer desk, and quite a bit of extra light that hits the ceiling and illuminates the room.
I really like the light quite a lot, and there are only a few things I can complain about, none of which I consider severe:
The mounting of the unit leaves a little to be desired. It needs to be double-stick-taped to your monitor, and doesn't stand well without. This gets to be a problem when experimenting with positions to put it in. The thick cord sticks directly out of the bottom of the body, and does not get much clearance to bend in (it has to fit between the lamp body and the monitor top) when the lamp body is not leaning forward. If you don't have the base taped down yet, the cord tends to push the lamp over.
It would be really nice to see this unit have a more substantial base so you can experiment with positioning more easily, and have the cord come out of the back of the body, not the bottom.
My other complaint is about the start-up. The lamp flickers pretty violently before becoming stable. No-flicker lamp starting is a pretty common fluorescent technology these days... even turning it off for 20 seconds and back-on half warm will cause a 3-4 strobe flicker.
Use of a warm-white fluorescent tube might also be a welcome change, but that can always be changed by the end user.
This might be true, but then again I am replacing 320w of fluorescent with 75w of incandescent lighting. From the 75w of electrical power it consumes the incandescent will turn a considerable portion of it directly to heat, only producing about ~1000 lumens. The 320w fluorescent bulbs consume more electricity, but also produce substantially less heat and IR from that energy than incandescent do. They probably do produce more heat overall, but it is probably only by a smallish margin. Certianly not as much as 320w-75w =245w. The difference is probably more like 50-100w given the efficiencies of the bulbs.
I think my body being present in the room will make much more of a difference to the AC than those two lighting arrangements.
I never said that the tank would rupture explosively (I casualy glanced on it as a separate concept, but did not go into it in depth, see a bit more at the bottom)
I was taking the possibility of the tank rupturing and spilling the liquid nitrogen into the cabin of the car. it would boil rapidly upon contact with the seats/floor, driving the oxygen out of of the cabin.
I did not claim that this would "happen every time" but it is indeed a possible hazard. The posts above me were claiming that it is pretty safe, and that freezing is the only worry.
Now yes, I do agree with you that a forceful rupture of the tank is unlikely. Unless they are using pressurized liquid nitrogen, like we use at my work. These can be pretty dangerous if the vent valves fail, but they do have the ability to produce hose-lines of pressurized nitrogen gas (which we use it for). I doubt anyone would be crazy enough to use such an item in a car.
Please don't think me foolish enough to belive that all LN tanks will blow up if punctured. I have seen a dewar before.
In the event of a tank rupture (I'm assuming a car would be carrying a good quantity of liquid nitrogen, but perhaps I'm wrong) the hazards from liquid nitrogen are twofold: Freezing and suffocation.
If you are really close to the tank when it ruptures, you have a good chance of getting frozen. If the nitrogen has to fly through air as a thin stream for several feet, it won't likely hurt you. I've had liquid nitrogen poured (purposefully) onto my hand in a pencil thick stream from about 4 feet above it. By the time it had reached my hand it was very close to boiling and vaporized quite rapidly in my hand. It "danced" in my hand like water on a hot skillet (CMA disclaimer: I do not recommend repeating this without a trained cryogenic gas safety expert present, you could be seriously injured if you mess this up). However, having 20 gallons of liquid N dumped in your lap from 1' away would be quite lethal. It is all a matter of range and quantity.
However being in a nice enclosed space like a car presents another hazard from liquid nitrogen. Liquid nitrogen expands a LOT, and strangely does not contain any oxygen. If your nitrogen tank bursts and vents into the cabin of your car, it will drive all the air out of it. If you are unconscious or too dazed to get out of the car quickly you could suffocate very quickly. (it does not take more than 2 or 3 breaths of pure nitrogen before your blood O2 drops enough to make you pass out anyway). The resulting gas is also cold, thus denser than air and will not "float away" on it's own.
Admittedly CO2 presents a much bigger suffocation hazard, but that too is generally not used in enclosed spaces. I guess I am also ignoring the forceful explosion hazzard caused by the rapid expansion of liquid nitrogen insided an enclosed space, but this post is getting too long :)
A fuller outlook may be had by consulting the international chemical safety card for nitrogen (courtesy of the CDC).
Thus my approach is to use a single 75w desk lamp. This shines light where I need it, is easier on my eyes, and saves 245w all at the same time. If for some reason I need my whole office as bright as the sun (ie: finding a screw lost behind my desk) I turn on the fluorescent units.
Admittedly I could probably save more power by using a small 20w fluorescent desk lamp, but I certainly wouldn't consider my current approach "environmentally unfriendly". It is certainly much more friendly than the typical USA "flood the office senseless with fluorescent lighting."
I am considering ordering and trying out an eclipse light, a specialized indirect 13w fluorescent unit.
Thinkgeek sells them for ~$40.
The mfg website for this unit appears to be onetech
Neither site mentions the wattage, I found that in a review.
Just a little historical perspective (as I recall it, correct me if I'm wrong):
Hotmail was NOT originally created by MS. When it was originally created, it was built on non Microsoft *nix type systems. Microsoft bought hotmail and shortly afterward investigated moving it to NT4.
During their testing they had a hard time getting NT4 boxes to handle the load of hotmail. I'd also say it is safe to assume that the existing hotmail code was written for, and tuned for *nix and not NT, meaning they would need at least some (and probably extensive) re-write to run well on NT. They probably could have moved it to NT at considerable expense, but given the cost and difficulty they decided to leave hotmail as-is. Even though leaving hotmail on *nix systems cost them some face (even MS couldn't get a large scale site to run on NT4), they still decided it would be better to leave well enough alone (for the time being).
Now they have a better (?) version of their flagship OS, and are taking another stab at moving hotmail onto their servers.
Not much of this seems very surprising..
Printed books generally do not have a problem with export from the US, finding protection under freedom of the press.
:)
It is only digital media that has had a problem, since the argument is that source code on disk is a tool, not an expressive essay. Apparently the assumption is that OCR software doesn't exist outside the US either
Hence Applied Cryptography with detailed descriptions of strong algorithms can be exported by US booksellers, since there is no companion CD with it. The CD is sold only directly from the author (in MN), and only to US and Canadian buyers with check or money order drawn from a US bank. The CD is restricted from export, but the book is not. See http://www.counterpane.com/scode.html for more detail.
It is a strange country we live in where what format a book is in has great impact on where you can sell it.
I'm no OS expert, but as best I can figure your largest gains in using 64bits as your native word size in an os come from two things.
One is the ability to address more than 4GB of physical ram (which 32bit addressing is limited to). Linux already does this on alpha's.
The ability to seek more than 4GB into a file (ie: fseek takes a 64bit offset, not a 32bit one). I'm pretty sure alpha linux has this too.
I'm not sure what areas (if any at all) that alpha linux is 32bit where it should be 64, but I've been led to belive it is a full 64bit os (with exceptions of things that *have* to be done in smaller word sizes, like ipv4 addresses.. which must be 32 bit).
I'd agree mostly.. but there are some possible usefulness to this stuff too.
The coffee pot could be turned on by your pc before you wake up. Admittedly you can already buy coffee pots with timers that will do this, but it would be easier if you could get your PC to read what time your alarm clock is set for, and adjust the coffee pot to match.
Another possible use I see is monitoring things. A small temperature sensor in each room of your house, one in the fridge, one in the freezer, etc. Your PC could poll this stuff and email you at the office, or beep to indicate that something is out-of-whack.
The first class of devices controls things, and that's at risk to hackers causing some noticeable damage. But the monitor devices are less of a problem. The worst that can happen there is a hacker disables the monitoring devices.
Even those devices would be better implemented using some form of one-wire serial interface, perhaps with a simple converter box to rs-232. The only advantage to IP is that most computers can speak it, making it more "cross platform". Unfortunately most devicemakers will decide to keep their specs closed so they may as well use a proprietary interface.
I would argue that to assume that an app will scale to four processors is quite ignorant, not the other way arround as you claim. In order to scale nicely to multiple processors your work needs to be dividable amongst processors. Some applications achieve this through threading, and others use multiple processes to get the job done but not all applications are coded to do this. One of the big improvements in the 2.2 kernel was improvements to allow more of the kernel code to spread nicely over multiple cpu's. This work on the kernel is by no means complete, so even the kernel is unlikely to be as scalable as it could be.
Sometimes dividing a job up into multiple tasks to work on multiple processors can even cause a *decrease* in overall performance compared to a single cpu box. This is mostly seen in systems such as the orignial pentium (not ppro or pII) on a HX or similar chipset. This arangement has its l2 cache shared by both processors and accesing it causes somewhat expensive bus contention. Should both processors be working on a computation involving a dataset/codeset much larger than the L1 cpu cache they can degrade performance to a point where it would be faster to remove the extra cpu. Now I'll agree this is a much more difficult condition to create within the ppro/pII processor family, but it does outline that scaling to multiple cpu's is not a trivial task.
But really weather or not it scales to four cpu's efficently isn't the point of the article. As I see it the point is that for this particular test, linux performs better than it's competition on a quad-xeon. This would imply that linux is scaling to the four cpu's better, and taking better advantage of them.
Dual PII is *very* well worth it. Each processor has its own L2 cache and that helps avoid the problems seen in pentium SMP - memory access.
With a dual P1, it is possible to be *slower* even with smp aware code than a single p1 at the same clock.. dual p-133's can be slower than a single p-133.. nonsense you say? Take a memory IO bound process operating randomly and heavily over a 400k dataset and a 128k code loop. Each processor has 8-16k (classic vs mmx) of local L1 cache onboard. Anything not in the L1 cache must be accessed from L2 cache, which is shared between the 2 processors. Acessing the shared cache requires contention against the other processor for control of the memory/l2 cache bus, which is not a trivial overhead. In the case of a large dataset and codeset, dual p1's can be slower than a single p1 of the same clockrate, because most of the time is spent arbitrating access to the l2 cache. Admittedly data/code loops this large aren't common in PC apps.
Even in the *best case* scenario you expect a 70 or 80% boost from the second pentium.. thus dual p-233's would at best perform like a single pentium 413, which is *vastly* slower than a pII-450.
Dual pII's do not suffer this memory contention problem as easily, since each processor has 512k of l2 cache onboard. You'd need a code/dataset significantly larger than 512k to cause the problem (random access over a 3-4meg working dataset and 1-2meg working code loop with lots of weird branching could cause the problem on dual PII's but it's really hard to find real problems with codeloops that big. And even with that, the 512k l2 cache may keep the processors busy enough they aren't in contention for memory all the time.)
Personaly, I'm considering building a SMP p1 system despite these caveats.. but I *know* that under no conditions will it be faster than a pII-450... I'm considering it for the geek factor.
And the intel PII 400's going for ~$300 (US) vs the PII 450's going for ~$480 (US) isn't almost a $200 price gap (source: 3rd lowest price on pricewatch.com). Also looking at most places on a singular basis (memory-man.com and paragoncomp.com among others) most vendors have the PII-450 about $210 over their price for the PII-400... CPU pricing is usualy exponential with clock rate, not linear.. the top few MHz of a particular CPU line often doubles the price of the CPU, while increasing speed by 10%