Reprise du message précédent :
En fait il esssaye d'etre "un peu" instable pour que les logiciels détecte les erreurs mais il passe direct du stade rock stable au stade très instable.
 
Burn2> Tu devrais essayer de changer le FSB MHZ par MHZ, 5 ça fait beaucoup.

Voilà c'est exactement ça!    
Ok j'aissayerais +1 ou 2 mhz sur le fsb  

Version 0.13b chez moi:

Sempron 3100+ @ 2589

Erreur détectée en 7 Sec, CPU à 99.3% (PRI NOR)
Erreur détectée en 9 Sec, CPU à 100 % (PRI HAU)
_______________________________________________
Sempron 3100+ @ 2574

Erreur détectée en 59 Sec, CPU à 99.8% (PRI NOR)
Erreur détectée en 3 Sec, CPU à 96.9 % (PRI HAU) 1er test
Erreur détectée en 1 Mn 28 Sec, CPU à 99.9 % (PRI HAU) 2eme test
_______________________________________________
Sempron 3100+ @ 2559

Erreur détectée en 14 Sec, CPU à 99.9% (PRI NOR)
Erreur détectée en 1 Mn 59 Sec, CPU à 99.9 % (PRI HAU)
________________________________________________
Sempron 3100+ @ 2554

Pas d'erreur détectée en 3 Mn, CPU à 99.9% (PRI NOR) 1er test
Erreur détectée en 1 Mn 45 Sec, CPU à 99.8 % (PRI NOR) 2eme test
Erreur détectée en 1 Mn 48 Sec, CPU à 99.9 % (PRI HAU)
________________________________________________
Sempron 3100+ @ 2544

Pas d'erreur détectée en 3 Mn, CPU à 99.8% (PRI NOR)
Pas d'erreur détectée en 3 Mn, CPU à 99.8% (PRI HAU)

Je note que le %CPU est bien meilleur qu'avant, par contre les resultats sont assez irréguliers... je me demande si c'est pas ma RAM pourrie qui met le boxon

L'irrégularité est (malheureusement) tout à fait normale. Globalement, plus le CPU sera instable, plus rapidement il fera une erreur.
Mais à paramétrage identique, d'un test sur l'autre, tu peux avoir des différences de plusieurs minutes (voire plusieurs heures) avant détection d'une erreur. Un PC peut par ex, passer le test OCCT (30min) puis échouer la fois suivante. Ou inversement.
 
Bref tout ça pour dire qu'avec un CPU instable, le bug est aléatoire, aussi bien spacialement que temporellement. Seule la fréquence d'apparition de ces bug change en fonction du niveau d'instabilité. Et plus la fréquence (d'apparition des bug) est élevée, plus la probabilité qu'il apparaisse rapidement est élevé.
 
Concernant le % moyen du CPU, peut-etre as-tu moins de processus mais ça peut s'expliquer autrement : j'ai légèrement modifié la formule (mais pas les mesures) afin qu'elle soit plus précise et ne bug plus dès que ça dépassait les 12h de test (dû à un dépassement d'un entier 32bit).

Ah ouais, j'allais te demander si tu voulais de l'aide mais bon je touche plus à ces langages

La seule aide dont j'ai besoin, c'est de vos feedback

<Supprimé par l'auteur>
cf. Tetedeiench

J'utilise aussi les commandes RDTSC en ASM

moi je monte mon pc ce we, avec o/c d'opty 144 au programme, c'est du symple core, mais je me ferais un plaisir d'utilise ton soft pour determiner la stabilité de ma bete. Et bien entendu tu auras droit a mes FB

Euh, c'est pas plutôt la non-stab qui est demandée

Il ne connait pas le CPU, donc pour déterminer la fréquence max stable du CPU, faut monter jusqu'à instabilité. Et c'est là que c'est interessant.
 
mav54fr> Quand tu seras aux "limites" compare avec Prime95/SP2004/OCCT si possible

Fouge > c'est bien ce que je dis : la non-stab

oki ca roule

Bon moi j'ai testé en vitesse: Dans mon test la version 11 (la 13 étant buggué et j'avais pas la 13b sous la main ) a été plus rapide à détecter les erreur que sp2004, peut-être un coup de chance en tout cas ton algo marche bien, par contre j'ai galérer à le rendre juste stable mon barton M'a fallu 203 mhz de fsb...

