Reprise du message précédent :

Ce qui est absurde aujourd'hui le sera encore demain

Il me tarde que la version  2 soit  totalement finie.  
Mais un onglet avancé pour gérer plus finnement le fonctionnement clairement intéressant.  
Souvent le problème est que tu vois une erreur mais qui est en faute?

merchi.    

 
Ahh, sortie du contexte ça change... Mais bon y a matière à confusion dans ma phrase, je l'admets. Je parlais d'éteindre le PC après une faute, fonction qui pourrait être implémentée plus tard. Alors je l'édite pour qu'elle reflète ce que "ma cervelle" pensait    
 

 
 
Satisfait?  

 
Pas de polémique, mais je te promets qu'il n'y a qu'en refléchissant et en allant par étape que tu le sauras. Aucun programme au monde ne te le diras à 100%. Les erreures CPU reportées par les programmes (OCCT ou rounding errors de Prime95) peuvent aussi venir de la memoire, d'un vFSB insuffisant, d'un strap NB trop serré, d'interférences à haut FSB due a un PCB mal fini de la CM, des PWM de la RAM qui merdouillent, des PWM du CPU delivrant une tension parasitée mais detectable seulement a un oscilloscope (même pas un DMM t'y aideras a le detecter), d'un PSU dont le 12v oscille trop en charge, encore une fois invisible sans oscilloscope...
 
Ce qui peut orienter, c'est le small FFT de Prime95 qui reflète beaucoup le CPU (avec ses petits calculs, il se limite au cache interne du CPU et ne sort presque jamais dans la memoire RAM, et ceci à condition d'avoir un minimum de stabilité grossière sur la RAM et NB, sinon ça error aussi
 
Comme t'as l'air convaincu, explique toi plus en détail peut-être. As tu un exemple concret d'une fonction qu'il faut rajouter pour pouvoir determiner la source de l'erreur ou y orienter plus que maintenant. Ca serait interessant de nous developper ton idée peut etre! En dehors d'un log en temps réel a rajouter (que speedfan fait très bien en paralléle) je ne vois pas personellement

jonny_ftm : en fait je fais du WC depuis 5 ans, je connais t'inquiètes. Le mien se fait juste un peu vieux, à l'époque mes pompes c'était le top du top (bon jusqu'à ce qu'on s'aperçoive que la marque fabriquait n'importe comment), plein de mètres de colonne d'eau, idéales pour du HPDC. Mon WB c'est un 1aHV3 donc pas des plus récents, mais je pense qu'avec bcp + de débit (grâce à une Laing) il marchera déjà bien mieux. Là c'est vrai que j'ai un débit très très faible.

 
Fouginounet, y a BEAUCOUP plus simple en fait, et c'est tout con :
 
getTickCount() (qui te renvoie le nombre de ms écoulé depuis le démarrage de windows) n'est pas affecté par le changement d'heure.
 
Du coup, ca devient plus facile

 
lol l'astuce.
J'avait un pot qui avait fait mieux , il afait deux trou ds le chassis de la fenetre du salon ( pour les tuyaux ) et avait foutu sont radiateur ( du WC ) dehors , avec un big big ventilo dessus.
Et bas la seule merde .... c'etait l'été !!!!!!!!!!!!!!!!!! ça servait a pas grand chose vu qu'il fesai plus chaud dehors lol.
Sinon ça fonctionné super , et puis il etait pas embeté par le bruit de la pompe et du ventilo ( radiateur ).
 
pis comme ça la fenetre reste fermé, et memere gueule pas parce que la maison refroidi lol.
 

Je crois que j'ai dû faire comme ça car il me fallait une solution compatible Linux/Windows (c'est p'tet même le compteur de temps de Qt) et ça devait être horloge dépendant.
Faudrait que je revois tout ça, c'est vieux et ça m'avait déjà posé des pb à l'époque.

edit: et sinon t'as testé le GetTickCount() ou c'est juste une intuition ?

 
 
Tu rigoles, mais j'avais vu un truc encore plus dingue chez un ami, quand il avait fait construire sa barraque.
Travaillant dans la clim et l'isolation, il avait fait prevoir dès la maconnerie un emplacement dedié à tout un systeme de clim dans un caisson special, au ras de son balcon, et le PC dans un petit sas attenant.
Tout etait super bien refroidi (comme dans une salle systeme   ), en conservant le PC à la fois accessible en cas de maintenance, totalement isolé des nuisances sonores, et dans un environnement à hygrometrie constante quelle que soit la saison.
Enfin quand je dis PC ; il n'y avait pas de boitier, notamment pour permettre de liberer les peripheriques (CDROM, USB...) et de les rendre accessibles par une sorte de petit "bureau" en bois d'ebenisterie, super bien fait.
Certains de ses elements Hifi/Homecinema profitaient aussi du systeme.
Dommage que je n'ai pas eu d'APN à cette epoque, ca valait le coup d'oeil

 
J'ai testé, ca marche. Je fais l'implémentation là

 
J'ai eu la même idée, et même en été ça marcherait pour moi, car souvent l'été c'est plus mon OC l'important, c'est que je meure pas de chaud dans ma piaule.
 
Mais bon faire des trous dans la fenêtre, bof quoi après on peut plus s'en servir. Moi c'est plutôt dans le mur que je verrais ça. Mais si je me fais chier à percer un putain de mur en béton armé, je crois que ce sera pour mettre la clim'

Ca marche pas mal mon système
 
C'est compliqué ces conneries, mais ca fonctionne pas trop trop mal.

Ok
Si j'ai utilisé ce moyen tordu (enfin pas tant que ça quand même), c'est qu'il y avait une raison valable. Enfin, j'ose espérer
Je regarderai ce soir pour m'en assurer.

 
Ben ca tourne bieng Bon, y a quand même un petit espace temps d'erreur (getTickCount est pas hyper précis), mais c'est pas bézef, et ca a l'air de bien réagir

 
 
 
Ouh Purée ça devai etre sympa !!!
 
Comme ça c'est super efficace et pas de nuisance sonore !!
 
Par contre le cablage il a du rigoler , je connait pas grand chose en connectique mais une rallonge pour ecran , ça doit pas couter deux sous ...ù
Et pour passer tout ça !!!

Je prends un exemple :
1) mon OC CPU est déjà plus que correct et je commence à monter le FSB méga par méga et le Vcore petit à petit.
2) je veux tester mon OC donc je me dis ça donne quoi en temp donc je lance un OCCT en burn léger pour vérifier la temp et si ça tient
3) si OK et si je suis prudent, je lance un burn en médium puis en very hot si toujours OK et ainsi de suite méga par méga et le Vcore petit à petit.
4) pareil pour la RAM
5) si au final tout est OK gros burn de la mort.  
 
