Zum nVidia-GPU-Client (erklärende) Statements von Mr. Pande zum Core 1.19 und den neuen, großen Workunits:
Questions regarding core_13 (und andere Threads, siehe jeweils die Posting-Quelle)
Ausschnitte (
keine Chronologie):
- "First, the NV core does really well compared to ATI for small proteins. However, we're moving to larger proteins and there NV has less of an advantage. (...) One final comment: NV core_13 and core_11 are now in sync. This project was released with core_13 as a test, but then was moved through QA and is now a production project." (Post)
- "... for now v1.19 is much more stable than its predecessors for the bulk of donors (...)" (Post)
- "The PPD was unnaturally high for NV for small WUs. This has been discussed in great detail in other threads. The PPD loss is mainly due to the change in project, not the change in core. The key science update has to do with computing with better precision, i.e. more accurate numerics to keep the results meaningful." (Post)
- "Finally, we are looking into the heating issues people are seeing. It would be useful to hear what temps you're getting." (Post)
- " ... it's worth noting that the heat problem would likely be *worse* with 1.18 than 1.19. The additional optimizations will lead to additional heat. Faster code will run hotter." (Post)
- "Finally, just to give people some insight into our thought process: we're seeing something where the same code works well on some hardware and not at all on others (eg v1.15). We've even seen where this can be fixed by upgrading the PSU w/o changing any software at all. So, at least in that case, it was definitely a hardware issue." (Post)
- "The temperature issue is very much on our minds. In the end, I think the only easy way to fix the temperature issue in software is to under-optimize the core (spend less time computing, eg sleep() for a little bit here and there). We're looking to see how we can do this. This would also be the equivalent to underclocking in a sense, so that may be an option for some (especially those who are already over clocked, but maybe others too)" (Post)
- "We may release an optional binary similar to 1.18 which would allow such testing in the future." (evtl. GX2-Spezialfall, Post)
Gerade der letzte Aspekte des absichtlichen De-/Unter-Optimieren (Peiorieren ?
) für die Temperatur-Absenkung wäre m.E. ein bedauerlicher Schritt, doch zeigt diese Notlösung die Grenzen der Hardware (negativ) bzw. die (positive) Grenzüberschreitung der Software-Entwickung auf. Schade nur, wenn man gezwungen ist, die Leistungsfähigkeit von Standard-Hardware einzuschränken.
Crunch-as-Crunching-can verliert so seinen Leitcharakter
. In einem FAH-Forumsthread angedeutet war die Vermutung, daß die Temperatur-Probleme vornehmlich auf abweichende Hersteller-Umsetzung von Standard-/Referenz-Designs beruhen. Persönlich setzt ich drei Mal Referenz-Designs ein, trotz (hohem) Overclocking hatte ich keine ernsthaften, schon gar nicht dauerhafte Temperatur-Probleme. Mhm.
slegrand (NVIDIA Development Team Member) hat einen aufschlußreichen Kommentar zu Unterschieden von nVidia-Grafikkarten hinsichtlich ihrer FAH-Eignung und Fehlerhäufigkeiten abgegeben, das meiste bleibt (leider) ungeklärt, doch - scheint es - nicht unlösbar:
Re: Culprit found in NV core v 1.15 issues for certain hardware?Zusammenkommen ist ein Beginn, Zusammenbleiben ist ein Fortschritt, Zusammenarbeiten ist ein Erfolg.
Henry Ford
) hatte ich die Temperaturen über die letzten Monate immer wieder dokumentiert, sie schwankten je nach Projekt, Atom-Zahl und Aussentemperatur zwischen 85 und 105 Grad GPU-Temperatur, gemessen mit Rivatuner, der Lüfter ist seit jeher auf max. 55% eingestellt, um die Lautstärke zu bändigen.