<Supprimé par l'auteur>
cf. Tetedeiench

Moi je veux bien pour voir! Si ça ne te dérange pas!  

<Supprimé par l'auteur>
cf. Tetedeiench
 
Il y a avait ici du code (C+ASM) permettant la mesure de la fréquence du processeur avec une très grande précision suivant 2 méthodes.

C++ powa en plus! !! Je retiens Merki  beaucoup. Comme ça je vais pouvoir bosser un peu et apprendre.

christophe _d13> Difficile à dire, je n'ai fait que comparer avec CPUZ. Tout ce que je peux te dire c'est que je me suis permis d'ajouter un 2ème chiffre après la virgule. Toute ce que je veux c'est avoir une précision à +/-0.1MHz ce que je pense avoir atteind.
Sur ma config je suis à +/- 0.005MHz mais sur d'autres, ça peut varier bien plus.
 
Bref, le seul problème que je trouve à ma solution actuelle, c'est que ça tourne que sous Windows. Lors du portage, faudra que je trouve un autre "compteur" à haute précision (bien en-dessous de la ms).
 
edit: tient je vois du QueryPerformanceCounter, comme moi , mais ma solution n'est pas aussi "évoluée" que la tienne.

http://haypo.developpez.com/articl [...] ence_linux ?
 

Oui lire la fréquence dans le fichier, j'avais déjà vu ça
Je ne sais pas si c'est précis&fiable et en plus, cela tient-il compte des CPU à fréquence variable (de type Mobile) ? Et ceux qui change la fréquence via un utilitaire (comme Clockgen sous Windows), c'est remis à jour ?

non, non, en bas, chronomètre ultra précis...
 
lire la fréquence un bête cat /proc/cpuinfo ça le fait Et c'est ce qui est écrit sur la page en question, faut que je change mes lunettes...
[pascal@localhost ~]$ cat /proc/cpuinfo
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 6
model           : 10
model name      : AMD Sempron(tm)
stepping        : 0
cpu MHz         : 2380.925
cache size      : 512 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mp mmxext 3dnowext 3dnow ts fid vid
bogomips        : 4768.25
 
pour les processeurs mobiles je sais pas, les XP-M ne sont pas supportés pour le chgt de fréquence à la volée, donc je peux pas testé

Explication alors :
1) on peut mesurer précisément un temps de calcul à l'aide du RDTSC et de la fréquence (précise de préférence).
2) on peut mesurer la fréquence à l'aide du RDTSC et d'un chronomètre (précis de préférence).
 
Bref pour mesurer la fréquence, il me faut un chronomètre précis. Et toi tu me propose d'utiliser RTDSC+fréquence en tant que chronomètre précis. Or c'est justement la fréquence que je veux calculer
 
edit: en fait sous Linux, je saurais déjà faire, mais c'est bien moins précis que sous windows. C'est là mon problème.

Ah, j'avais pas compris que c'était pour mesurer la fréquence, vu quelle est déjà dispo

En gros : soit je lis en faisant aveuglément confiance, soit je calcul moi-même mais la précision sera > 1MHz.

La faudrait demandé au gurus linux, mais je vois pas pourquoi ce serait faux ? Il ont mis 3 chiffres après la virgule, c'est pas pour rien
 
Pour la mesure du temps:
Tout d'abord, je dois préciser que, du fait de la nature multi-tâches préemptive de Linux, on ne peut pas garantir à un programme en mode utilisateur un contrôle exact du temps. Votre processus peut perdre l'usage du processeur à n'importe quel instant pour une période allant d'environ 20 millisecondes à quelques secondes (sur un système lourdement chargé). Néanmoins, pour la plupart des applications utilisant les ports d'E/S, cela ne pose pas de problèmes. Pour minimiser cet inconvénient, vous pouvez augmenter la priorité (avec nice) de votre programme.
 
C'est mal parti
j'ai pris ça la : http://www.tuxfinder.com/french/HO [...] ort-2.html