Je sais bien qu'il n'y a qu'en réfléchissant qu'on résout ses problèmes d'OC mais quitte à avoir un soft de test, il est intéressant d'avoir du paramétrage disponible pour voir ce qui ce passe.
On laisse un burn finir même avec erreurs pour voir à la fin si il y a corrélation entre les erreurs et l'un des paramètres monitoré.
D'où l'intérêt du log aussi.
Et puis le fait d'avoir un seul soft et aussi un avantage.

 
1) c'est vrai
2) et 3): aucun intéret, un burn full d'emblée est tout ce qu'il faut. Avec ta methode il est plus que choyé le CPU, on a peur de le choquer?A ces fréquences on ne fait plus dans le cocolage du CPU de toute façon. La théorie du burn lent n'est qu'un mythe jamais prouvé si c'est de là que ça vient cette prudence extrème.
4) cf points deux et 3, sauf que OCCT RAM ne va pas dans le coton. Perso, je pense qu'un programme comme OCCT RAM lancé 12h sur une DDR2 a 2.3v, ben elle y perd quelques neurones la barettes. Y a qu'à voir les kits DDR2 grillés dans les forums, surtout les D9. Faut y aller molo. Rapide, bref et efficasse, voilà OCCT en mode RAM. On est vite fixé avec lui et la RAM n'est pas torturée a feu doux une éternité.
5) je mettrais ça en position 1
 
 
Bon, sérieusement, je comprends ce que tu veux dire, mais imagine ce scénario, valable pour la RAM, le CPU, le NB...: La plupart des erreures sont dues a un voltage insuffisant (ok, pas si grave), à un OC poussé au delà des limites physiques du silicone pour une puce donnée (là c'est déjà grave) ou à une température élevée (aussi grave). Il y a en plus les limites de la carte mère: interférences à haut FSB dûe a un PCB mal isolé, étages d'alimentation surchauffants et surchargés qui se mettent a delivrer au CPU et RAM des tensions folles (pics et bas hors normes...).
 
OCCT détecte une erreure pendant que tu dors, il continue, encore une erreure, il continue... Ben je crois qu'en dehors d'un voltage insuffisant, dans tout les autres scénarios, les chances que les composants aillent dans la terre de non retour est important. Conséquence: CPU qui ne s'overclockent plus comme avant, DDR2 qui ne boot plus a 1.8v (la plupart des CM ont des PWM de RAM minables qui survoltent la RAM lorsqu'ils surchauffent...), Penryn 45nm grillés, CM décédée avec étage alim grillé...
 
