Reprise du message précédent :

 
Ben en dehors de limiter les FPS, je vois pas trop comment je pourrais faire

Tu fais varier les fps pour charger à x pourcent (sonde charge gpu)

OCCT 5.3.0.b05 OUT !
 
Changelog :

• UI : Added translatable "Memory" under System Usage and removed "Used"
• UI : Ready for translation

Enjoy !
 
https://www.ocbase.com

On ne pourrait pas imaginer deux tests, à la manière d'OCCT (large pour les erreurs et small pour la chauffe) ?

 
Malheureusement non. Cette sonde n'est pas fiable, et le GPU à 100% peut être en throttle ou non... sans compter le délai de MAJ de la sonde. Je ne peux pas m'appuyer dessus.
 

 
Cela ne marche pas vraiment pareil. En faisant travailler OCCT juste dans les registre du proco, tu maximise la chauffe, en le faisant travailler dans la RAM, tu "diminue" artificiellement la charge en induisant de la latence.
 
Ici, j'ai pas autant de marche de manœuvre, car je fais déjà travailler toute la chaîne.
 
Je peux faire varier le nombre de couches du donut (c'est un gros oignon que vous voyez en fait), je peux faire varier la précision de la texture, mais tout cela n'a pas d'incidence "diminution de la charge" et compagnie.
 
Si par exemple je diminue le nombre de couches du donut, vous obtenez moins de charge en théorie... mais plus de FPS Donc la charge GPU dépend de sa capacité à cracher autant de frame.
 
Bref, pas simple tout ça
 
Je pourrais plus facilement le faire avec un test genre compute shader. Sauf que cela ne fait travailler qu'une partie plus faible du GPU que la 3d, et c'est donc vachement moins efficace.

Je suis en WC full custom, donc le GPU reste en dessous de 50°C
 

 
En limitant les FPS, je dois faire baisser le GPU load vers les 50% pour ne pas atteindre le PWR throttle ... Et même comme ça, la fréquence du GPU comme le GPU power sont très instables (j'oscille entre 1964MHz et 2076MHz pour la fréquence, et 140 et 220W pour la puissance ...)
Je me demande si une charge GPU à 50%, même avec une fréquence et une puissance comparable aux conditions de jeu (avec charge GPU à 100%), permet une détection d'erreur correct ...
 

 
En soit, le problème n'est pas la charge GPU, mais la puissance tirée par la carte. à 50% de charge GPU, j'ai autant de puissance tirée par la carte qu'à 100% de charge GPU sur The Witcher 3    

Ça ne me parait donc pas du tout normal que ta carte throttle...tu as vérifié que les VRM de la CG ne montent pas trop haut eux non-plus ?

Je parle bien de power throttle et pas de thermal throttle
 
D'après ce que j'ai vu, c'est très courant sur l'architecture Pascal. La limite n'est en général pas la température, mais la consommation de la carte...
 
D'ailleurs, pas de sonde thermique pour les VRM sur la plupart des cartes Pascal. Mais mon waterblock fait bien contact avec les VRMs, donc je ne pense pas qu'il y ait de soucis sur la température des VRM.

Tu rentres dans le gros enfumage des constructeurs de carte graphique, tous sans exception.

On te vend une carte capable de débiter des trillions de triangles/machin, sauf qu'en pratique, la carte est pensée avec un fonctionnement mode "Jeux vidéo". A savoir la carte est utilisée à X% de ses capacités, genre 60% maximum, car les 40 autres % sont passés à attendre que le proco se charge de l'IA, du son, des inputs, bref... un fonctionnement en ping pong.

Le donut OCCT, il fait rien de chez rien côté proco. On charge tout sur la carte, et on exécute en boucle. Pas d'IA, pas de son... enfin tu vois.

Et là, tu viens de mettre le doigt sur un truc et je t'en remercie. Si je veux simuler un jeu, il me suffit d'augmenter cette charge proco entre chaque frame. Et là, y a plus que de l'idée, car ce serait le premier test 3d + Cpu dont tu peux paramétrer la charge.

Y a énormément de taff pour faire cela ( je pourrais faire un bête sleep, mais je pourrais aussi inclure des cycles de CPU:OCCT ), mais l'idée est très très bonne.

En fait, mon post décrit mon raisonnement

Bien, tu peux donc officiellement faire passer la nana qui dance toutes les x frames pour ralentir la charge ;-)
Sans les poils stp ;-)

 
Sans les poils c'est pas chaud
 

