Reprise du message précédent :

 
ben justement, je me pose la question (c'était sérieux en fait comme remarque). gcc n'est qu'une appli comme une autre. Ses appels au matériel (cpu, ram, etc...) passent par des instructions au kernel non? admettons qu'on o/c le cpu, et que lorsqu'il est occupé à 99% il fait des erreurs. On compile avec gcc (cpu 100%), le cpu fait des erreurs, gcc fait un segfault. Qui lui envoie le signal? le kernel non?
 
je ne suis pas assez spécialiste de l'architecture du système pour l'affirmer, donc si quelqu'un peut confirmer/infirmer  

c'est vrai que j'avais pas vu les choses sous cet angle ;
Je vais essayer un autre exemple pour éliminer le noyau (à défaut d'avoir une réponse à ton objection), si à cause de l'O/C, la RAM produit des erreurs et que gcc introduit du code binaire incorrect dans un programme que l'on compile. à ce mmoment là, le kernel n'intervient pas non ?

ben gcc accède pas directement à la ram non? normalement, l'os (donc ici le noyau) est la surcouche qui permet aux logiciels d'utiliser le matos. donc même dans ce cas, gcc demande un accès mémoire au noyau, qui plante vu que la ram fait des erreurs, et le noyau envoie un segfault non?

Meme si c'est bien ventilé etc etc, overcloqué sont proc ca réduit pas sa durée de vie ?

J'avais une Leadtek (nForce2). J'en ai eu tellement assez des dysfonctionnements aléatoires du réseau (ça marche impeccable pendant 15 jours, puis un jour pas moyen, sans raison apparente, même après un clear CMOS) que j'ai fini par brancher une Realtek à 10? ...

et? c'est quoi le rapport?

Normalement la limite d'o/c entre windows et Linux ne devrait pas être très importante, si le PC est réellement stable sous windows. Quand je dis réellement, ça veut dire que l'on peut balancer autant de tests que l'on veut et que le PC ne dois en aucun cas planter.
 
Mon expérience perso, j'avais un Duron 700@1000 sous XP. Parfaitement stable. En essayant la Mandrake 9.0, j'ai dut descendre à 970 MHz pour rester absolument stable. Bref, il a fallut descendre un peu.
Actuellement, j'ai un P4 2,66@3,1 et un P4C 2,8@3,457. Sur les 2, si j'augmente le FSB d'1 seul MHZ, je ne suis plus 100% stable sous Windows.
Aujourd'hui, le premier ne tourne plus que sous Gentoo, toujours à 3,1 GHz et ne montre absolument aucun signe de faiblesse; il atteind pourtant régulièrement 3 semaines d'uptimes (je sais qu'il y a mieux, mais faut bien rebooter pour changer le kernel). Je n'ai pas essayer de le monter plus sous Gentoo, mais déjà, je n'ai pas eu à le baisser alors que les compilations fréquentes "imposées" par la Gentoo auraient eut raison de lui s'il était instable.
Le P4C à 3,457 est de temps en temps sous Gentoo, idem. Pour lui, je serais moins catégorique sur la stabilité car je ne peux pas lui faire de gros uptime, je reboote très souvent sous XP pour jouer.
 
Néanmoins, je dirais que si dans certains cas tu dois baisser un peu l'o/c, si le PC est réellement stable, il ne doit pas y avoir de raison de perdre trop en o/c.

le plus gros proc s'o/c aussi  

non, tjs beaucoup moins
on gagne tjs bcp sur les proc les plus bas d'une gamme et très peu sur les plus hauts

ca c'est clair, The_fury tu te trompes. Un 3200+ s'overcloquera beaucoup moins qu'un 2500+ qui est le meilleur proc pour o/c.  
 
Pourquoi le 3200+ s'overclocke tres mal ?
parce que AMD a deja poussé au maximum l'architecture du 3200+, c'est d'ailleur pour cette raison que les 3400+ utilise une architecture completement differentes de celle du 3200+ avec une gravure plus fine qui va permettre a AMD de pousser ses proc.

 
+1.
C'est en effet un bon test.
Qt n'est pas mal non plus
Et bien sûr si cela plante, ne pas incriminer GNU/Linux.
 
Pour ma part, sans soucis:
barton2500@3200
duron600@1000

Je suis d'accord, un overclocking "sûr" (donc stable) ne pose aucun problème sous Linux (cf mon Barton 2500@3200 ...)
Quand on abuse, les instabilités apparaissent plus vite sous Linux que sous Windows.