Fait un tour sur les forums XS et tu verras que ce n'est pas une exception. Franchement, mon avis perso, comme a dit le Iench, une telle fonction est non recommandée. D'ailleurs il doit y avoir une raison si aucun soft a ce jour n'a osé le faire.

Ben, disons que la dichotomie PC stable et PC instable est claire : une erreur.

Je comprends que le nombre d'erreurs puisse avoir un intérêt : si y en a plein, j'y suis allé comme un gros porc... etc.

Je conteste pas cet intérêt.

Ma position est que les effets de bord sont trop nombreux.

On a déjà ceux qui imputent les erreurs détectées par OCCT à des bugs du programme et pas de leur PC. On a ceux qui ne l'utilisent plus car cela fait trop chauffer le CPU, ils préfèrent voir si counter strike tient le choc . On a ceux qui se disent que 2 minutes de burn c'est suffisant. j'ai pas envie de rajouter des gens qui pondent des règles style :
"Si moins de 10 erreurs de calcul OCCT en 1h, alors c'est good, ca plantera jamais"
"Une erreur en 2h de burn ? Ignore-là"

Et compagnie.

Pour le burn léger, c'est déjà le cas. RAM chauffe moins que CPU. Mixte alterne les deux. Je trouve ça pas trop trop mal Du coup, on pourrait renommer les tests comme :

• Temp max
• Mixte
• Detect errors

Un truc du genre.

Je te bassine encore, mais, mon problème CPU-z signalé plus haut y a un espoir de le regler?

Il faut savoir qu'OCCT RAM fait aussi et surtout mal au chipset/FSB. Donc avant de bench ça faut ptet deja voir une ptite passe de memtest si on veut pas s'arracher les cheveux trop longtemps.

 
Je suis d'accord, pour une rigueur d'OC ça devrait se faire. Mais comme j''ai de la peine a laisser tourner sans rien pouvoir faire avec le PC, je réserve memtest au cas ou y a des trucs bizarres qui ne s'arrangent pas ou qui apparaissent alors que small FFT, OCCT RAM et compagnie passent sans problème. J'ai en tout cas bien essayé OCCT RAM: si j'ose toucher le VDDR d'un poil, faire le fier avec mes timings, monter trop les MHz sur la RAM, il me sonne en moins de 10mn. Depuis que j'utilise ce mode, mes OC se font tellement plus vite. Merci le Iench pour ça    
 
Reste un test CPU aussi efficasse en rapidité que ce mode RAM. Y a pas un programme existant qui en est capable. La plupart nécessitent minimum quelques heures pour voir le maximum d'erreures. C'est surement du a la complexité d'un CPU comparé a la RAM (cette dernière peut en effet etre shématisée, en tant que fonction, au seul cache du CPU), donc plus difficile a solliciter dans son ensemble. La RAM est une strcture passive, qui n'a pas de cervelle comme un CPU si on veut bien le dire ainsi. Même Intel Linpack, qui est prometteur sur le papier, est décevant

Sinon, le Iench:
On peut faire de la pub avec liens pour la 2.0 beta 7 ou pas encore, tu avais dis non tout au début, mais cette derniere beta a l'air fiable

 
Aucun. Je me demande si OCCT en mode béta n'utilise pas un pilote plus récent que celui de CPU-Z (suite au blem des descentes de charge CPU).
 
Je ne trouve absolument pas le bug des tensions. je vais essayer de débugguer plus en avant, mais j'promets rieng... ca risque de prendre du temps

Je préfèrerai qu'on attende la fin des bugs et la sortie de la version finale...

Y a eu beaucoup de pub autour de la RC2, et elle a était encore pas mal téléchargée après la sortie de la stable (style 6 mois après).

Faudrait pas la retrouver sur tous les sites de news

La 2.0.0 par contre, j'espère bien qu'elle se retrouvera sur d'excellents sites de niouzes type pcinpact