Merci beaucoup pour cette explication  
Ça confirme donc qu'en limitant les FPS, avec ~60% de "charge GPU", on peut donc bien simuler la vraie charge GPU en jeu ?

Cette "charge proco" est faite par qui ? Le CPU ? Dans ce cas, avec un CPU plus puissant, on pourrait récupérer une partie de ces 40% perdus ?

Content d'avoir pu aider  

Conversation tellement chaude que ça continue de les attirer comme des guêpes par la bière

Lol oui
Vanisele vaseline

J'avais oublié, mais la détection d'erreur, sur le test GPU, c'est un peu ce qui permet de tester une carte sans pour autant la faire chauffer comme une dingue, non ?

 
La détection d'erreurs impose le transfert d'une texture de manière périodique du GPU vers le CPU.
 
Ce transfert coûte en termes de perfs et fait effectivement baisser la charge GPU

ptet que c'est plus rapide en pcie4 ^^

OCCT 5.3.0 OUT!
 
Changelog :

• UI : Main window is now fully resizable
• MONITORING : added Min/Max value colums in table view
• MAIN : Improved license and .lang file detection speed
• MAIN : Fixed a bug with some .net framework that are missing a particular registry function
• MAIN : Fixed an issue where OCCT could crash at startup when no graphic card driver was installed
• MAIN : Fixed a display bug with test durations over 24 hours
• Translations : Fixed a bug where putting a corrupt English.lang file next to OCCT.exe could crash the app

Enjoy !
 
https://www.ocbase.com
 
PS : cette version est identique à la précédente beta, avec plus de traductions mises à jour !

 
Tu penseras à forcer le mode occt large Max threads no avx pour les ryzen 3XXX.

Ah, oui, mais pour ça, faut que je fasse une update du monteur de monitoring

Je te dis ça parce que chaced c'est fait avoir quand il a voulu tester occt.  
Il est resté en "auto" et du coup linpack chauffait/consommait plus que occt.
 
En forçant les bons réglages qui sont toujours les mêmes sur le ryzen, il a à nouveau obtenu le résultat habituel de chauffe.

Mince, je voulais dl mais le site est hors ligne.

Ce site est inaccessible www.ocbase.com n'autorise pas la connexion.
Voici quelques conseils :

Vérifier la connexion
Vérifier le proxy et le pare-feu
ERR_CONNECTION_REFUSED

Edit : J'ai réussi à me le procurer ici https://www.techspot.com/downloads/ [...] ad0&file=1

Putain de let's encrypt qui fait crasher apache2...
 
C'est résolu, désolé

 
Actuellement, le mode Auto fait la chose suivante :

 
Je vais changer la règle pour la suivante :

A ta place je rajouterais un mode "auto/best" qui pour un cpu amd prendrait toujours le meilleur réglage à savoir large no avx.  
ça éviterait tout doute.  
 
L'utilisateur qui veut tester autre chose il peut, mais celui qui fait "suivant suivant" aurait au moins le résultat qui fait chauffer le plus le ryzen sans se poser de question.
 
Qu'en penses tu?

C'est ce que j'ai fait
 
OCCT 5.3.1.beta1 out !
Changelog :

• MONITORING : Huge update to the monitoring engine - better readings, newer CPU support
• MONITORING : Updated how the default sensors are picked. New algorithm avoids selecting sensors with readings above max threshold for temperatures !
• CPU:OCCT : Auto mode now disables AVX by default on AMD CPU in all data set sizes
• MAIN : increased the waiting screen width to fit most translation in one line for looks
• Translations : Added Japanese (Big thanks to Masao !)
• Translations : Added Chinese (Simplified) (Thanks QMRQ ! )
• Translations : Added Chinese (Traditional) (Thanks Danfong ! )
• Translations : Added Swedish  (Thanks Nilas ! )