Je pense que ça doit etre précis mais que c'est pas fiable dans le sens où ça ne prend p'tet pas en compte les CPU à fréquence variable (les Mobile) ou le fait de changer la fréquence directement sous Linux (dans le cas où c'est possible).

<Supprimé par l'auteur>
cf. Tetedeiench
 
Il y a avait ici du code (C+ASM) permettant la mesure de la fréquence du processeur avec une très grande précision suivant 2 méthodes.

Au fait, c'est quoi ta méthode avec le 8253 ? Jamais entendu parler...
Ca marche partout ?

<Supprimé par l'auteur>
cf. Tetedeiench

Ha ok, je l'utilisais donc sans le savoir. Le tout est le trouver l'équivalant (en terme de précision) du QueryPerformance sous Linux

<Supprimé par l'auteur>
cf. Tetedeiench

J'vais avoir besoin de vous avant que la v0.14 sorte. Voici 7 versions de l'algo (en mode console) :
http://olivier.fouge.free.fr/OCCT/CPU_Burn_size.zip
 
Essayez de me faire un classement de la version la + performante à la moins performante.
Dès que j'aurai assez de feedback (sur un max de CPU différents), j'agirai en conséquence sur la v0.14
 
christophe _d13> merci pour l'info. Je regarderai ça en temps voulu, pour la version linux.

<Supprimé par l'auteur>
cf. Tetedeiench

mais pour la detection d'erreur ?

justement il me semble que c'est la 512k:
 
Sempron 3100+ @ 2589 (3 tests)
 
Burn 32K : Erreur en 18s, 25s,  3s
Burn 64k : Erreur en  6s, 24s, 12s
Burn 128k: Erreur en  4s,  4s,  6s
Burn 256k: Erreur en 17s, 10s,  3s
Burn 512k: Erreur en 11s,  1s,  5s
Burn 1 Mo: Erreur en 18s, 10s, 14s
Burn 2 Mo: Erreur en 11s,  2s, 10s  
___________________________________
Sempron 3100+ @ 2574 (2 tests)
 
Burn 32k : Erreur en  61s, 118s
Burn 64k : Erreur en  52s,  36s
Burn 128k: Erreur en  24s,  57s
Burn 256k: Erreur en   1s,  58s, 26s
Burn 512k: Erreur en  76s,   2s, 31s
Burn 1 Mo: Erreur en  25s,  25s
Burn 2 Mo: Erreur en 110s,   1s, 14s
___________________________________
Sempron 3100+ @ 2559 (2 tests)
 
Burn 32k : Pas d'erreur en 120s, Erreur en  97s
Burn 64k : Pas d'erreur en 120s, Erreur en 104s
Burn 128k: Pas d'erreur en 120s, Erreur en   2s, Pas d'erreur en 120s
Burn 256k: Erreur en        77s, 59s
Burn 512k: Erreur en        16s, 24s
Burn 1 Mo: Pas d'erreur en 120s, Pas d'erreur en 120s
Burn 2 Mo: Erreur en        95s, 46s

<Supprimé par l'auteur>
cf. Tetedeiench

ça marche trés  bien sur les pentium M je confirme étant donné que c'est comme ça que je vérifie que ma fréquence soit juste. Je ne sais pas si c'est super précis mais ça donne bien la fréquence variable en fonction de la charge. Si tu veux des screen fouge!

Au fait j'ai tester mon algo et résultat..... Rien Le calcul de pi n'est même pas assez stressant pour que le processeur fasse des erreurs !(tout du moins le temps que je l'ai laissé tourner)

christophe_d13> Heu oui, au fait, c'est pas la T° qui compte mais la détection d'erreur, avec (si possible) le code erreur associé.
Si tu tests sur une machine stable, c'est normal que tu n'ais pas d'erreur. Il faut tester sur une machine volontairement instable, soit en baissant le Vcore soit en augmentant la fréquence.
 
J'aime bien les feedback comme ceux de shurl
Quoique, il manque 2554 et 2544 mais c'est par manque de temps je suppose.

j ai pas pigé ou faut choisir les truc 128k, 64k..etc
 
moi j ai juste regardé vite fais et j ai entre 1mhz et 5mhz d erreur sur la detection de la frequence, j ai un portable equippé d un sempron socket 754. je ferais des tests d erreur plus tard.