CPUZ et GPUZ ont droit a une news matbe, organisont une petition pour que OCCT y ai droit aussi    
par contre j'espere que ton hebergeur tient le choc ...... quand tout matbe debarque ca fait du peuple  
(l'année derniere 59hardware plantais 3 fois sur 4 quand matbe faisait un lien chez eux )

 
ok, pas de problème
 
Quel désespoir ces bugs de tensions et CPU-z  

Ben ca a jamais foiré...

j'ai eu droit à pcinpact + yahoo (du coup) lors de la RC2, y a pas eu de souci

C'est qu'un mutualisé OVH. Jamais eu besoin de plus... ca télécharge du binaire, c'est tout

Allez, je file bosser un peu (quand même ! )

 
suffit de mailer presse@matbe.com
 
A votre service
 
Stéphane.

Tetedeiench,
 
Je teste la dernière béta sur une config mono-xeon quad core 45nm, chipset Intel 5400, 16Go de ram (8x2go), et windows xp 64 bits.
 
J'ai remarqué une petite chose :
Dans la liste des t° custom, les températures des puces amb sont nommées "core".
Si j'ouvre Hardware monitor en parallèle, celui-ci me les nomme FB-Dimm->Temperature->Core

Voila g une petite remarque a faire au sujet d'occt beta, qui est excellent au passage  
 
Il y a une seul chose que je trouve dommage, l'alarme "temp cpu maximum" ne prend en compte que les températures coeur 1 à 4, moi je veux par exemple que la sonde CPUTIN de Hwmonitor soit prise en compte par le système d'alarme "temp cpu maximum", ma seul solution c de changer un des coeur 1 à 4 et choisir la sonde en question (CPUTIN) mais voila c pas clair dans les graph ma sonde CPUTIN va s'appeler coeur 1 (c un exemple) dans le graph, moyen quoi et de plus je perd ma temp coeur 1 que je suis obligé d'ajouter en température perso...
 
Sinon je peux aussi ajouter la sonde CPUTIN dans les températures perso, mais les températures perso ne sont pas prises en compte par le système d'alarme "temp cpu maximum"
 
Ma suggestion, ajouter une case a cocher (ou 2 tien) dans température perso pour inclure une des températures perso (ou les 2) dans le système  d'alarme "temp cpu maximum"
La case peut s'appeler simplement ALARME
 
Plus claire au final et graph beaucoup plus juste
 
Alors bien sur c un petit détail, certain vont dire que je chipote, mais moi je trouverais ça très sympa de pouvoir intégrer une ou les 2 températures perso dans le système d'alarme "temp cpu maximum"
système d'alarme que j'affectionne particulièrement
 
PS: LOL je vous explique je me suis trompé de topic, g posté dans le topic de fouge croyant être ici, lol mdr toussa....

 
Pas tant chipotin ça. La température des cores est cependant plus fiable, vu que celle du CPU deconne est est < a température ambiante sur plein de CM, donc elle ne sera jamais haute, mais y a des CM sur lesquelle ça marche donc 4a peut valoir la peine.
 
Pour les températures perso, c'est encore mieux. Certaines CM donnent les températures du NB et de la RAM même, donc, en mode RAM, quand le NB et la RAM grillent, stopper le test est une bonne chose a mon avis aussi. Ca serait don pas si bête de rajouter de telles fonctions

Est ce que ça serait possible de connaitre la taille des paquets maintenant avec la version 2.0b7 en mode CPU? C'est aussi 8-64kb comme sur Prime95 avec 0Mb pour la RAM?

Serait-il possible de mettre à jour la 1ere page?
J'ai cliqué sur un vieux lien : http://www.ocbase.com/news_65.html

Une autre remarque :
 
Lorsqu'on a l'idée saugrenue de donner le même nom à des températures perso, Occt ne génère qu'un seul graph pour les deux.

 
8-128k avec 0Mb de mémoire.

 
Ouaip, faut que je refasse la première page, que je fasse une doc, mais comme tout, c'est le plus long et le moins motivant à faire

Bien vu, je regarde d'où provient l'souci

Attendez-vous à une nouvelle béta courant de cette semaine

edit: mauvais topic.
scuzi

 
Merci, donc tjr assez petit pour ne pas sortir du CPU    
Vivement la prochaine beta, même que mon PC est stable, pour quelques temps. Je vais faire repasser a mon CPU une cure de lapping jusqu'à un grain de 1800. J'éspère que la beta sera là pour faire chauffer la bête