It's worse than that - the size of the partitions in some of those graphs are the same, but the labels sometimes show different interval sizes. See the 3D performance chart - the left hand interval is 10% (90% to 100%). The remaining intervals - the same physical size on the graph - apparently span 20%.
This sort of blatant graphical manipulation of statistics only undermines their credibility in my book.
The larger the circuit the less yield you will get from the process. To get around this you add circuits to detect and work around these errors - but these corrective circuits are also marred by the same amount of errors as the rest of the wafer. And adding even more redundant circuits eats up more and more of the wafer. And in the end the yields were to low to make it commercially viable.
It should be pointed out that redundant circuitry is a viable method of dramatically increasing yield - often by several orders of magnitude - depending on the architecture of the circuit. Of course, wafer scale yields without redundancy are generally negligible in the first place (because the chance of having no critical defects in a very large circuit is very small), so several orders of magnitude might not be enough. I should know a little about it, as my PhD was in that area.
Using redundant circuitry, you have some capacity to fix defects in the wafer. This is more useful for regular architectures composed of small functional components, or at least those composed of several instances of each functional component.
If one ignores both power consumption and the possibility of errors in the portions of the wafer containing redundant circuits, redundancy looks like a panacea - simply add as much as you like until you can almost always fix the defects that will occur.
It's never that simple. Those redundant circuits are also likely to contain some defects of their own. You can partly mitigate this by reducing the amount of extra circuitry by moving the detection functionality off the wafer (for manufacturing at least). Since this only has to be done once, there's no point wasting silicon on that. This idea helps, but doesn't solve the problem.
The next step might be to use cleverly designed redundant circuits can tolerate some defects without malfunction, but there is still an associated portion where any defect of sufficient size will break the entire wafer. The more redundancy you add, the more likely there is to be such a defect.
In the end (to a very simple first approximation), it's a tradeoff between redundancy improving the yield of the original circuitry, and decreasing yield due to the possibility of fatal defects in the redundant circuitry - but you're much better off using redundancy than not.
The other point is that most of the algorithms designed to detect and correct defects for most architectures are NP-complete or computationally infeasible (i.e. exponential time complexity or worse). That means they are really hard problems, but also that advances in heuristics might also bring about incremental yield gains.
They're selling for about half price at JavaOne, but to get this price you have to have paid about $1500 to attend the conference. Street price is in the $400-$450 range.
I see release at JavaOne as seeding the developer market (after all, it's a developer version of the JVM).
I'll buy one tomorrow and check it out in person:)
This is where your solution will die. 10 million per day is most emphatically NOT going to be a steady 10k per minute every minute. Net traffic is almost always very peaky. The peak hour might have (say) 20% of the total daily traffic, and within that hour the peak minute might have (say) 10% of the peak hour's traffic -i.e. about 200,000 hits in that peak minute. Most good WebAdmins will do this sort of analysis (or base it on an assumed pseudo-Gaussian distribution over (say) minute intervals) and then design for 3 to 5 times the peak load, so we're talking somewhere around 1 million hits per minute.
Your mileage may vary - different sites have different profiles - but your rough estimate of peak load is derived from poor methodology, and could lead to some nasty surprises
Slashdot Mirror
It's worse than that - the size of the partitions in some of those graphs are the same, but the labels sometimes show different interval sizes. See the 3D performance chart - the left hand interval is 10% (90% to 100%). The remaining intervals - the same physical size on the graph - apparently span 20%.
This sort of blatant graphical manipulation of statistics only undermines their credibility in my book.
It should be pointed out that redundant circuitry is a viable method of dramatically increasing yield - often by several orders of magnitude - depending on the architecture of the circuit. Of course, wafer scale yields without redundancy are generally negligible in the first place (because the chance of having no critical defects in a very large circuit is very small), so several orders of magnitude might not be enough. I should know a little about it, as my PhD was in that area.
Using redundant circuitry, you have some capacity to fix defects in the wafer. This is more useful for regular architectures composed of small functional components, or at least those composed of several instances of each functional component.
If one ignores both power consumption and the possibility of errors in the portions of the wafer containing redundant circuits, redundancy looks like a panacea - simply add as much as you like until you can almost always fix the defects that will occur.
It's never that simple. Those redundant circuits are also likely to contain some defects of their own. You can partly mitigate this by reducing the amount of extra circuitry by moving the detection functionality off the wafer (for manufacturing at least). Since this only has to be done once, there's no point wasting silicon on that. This idea helps, but doesn't solve the problem.
The next step might be to use cleverly designed redundant circuits can tolerate some defects without malfunction, but there is still an associated portion where any defect of sufficient size will break the entire wafer. The more redundancy you add, the more likely there is to be such a defect.
In the end (to a very simple first approximation), it's a tradeoff between redundancy improving the yield of the original circuitry, and decreasing yield due to the possibility of fatal defects in the redundant circuitry - but you're much better off using redundancy than not.
The other point is that most of the algorithms designed to detect and correct defects for most architectures are NP-complete or computationally infeasible (i.e. exponential time complexity or worse). That means they are really hard problems, but also that advances in heuristics might also bring about incremental yield gains.
Cheers, DrMazz.
They're selling for about half price at JavaOne, but to get this price you have to have paid about $1500 to attend the conference. Street price is in the $400-$450 range.
:)
I see release at JavaOne as seeding the developer market (after all, it's a developer version of the JVM).
I'll buy one tomorrow and check it out in person
Cheers,
DrMazz
Given that they just made computing cycles 4 orders of magnitude cheaper than before, those cycles are suddenly looking a lot less valuable... ;-)
10million is "only" 10,000 a minute
This is where your solution will die. 10 million per day is most emphatically NOT going to be a steady 10k per minute every minute. Net traffic is almost always very peaky. The peak hour might have (say) 20% of the total daily traffic, and within that hour the peak minute might have (say) 10% of the peak hour's traffic -i.e. about 200,000 hits in that peak minute. Most good WebAdmins will do this sort of analysis (or base it on an assumed pseudo-Gaussian distribution over (say) minute intervals) and then design for 3 to 5 times the peak load, so we're talking somewhere around 1 million hits per minute.
Your mileage may vary - different sites have different profiles - but your rough estimate of peak load is derived from poor methodology, and could lead to some nasty surprises
Cheers,
DrMazz.