Reprise du message précédent :

C'est pas le logiciel qui détruit le matériel, c'est le matériel qui se suicide car mal conçu. Faut voir ça comme une sorte de sélection naturelle

Tu as pas tord mais la sélection naturelle peut revenir chère pour l'utilisateur...
Après c'est vrai que c'est abusé qu'une cg ne soit pas capable d'être utilisé au Max de ses capacités

Mais c'est vrai que 99% des ordinateurs sont mal concu et tombent tous en panne à la moindre ocazion. Faut arrétez les mecs hein, Dell, Acer et tous les autres ne sont pas des escrocs, et à ce titre ils ne vont pas mettre des alim de 500w sur toutes leurs machines alors qu'une 300 suffit !

C'est pas l'alimentation le problème, c'est l'étage d'alimentation interne de la carte qui est en cause. Les VRM, quoi. Et sur le design de référence. Tu auras beau mettre une alimentation de 1500W derrière, la carte fera pouic sous GPU:3D

Et donc, tu achète un GPU capable de 3 trillions de texels/s avec un fillrate de machin, que tu atteindras jamais car en pratique, à 2,2 trillions de texels, ca pouic.

Faut voir quelle types d'alim ils mettent : les noname ont tendance à cramer à la moitié de la puissance affichée Et surtout j'imagine que :
 - tous les assembleurs de se valent pas, certains sont plus sérieux que d'autres
 - certains doivent miser sur le fait que la plupart ses PC (notamment les "bureautiques" ) ne seront jamais utilisés intensivement et que les rares cas où cela arrive, tant pis ça fera partie du petit % de machine qui partira en SAV.

Tant que ça n'engendre pas un taux de panne trop élevé, ça peut valoir le coup de sous-dimensionner certains composants dans le but de faire de économies, être plus concurrentiel, de vendre plus et donc de gagner plus. Ils choisissent le meilleur compromis prix/fiabilité, faut pas croire qu'ils essaient d'atteindre à tout prix le taux de 0%. Donc oui, beaucoup de produits/machines sont mal conçus techniquement (mais bien conçue économiquement) et pourraient défaillir dans certaines conditions, mais cela ne veut donc pas dire qu'ils vont tomber comme des mouches, ils parient justement sur le fait que cela n'arrivera que très peu souvent.

edit: et c'est valable dans pas mal de domaines

dites, si on passes le Large Data, c'est pas obligé de faire un Small Data, si pas de soucis sous Windows?
 
merci

perso je fais large + prime95
le small c'est pour tester + fort le cpu

needless
à moins que tu détailles histoire de faire profiter un peu

Pouic-pouic, l'auteur du "Le cache c'est de la mémoire, donc c'est adressable." ?

Small Data, ça va juste plus stressé/chauffé le CPU, si je me souviens bien
si je passe le Large Data et HyperPI 32M, je vais m'arreté là, tant que j'ai pas de soucis sous Windows
 
merci

et les chargement aléatoire en L1 après Recall_Instruction, que windows aime tant et que [i]Small data Set[i], lui fait se pourrir sur place (à windows) ?

 
j'ai pas compris là

 
bah pas plus tard que l'aut' jour, mon 1090t @ 4047Mhz 1.41v, stable 3h OCCT
et reboot du pc après 20 minutes de prime95

je parle d'une petite action dont Se7en raffole et que Small data set explose en nombre !

Précise bordel ya 5 tests CPU !

 
ok, en générale, si je passe pas Small Data alors que je passe Large Data, c'est qu'il me manque un cran de Vcore
Je verrai si sous Windows j'ai des problèmes
 
merci
 

en load de jeu, en scripts web modernes, quelques applications en MDAC ou .Net assez ancien et une rare variété de sous-couche en B.

 
je verrai en jeu, et web alors, le reste....

 
moi j'en compte que 3 m'enfin c'était en large data set, infini...
impec 3h, mais dis le iench une erreur peut survenir plus tard... dans tous les cas prime95 me trouve souvent des erreurs là où OCCT en large data set m'en trouve pas
pour ça que je commence par tester mon O/C avec OCCT puis prime

Prime95 dans quel mode ? Small, Large, Blend, Custom ? Si custom, quels paramètres ?

En blend le test dur 12h en même temps...
 
En Custom sur les SNB les FFT 1792 et 1344 sont assez contraignant, j'utilise le 1ier pour dégrossir
 
Edit : d'ailleurs OCCT CPU change-t-il de type de calcule suivant le temps, un peu comme prime qui test beaucoup de FFT en blend ? (j'ai aucune idée de comment ça fonctionne )

ah oki je croyais que Norad voulait savoir le test choisi dans OCCT...
bah pour prime je sais pas je lance l'appli et point barre, donc le test par défaut...
Après je me prends peut-être la tête pour rien, si c'est stable 3h OCCT j'ai qu'à considérer comme stable si j'ai pas de soucis en utilisation standard

