3. the popular notion that running some "highly stressful" test constitutes a complete test, and that any system that passes that is perfect, so any malfunction must come from something other than the system is nonsense. Such a universal "perfect test" is likely far less comprehensive in coverage than is the manufacturer's final test--and that for certain is far from complete in coverage, and escapees reach the wild at an appreciable rate.
I often wonder what testing manufacturers actually did do, and i do look at MTBF figures if i can find them (are they also real?). For example my last build the mobo was Gigabyte (**1) and i believed (am i gullible?) the 168hr testing. Perhaps other makers test their stuff longer, or the 168 hour test was more marketing than engineering.
**1 - I'm tempted to write to Gigabyte and say ... if you have a thousand mobos and gpus testing, why not do some crunching for E@H?
For any very large chip, such as a substantial microprocessor, GPU, RAM, or such, you can be sure that a very substantial test has been passed somewhere between wafer fabrication and you, or the fraction not working in first simple use would be far higher than it is. It is less clear to me that a comprehensive functional test by the final product assembler adds much value in the case that the chip specs are being complied with. However if the product assembler brags about violating the specs (which is what overclocking is), then they had better be attempting very thorough functional testing at an operating envelope a bit outside that proposed to be customer suitable. I don't know who writes test code for Nvidia parts, nor whether the people doing tests at the chip, packaged part, and board level share their work or not. I hope they do.
Even though _some_ defects have no effect at all, and others have effects in such rare cases that catching them is very difficult, lots of them are so catastrophic in effect that in the case of a CPU, the system would never boot, for example.
I doubt very much that running Einstein successfully would be anything like a comprehensive test, though until E@H next changed the application code, it might help us out considerably.
Taking my lead from Gary's cheerful assessment, I recently looked over Ryan's results, and it sure does appear that something changed quite dramatically for the better. He has even been lucky enough in quorum partners not to make new inconculsives, though that could change a bit at any moment.
RE: 3. the popular notion
)
I often wonder what testing manufacturers actually did do, and i do look at MTBF figures if i can find them (are they also real?). For example my last build the mobo was Gigabyte (**1) and i believed (am i gullible?) the 168hr testing. Perhaps other makers test their stuff longer, or the 168 hour test was more marketing than engineering.
**1 - I'm tempted to write to Gigabyte and say ... if you have a thousand mobos and gpus testing, why not do some crunching for E@H?
Edit: i just did...
For any very large chip, such
)
For any very large chip, such as a substantial microprocessor, GPU, RAM, or such, you can be sure that a very substantial test has been passed somewhere between wafer fabrication and you, or the fraction not working in first simple use would be far higher than it is. It is less clear to me that a comprehensive functional test by the final product assembler adds much value in the case that the chip specs are being complied with. However if the product assembler brags about violating the specs (which is what overclocking is), then they had better be attempting very thorough functional testing at an operating envelope a bit outside that proposed to be customer suitable. I don't know who writes test code for Nvidia parts, nor whether the people doing tests at the chip, packaged part, and board level share their work or not. I hope they do.
Even though _some_ defects have no effect at all, and others have effects in such rare cases that catching them is very difficult, lots of them are so catastrophic in effect that in the case of a CPU, the system would never boot, for example.
I doubt very much that running Einstein successfully would be anything like a comprehensive test, though until E@H next changed the application code, it might help us out considerably.
Taking my lead from Gary's cheerful assessment, I recently looked over Ryan's results, and it sure does appear that something changed quite dramatically for the better. He has even been lucky enough in quorum partners not to make new inconculsives, though that could change a bit at any moment.