Enjoy !
 
https://www.ocbase.com

Tu pourrais mettre le cpu package pour le graph CPU?
Il est plus élevé que le core:
 

ah au fait.
y'a un truc bizarre chez moi du coté de l'interface.
la CG qu'on voit, c'est pas ma carte principale.....

Le but n'est pas de mettre la t° la plus haute, mais la plus précise - à ma connaissance, c'est le core le plus précis

Tu l'as dans la liste déroulante ?

Le serveur a fait du up& down sur les 10 dernières minutes, mais au moins, cela ne devrait plus planter désormais

Je freeze la 5.3.1 dés maintenant en termes de feature, je pars en vacances et je veux pas lancer une version trop foireuse
 
Objectif : stable d'ici lundi

Good spirit.: j'ai fait de même avant de partir en vacances ;-)

beh oui :
 

 
mais ma carte principale, c'est la 1070.
mais sur l'accueil d'occt, c'est la 970 qui est "vue"
 

Je viens de tester la nouvelle version, joli travail iench et cette interface soviet2.0  
Par contre la possibilité de choisir le soft sur lequel occt exploite les sondes me manque, notamment par exemple pour ma vega64 dont je souhaiterai visualiser son hotspot

Et j'ai eu un petit moment de flippe en voyant le 12v tomber à 11v7 sur le power supply stress test

Ca sera rétabli dans une future version

OCCT 5.3.1 out !
Changelog :

• MONITORING : Huge update to the monitoring engine - better readings, newer CPU support
• MONITORING : Updated how the default sensors are picked. New algorithm avoids selecting sensors with readings above max threshold for temperatures !
• CPU:OCCT : Auto mode now disables AVX by default on AMD CPU in all data set sizes
• MAIN : increased the waiting screen width to fit most translation in one line for looks
• Translations : Added Japanese (Big thanks to Masao !)
• Translations : Added Chinese (Simplified) (Thanks QMRQ ! )
• Translations : Added Chinese (Traditional) (Thanks Danfong ! )
• Translations : Added Swedish  (Thanks Nilas ! )

Enjoy !
 
https://www.ocbase.com
 
PS : 5.3.1.beta1 = 5.3.1

J'aime le popup qui dit qu'une nouvelle version est dipso ^^
Par contre ça serait bien d'enlever la version pour pas se trimballer avec plein d'iônes pour chaque version.
 

salut,
quand est-ce qu'on aura droit à la lecture des tensions 12v, 5v et 3.3v ?
y'a plus de graphiques en fin de test non plus ?
j'ai des soucis en ce moment avec mon pc, et ces valeurs me manquent pour savoir ce que mon alim a dans le ventre.

pour info, c'est p'têt que chez moi, mais la 5.3.1 bouffe 2 fois plus de ressources mémoires et proco que la version 5.3.0 (même sans lancer aucun test)

edit : j'arrive pas à tester ma 2° CG qui n'est relié à aucun écran. c'est normal de ne pouvoir tester que la carte "principale" ?
quand je lance le test, je ne peux choisir qu'une seule résolution, et le test s'arrête au bout de 5s.
merci

Salut,
 
Quand je lance occt 5.3.1 avec linpack 2019, j'ai des périodes où ça tourne à fréquence max et charge CPU 100%, et des périodes où ça descend à la frequence de l'offset AVX et à ce moment là la charge CPU descend à 75% et la temp CPU fait un bond spectaculaire, environ +15° de tous les autres stress test que j'ai, occt compris, y compris les tests utilisant l'AVX.  
 
C'est quoi comme type de calcul?

De retour de congés
 

 
Elles sont déjà lues, probablement pas activées dans l'écran tableau du monitoring.
 
Graphiques en fin de test, faut cliquer sur la petite disquette (si tu as une licence, ou sur les 5 premiers tests).
 

 
Pour la conso des ressources, j'ai rien remarqué, je vais investiguer.
 
Pour la 2nde carte graphique, j'ai assez peu de cas j'avoue, voir t'es le premier, mais cela devrait marcher comme avant
 

 
Linpack C'est un test de source Intel, impossible de t'en dire plus.