Pour info, en 4.2.1, je pense modifier un peu GPU:3D pour inclure (attention, je suis pas sûr d'y arriver) un setting pour "brider" l'exécution de GPU:3D. L'idée étant de "simuler" du taff CPU pour "ralentir" le test et pouvoir, via du bidouillage manuel, s'approcher des limites de la carte.

Je pourrais l'automatiser, sauf que la détection des fréquences GPU est loin d'être parfaite, donc du coup, pas dans un 1er temps probablement.

Je suis pas encore sûr d'y arriver, mais je vais essayer

C'est chiant ces systèmes de limite de charge

Et en limitant simplement les FPS pour s'approcher de la limite ?
ça donne rien ?

 
Oui, c'est l'idée, limiter le nombre d'images par secondes de manière soft. Ca sera pas du super efficace, mais ca devrait aller.

Quelles limites  

Je vais passer pour un relou, mais je suis un peu deçus des test OCCT CPU (small, med, large)
 
J'avais jamais de plantage sur ces tests, et pourtant j'avais des crash très souvent sur BF3.
 
Le seul logiciel de Burn qui a reussi à reproduire le plantage de BF3 est Intel Burn Test (LinPack, AVX)
 
Pourtant OCCT LinPack ne plantait pas non plus
 
Le problème était que ma RAM était trop rapide pour mon 2500k (1866mhz, ram pourtant certifié 1866mhz , et même en mettant plus de VTT, plus de vRam etc...)
 
Vu que c'était un problème entre le CPU et la RAM, le Large Data aurais du planter non ?
 
 
Après pour le GPU, rien à dire c'est parfait

Je reste persuadé que ton soucis de ram c'est un soucis de CM

 
Y a plein d'exemples contraires Dis-toi que IntelBurnTest et CPU:LINPACK => pareil. Comme on est dans le domaine de l'aléatoire, la loi de murphy a joué en ma défaveur

C'est surtout que parfois c'est tellement aléatoire et peu franc comme instabilité qu'on peux tourner en rond plusieurs jours/semaines avant de mettre le doigt sur la cause exacte... si on y arrive vraiment.
 
Dans ces cas là, être empirique et changer composant par composant reste le plus rapide et probant.

Pouvoir charger au maximum le GPU avant que celui-ci dépasse une "limite" au-delà de laquelle le GPU baissera en fréquence et annihilera au passage l’intérêt du test.

 
Tout a fait. Je suis pas persuadé que le test pourrait pas charger plus la carte de cette manière.
 
Car si la protec se lance, elle bride le GPU à 50% de sa fréquence (mettons). Si on faisait tourner OCCT à 70%, ca permettrait d'être au dessus sans taper la limite.
 
Ca permettrait aussi de mesurer à quel niveau de performance se situe la bride !

 
Ouai enfin c'est le début d'un nid à bug. Déjà pour le GPU boost vu que l'augmentation et la diminution de la freq. ne se fait pas aux même seuils de conso. et surtout lié aussi à la T°, ça risque d'être plus que délicat pour avoir un algo. rapide et efficace pour trouver le sweet spot.
 
 

 
La 1ère version sera manuelle !
 
Si la détection de fréquence GPU devient bonne, je pourrais implémenter un algorithme de détection qui fonctionnera comme suit :

• Le test se lance à fond. Si la fréquence GPU actuelle est fortement inférieure à celle du mode 3d, je baisse les FPS d'un cran
• Je fais ça en boucle, jusqu'à trouver le "sweet spot", i.e. la fréquence GPU fait un bond en avant

Il faut que je tope une carte qui va bien (faudrait que j'arrive à mettre la main sur une GTX670, elle me dit bien, mais j'hésite à investir tous les dons là dedans, vu qu'il se peut que j'aie des dépenses liées à OCCT bientôt, donc voilà ), pour voir si la bride est dynamique, ou si elle implique un retour au mode 2d entre deux pour se désenclencher.
 
Si le dernier cas est le vrai, je suis baisé, ca restera manuel.
 
Ce qui va être coton, ca va être d'exprimer ça en % de l'algo, et non en fps, ce qui est plus "rationnel" pour un utilisateur, mais bien plus complexe à gérer, surtout quand à cause de la bride, je ne connais pas le 100%

 
Non. Voir topic OC 1155, (fin tu y est déjà), depuis mon posts (1mois ?) ya déjà eu deux personnes qui ce sont ramener avec le même probleme, ram @ 1866mhz et 2500K, et avec des mobals différentes...
 
Idem forum eVGA (mobal eVGA)
Idem forum Corsair (mobal Asus)  
 
....
 
Désolé pour le HS  

IWH page 800 de mon topic
 
Fier

IWH 800
 
La bride se delanche pas à partir d'une x température ?
 
Tu lance le test et tu réduis "la puissance" du test en ce raproche à -1 de la température maximal avant le declanchement de la bride ?

IWH too
 
c'est la ram qui pue avec son incompatibilité alors, j'ai vu des machines stable avec de la ram a plus de 2000. pour moi c'est pas lié au 2500K (j'ai du faire une réponse dans ce gout la sur le topic des SB)
 
Pour la carte graphique, tu peux pas demander a une marque d'avoir une forte réduc ? (ils vont peut être pas la donner non plus )

 
C'est pas juste la température, ca peut être le courant demandé au GPU...
 
Et surtout, je n'ai aucun moyen de connaitre la valeur à ne pas dépasser. Je sais juste quand je la dépasse, parfois, via la fréquence GPU