[RAM] Ajout d'une barrette sur portable

Nicolas George

18/08/2007 à 21:36

"G.T" wrote in message <46c73cfe$0$421$:

Je te laisse à tes a-priori qui valent ce qu'ils valent quant à ma
connaissance du sujet ou de mes compétences.

Ce n'est pas un a-priori, puisque c'est basé sur tes propres propos.

fréquemment modifiées, et donc rafraîchies. L'endroit où ce genre d'erreur
se manifeste le plus souvent, c'est le cache disque. Et c'est un endroit
Attends, là tu t'éloignes.

Non, pas du tout, c'est de ça qu'il est question depuis le début : les
erreurs de mémoires invisibles à memtest.

Là c'est un phénomène "d'usure" dû aux écritures
rapides et répétées, c'est physique.

Euh, non, une RAM n'est pas censée avoir ce genre de phénomène,
heureusement, et ce n'est pas ce phénomène qui cause les erreurs dont il est
question ici.

G.T

18/08/2007 à 21:58

Salut,

Là c'est un phénomène "d'usure" dû aux écritures
rapides et répétées, c'est physique.
Euh, non, une RAM n'est pas censée avoir ce genre de phénomène,

heureusement, et ce n'est pas ce phénomène qui cause les erreurs dont il
est

question ici.
Ca se voit mieux sur les supports magnétiques (mais ils n'ont rien à voir au

niveau de la constitution), mais alors c'est quel est donc ce phénomène qui
cause les erreurs auxquelles tu penses ?
Pitié, me dis pas un transitoire.

a+,
--
G.T

Nicolas George

18/08/2007 à 22:33

"G.T" wrote in message <46c74f90$0$422$:

mais alors c'est quel est donc ce phénomène qui
cause les erreurs auxquelles tu penses ?

Je ne suis pas spécialiste en micro-électronique. L'hypothèse la plus
plausible à mon avis, et également à l'avis de mes contacts qui s'y
connaissent mieux, est qu'il s'agit d'une décharge trop rapide du
condensateur qui stocke l'information.

G.T

19/08/2007 à 00:18

mais alors c'est quel est donc ce phénomène qui
cause les erreurs auxquelles tu penses ?
Je ne suis pas spécialiste en micro-électronique. L'hypothèse la plus

plausible à mon avis, et également à l'avis de mes contacts qui s'y
connaissent mieux, est qu'il s'agit d'une décharge trop rapide du
condensateur qui stocke l'information.
Ce qui provoquerait un code (ou si tu préfères une donnée) incorrecte

pendant un petit moment avant que le code soit correct ?

--
G.T

Nicolas George

19/08/2007 à 01:31

"G.T" wrote in message <46c7703f$0$399$:

Ce qui provoquerait un code (ou si tu préfères une donnée) incorrecte
pendant un petit moment avant que le code soit correct ?

Non, ce qui provoque le changement de valeur d'un bit dans la mémoire.

Rappel : la RAM des PC est de la RAM dynamique (le D dans SDRAM), dont le
principe de fonctionnement est de conserver l'information dans un
condensateur. Comme condensateur se décharge progressivement, la valeur de
chaque bit est périodiquement rafraîchie, c'est à dire lue et restockée.

Si à cause d'un défaut de fabrication un condensateur a tendance à se
décharger trop vite, il se peut que sa charge ait atteint la limite où elle
n'est plus considéré comme 1 mais comme 0 (ou le contraire, selon le codage
utilisé, ou si les courants de fuite au contraire chargent le condensateur)
avant que le rafraîchissement ait lieu.

Le résultat visible est que la valeur stockée à un emplacement de la mémoire
va se retrouver avec exactement un bit qui est passé de 1 à 0 (ou
l'inverse), toujours au même endroit.

Si la décharge est vraiment trop rapide, ça se verra immédiatement aux
tests. Si la décharge est assez lente, le rafraîchissement vient toujours à
temps. Mais dans les cas limite, la décharge ne se verra que de temps en
temps. Un rafraîchissement sur un milliard, peut-être, arrivera trop tard,
selon la température, la valeur des bits voisins, etc.

Un rafraîchissement sur un milliard, ça veut dire que le bit défectueux
change de valeur une à deux fois par jour, pour une mémoire de PC commune.

Je ne suis pas certain que c'est exactement ça l'explication
microélectronique, mais elle colle parfaitement avec les symptômes logiciels
que j'ai observés plus d'une fois : un certain octet de la mémoire voit un
bit changer de valeur de temps en temps. Toujours le même bit, à la même
adresse physique.

Pour quiconque est un tant soit peu familier avec le mode de fonctionnement
d'un système d'exploitation moderne, l'idée que ce symptôme soit d'origine
logicielle est tout simplement absurde : le système d'exploitation passe son
temps à allouer et désallouer des pages de mémoire physique, dans un ordre
essentiellement imprévisible, il n'y a aucune chance qu'un bug logiciel
vienne modifier toujours le même emplacement physique.

Ce bit qui a changé de valeur, ce qui est déjà assez rare en soi (sinon, on
l'aurait détecté au memtest), en général, il ne va pas avoir de
conséquence : il tombe dans une page mémoire considérée comme libre, ou dans
un bout du cache disque qui ne va pas servir, et une nouvelle valeur sera
écrite dessus avant qu'il ne soit lu. Ou bien il tombe dans un bitmap, et
change très légèrement la couleur d'un pixel du fond d'écran.

Mais parfois il a des conséquences.

Typiquement, on commence à soupçonner un problème de mémoire quand un
programme se met à crasher déterministement sans qu'on ait rien changé :
c'est signe que le code de ce programme résident en mémoire (ou d'une
bibliothèque partagée qu'il utilise) est corrompu. Évidemment, si quand ça
arrive on a le réflexe de rebooter pour voir si ça va mieux, de fait ça ira
mieux. Mais si on utilise un système où les dysfonctionnements sont assez
rares pour que chacun mérite une investigation approfondie, et qu'on sait
mener cette investigation, il y a moyen d'être sûr.

La première chose à faire est de lancer une vérification de l'intégrité des
fichiers utilisés par le programme en question. Et on va constater que l'un
d'eux ne correspond pas à ce qu'il devrait être.

(Il arrive également que le problème de mémoire se manifeste directement
lors d'une vérification d'intégrité de routine, sans passer par la case
d'observation d'un crash.)

L'étape suivante est de récupérer une version intacte du fichier, et de
comparer : si on constate qu'il y a exactement un bit de différence, c'est
un signe fort.

À ce moment, il faut s'efforcer de trouver l'adresse physique où se trouve
le bit concerné dans l'image en mémoire du fichier.

Quand c'est fait, on peut faire le test de forcer la relecture du fichier
directement depuis le disque, par exemple en invalidant les caches : si
c'est bien un problème de mémoire, le fichier va alors redevenir conforme à
l'original sans qu'aucune modification y ait été apportée.

Si on en est arrivé là, il ne reste plus qu'à demander à l'OS de ne plus
utiliser la page mémoire concernée, et à lancer des tests intensifs dessus.

Ce scénario, j'en ai personnellement fait l'expérience plusieurs (pas
beaucoup, deux ou trois) fois, à peu près comme décrit, à l'époque où je
pensais malin d'économiser sur le prix de la mémoire ; certaines de mes
relations ont eu des expériences similaires. Et les tests intensifs qui ont
suivi ont confirmé le problème.

Ça, c'est le bon cas. Il se peut que la corruption tombe sur un fichier non
pas qui a été lu depuis le disque, mais qui va y être écrit. Si c'est un
fichier compressé, un bit de différence peut avoir des résultats
catastrophiques pour le fichier concerné. Et il peut arriver aussi que ça
tombe sur les données de structure du système de fichiers, et provoquer des
dégâts sur beaucoup de fichiers.

Évidemment, si on considère les différents endroits où la corruption peut
arriver :

- endroit inutilisé ou bien où elle passera inaperçue,
- endroit où elle provoquera un dysfonctionnement visible mais transitoire
(s'en va au reboot, en particulier),
- endroit où elle se retrouve stockée durablement sur le disque sans grave
conséquence,
- endroit où elle se retrouve stockée sur le disque avec de graves
conséquences.

Chaque situation est plus grave que la précédente, mais aussi moins
probable, parce que la fenêtre dans laquelle la corruption doit intervenir
est plus étroite (pour corrompre le superbloc d'un filesystem, il faut
tomber dans les bons 4 ko pendant les 5 secondes où il est gardé en mémoire
avant écriture, pour faire apparaître un carré bizarre pendant deux secondes
sur une vidéo, il y a plusieurs dizaines de minutes et plusieurs centaines
de méga-octets).

Mais ces problèmes sont bien réels. D'ailleurs, dans les architectures
sérieuses dotées de mémoire à détection d'erreur, quand une erreur est
détectée, l'OS décide de planter net, sans plus rien écrire sur les disques
ou échanger sur le réseau. Quand on pense aux conséquences que peut avoir un
bit modifié dans la valeur d'une transaction bancaire, on voit tout de suite
la sagesse de cette mesure.

"G.T" wrote in message <46c7703f$0$399$426a74cc@news.free.fr>:

Ce qui provoquerait un code (ou si tu préfères une donnée) incorrecte
pendant un petit moment avant que le code soit correct ?

Non, ce qui provoque le changement de valeur d'un bit dans la mémoire.

Rappel : la RAM des PC est de la RAM dynamique (le D dans SDRAM), dont le
principe de fonctionnement est de conserver l'information dans un
condensateur. Comme condensateur se décharge progressivement, la valeur de
chaque bit est périodiquement rafraîchie, c'est à dire lue et restockée.

Si à cause d'un défaut de fabrication un condensateur a tendance à se
décharger trop vite, il se peut que sa charge ait atteint la limite où elle
n'est plus considéré comme 1 mais comme 0 (ou le contraire, selon le codage
utilisé, ou si les courants de fuite au contraire chargent le condensateur)
avant que le rafraîchissement ait lieu.

Le résultat visible est que la valeur stockée à un emplacement de la mémoire
va se retrouver avec exactement un bit qui est passé de 1 à 0 (ou
l'inverse), toujours au même endroit.

Si la décharge est vraiment trop rapide, ça se verra immédiatement aux
tests. Si la décharge est assez lente, le rafraîchissement vient toujours à
temps. Mais dans les cas limite, la décharge ne se verra que de temps en
temps. Un rafraîchissement sur un milliard, peut-être, arrivera trop tard,
selon la température, la valeur des bits voisins, etc.

Un rafraîchissement sur un milliard, ça veut dire que le bit défectueux
change de valeur une à deux fois par jour, pour une mémoire de PC commune.

Je ne suis pas certain que c'est exactement ça l'explication
microélectronique, mais elle colle parfaitement avec les symptômes logiciels
que j'ai observés plus d'une fois : un certain octet de la mémoire voit un
bit changer de valeur de temps en temps. Toujours le même bit, à la même
adresse physique.

Pour quiconque est un tant soit peu familier avec le mode de fonctionnement
d'un système d'exploitation moderne, l'idée que ce symptôme soit d'origine
logicielle est tout simplement absurde : le système d'exploitation passe son
temps à allouer et désallouer des pages de mémoire physique, dans un ordre
essentiellement imprévisible, il n'y a aucune chance qu'un bug logiciel
vienne modifier toujours le même emplacement physique.

Ce bit qui a changé de valeur, ce qui est déjà assez rare en soi (sinon, on
l'aurait détecté au memtest), en général, il ne va pas avoir de
conséquence : il tombe dans une page mémoire considérée comme libre, ou dans
un bout du cache disque qui ne va pas servir, et une nouvelle valeur sera
écrite dessus avant qu'il ne soit lu. Ou bien il tombe dans un bitmap, et
change très légèrement la couleur d'un pixel du fond d'écran.

Mais parfois il a des conséquences.

Typiquement, on commence à soupçonner un problème de mémoire quand un
programme se met à crasher déterministement sans qu'on ait rien changé :
c'est signe que le code de ce programme résident en mémoire (ou d'une
bibliothèque partagée qu'il utilise) est corrompu. Évidemment, si quand ça
arrive on a le réflexe de rebooter pour voir si ça va mieux, de fait ça ira
mieux. Mais si on utilise un système où les dysfonctionnements sont assez
rares pour que chacun mérite une investigation approfondie, et qu'on sait
mener cette investigation, il y a moyen d'être sûr.

La première chose à faire est de lancer une vérification de l'intégrité des
fichiers utilisés par le programme en question. Et on va constater que l'un
d'eux ne correspond pas à ce qu'il devrait être.

(Il arrive également que le problème de mémoire se manifeste directement
lors d'une vérification d'intégrité de routine, sans passer par la case
d'observation d'un crash.)

L'étape suivante est de récupérer une version intacte du fichier, et de
comparer : si on constate qu'il y a exactement un bit de différence, c'est
un signe fort.

À ce moment, il faut s'efforcer de trouver l'adresse physique où se trouve
le bit concerné dans l'image en mémoire du fichier.

Quand c'est fait, on peut faire le test de forcer la relecture du fichier
directement depuis le disque, par exemple en invalidant les caches : si
c'est bien un problème de mémoire, le fichier va alors redevenir conforme à
l'original sans qu'aucune modification y ait été apportée.

Si on en est arrivé là, il ne reste plus qu'à demander à l'OS de ne plus
utiliser la page mémoire concernée, et à lancer des tests intensifs dessus.

Ce scénario, j'en ai personnellement fait l'expérience plusieurs (pas
beaucoup, deux ou trois) fois, à peu près comme décrit, à l'époque où je
pensais malin d'économiser sur le prix de la mémoire ; certaines de mes
relations ont eu des expériences similaires. Et les tests intensifs qui ont
suivi ont confirmé le problème.

Ça, c'est le bon cas. Il se peut que la corruption tombe sur un fichier non
pas qui a été lu depuis le disque, mais qui va y être écrit. Si c'est un
fichier compressé, un bit de différence peut avoir des résultats
catastrophiques pour le fichier concerné. Et il peut arriver aussi que ça
tombe sur les données de structure du système de fichiers, et provoquer des
dégâts sur beaucoup de fichiers.

Évidemment, si on considère les différents endroits où la corruption peut
arriver :

- endroit inutilisé ou bien où elle passera inaperçue,
- endroit où elle provoquera un dysfonctionnement visible mais transitoire
(s'en va au reboot, en particulier),
- endroit où elle se retrouve stockée durablement sur le disque sans grave
conséquence,
- endroit où elle se retrouve stockée sur le disque avec de graves
conséquences.

Chaque situation est plus grave que la précédente, mais aussi moins
probable, parce que la fenêtre dans laquelle la corruption doit intervenir
est plus étroite (pour corrompre le superbloc d'un filesystem, il faut
tomber dans les bons 4 ko pendant les 5 secondes où il est gardé en mémoire
avant écriture, pour faire apparaître un carré bizarre pendant deux secondes
sur une vidéo, il y a plusieurs dizaines de minutes et plusieurs centaines
de méga-octets).

Mais ces problèmes sont bien réels. D'ailleurs, dans les architectures
sérieuses dotées de mémoire à détection d'erreur, quand une erreur est
détectée, l'OS décide de planter net, sans plus rien écrire sur les disques
ou échanger sur le réseau. Quand on pense aux conséquences que peut avoir un
bit modifié dans la valeur d'une transaction bancaire, on voit tout de suite
la sagesse de cette mesure.

Vous avez filtré cet utilisateur ! Consultez son message

"G.T" wrote in message <46c7703f$0$399$:

Ce qui provoquerait un code (ou si tu préfères une donnée) incorrecte
pendant un petit moment avant que le code soit correct ?

Non, ce qui provoque le changement de valeur d'un bit dans la mémoire.

Rappel : la RAM des PC est de la RAM dynamique (le D dans SDRAM), dont le
principe de fonctionnement est de conserver l'information dans un
condensateur. Comme condensateur se décharge progressivement, la valeur de
chaque bit est périodiquement rafraîchie, c'est à dire lue et restockée.

Si à cause d'un défaut de fabrication un condensateur a tendance à se
décharger trop vite, il se peut que sa charge ait atteint la limite où elle
n'est plus considéré comme 1 mais comme 0 (ou le contraire, selon le codage
utilisé, ou si les courants de fuite au contraire chargent le condensateur)
avant que le rafraîchissement ait lieu.

Le résultat visible est que la valeur stockée à un emplacement de la mémoire
va se retrouver avec exactement un bit qui est passé de 1 à 0 (ou
l'inverse), toujours au même endroit.

Si la décharge est vraiment trop rapide, ça se verra immédiatement aux
tests. Si la décharge est assez lente, le rafraîchissement vient toujours à
temps. Mais dans les cas limite, la décharge ne se verra que de temps en
temps. Un rafraîchissement sur un milliard, peut-être, arrivera trop tard,
selon la température, la valeur des bits voisins, etc.

Un rafraîchissement sur un milliard, ça veut dire que le bit défectueux
change de valeur une à deux fois par jour, pour une mémoire de PC commune.

Je ne suis pas certain que c'est exactement ça l'explication
microélectronique, mais elle colle parfaitement avec les symptômes logiciels
que j'ai observés plus d'une fois : un certain octet de la mémoire voit un
bit changer de valeur de temps en temps. Toujours le même bit, à la même
adresse physique.

Pour quiconque est un tant soit peu familier avec le mode de fonctionnement
d'un système d'exploitation moderne, l'idée que ce symptôme soit d'origine
logicielle est tout simplement absurde : le système d'exploitation passe son
temps à allouer et désallouer des pages de mémoire physique, dans un ordre
essentiellement imprévisible, il n'y a aucune chance qu'un bug logiciel
vienne modifier toujours le même emplacement physique.

Ce bit qui a changé de valeur, ce qui est déjà assez rare en soi (sinon, on
l'aurait détecté au memtest), en général, il ne va pas avoir de
conséquence : il tombe dans une page mémoire considérée comme libre, ou dans
un bout du cache disque qui ne va pas servir, et une nouvelle valeur sera
écrite dessus avant qu'il ne soit lu. Ou bien il tombe dans un bitmap, et
change très légèrement la couleur d'un pixel du fond d'écran.

Mais parfois il a des conséquences.

Typiquement, on commence à soupçonner un problème de mémoire quand un
programme se met à crasher déterministement sans qu'on ait rien changé :
c'est signe que le code de ce programme résident en mémoire (ou d'une
bibliothèque partagée qu'il utilise) est corrompu. Évidemment, si quand ça
arrive on a le réflexe de rebooter pour voir si ça va mieux, de fait ça ira
mieux. Mais si on utilise un système où les dysfonctionnements sont assez
rares pour que chacun mérite une investigation approfondie, et qu'on sait
mener cette investigation, il y a moyen d'être sûr.

La première chose à faire est de lancer une vérification de l'intégrité des
fichiers utilisés par le programme en question. Et on va constater que l'un
d'eux ne correspond pas à ce qu'il devrait être.

(Il arrive également que le problème de mémoire se manifeste directement
lors d'une vérification d'intégrité de routine, sans passer par la case
d'observation d'un crash.)

L'étape suivante est de récupérer une version intacte du fichier, et de
comparer : si on constate qu'il y a exactement un bit de différence, c'est
un signe fort.

À ce moment, il faut s'efforcer de trouver l'adresse physique où se trouve
le bit concerné dans l'image en mémoire du fichier.

Quand c'est fait, on peut faire le test de forcer la relecture du fichier
directement depuis le disque, par exemple en invalidant les caches : si
c'est bien un problème de mémoire, le fichier va alors redevenir conforme à
l'original sans qu'aucune modification y ait été apportée.

Si on en est arrivé là, il ne reste plus qu'à demander à l'OS de ne plus
utiliser la page mémoire concernée, et à lancer des tests intensifs dessus.

Ce scénario, j'en ai personnellement fait l'expérience plusieurs (pas
beaucoup, deux ou trois) fois, à peu près comme décrit, à l'époque où je
pensais malin d'économiser sur le prix de la mémoire ; certaines de mes
relations ont eu des expériences similaires. Et les tests intensifs qui ont
suivi ont confirmé le problème.

Ça, c'est le bon cas. Il se peut que la corruption tombe sur un fichier non
pas qui a été lu depuis le disque, mais qui va y être écrit. Si c'est un
fichier compressé, un bit de différence peut avoir des résultats
catastrophiques pour le fichier concerné. Et il peut arriver aussi que ça
tombe sur les données de structure du système de fichiers, et provoquer des
dégâts sur beaucoup de fichiers.

Évidemment, si on considère les différents endroits où la corruption peut
arriver :

- endroit inutilisé ou bien où elle passera inaperçue,
- endroit où elle provoquera un dysfonctionnement visible mais transitoire
(s'en va au reboot, en particulier),
- endroit où elle se retrouve stockée durablement sur le disque sans grave
conséquence,
- endroit où elle se retrouve stockée sur le disque avec de graves
conséquences.

Chaque situation est plus grave que la précédente, mais aussi moins
probable, parce que la fenêtre dans laquelle la corruption doit intervenir
est plus étroite (pour corrompre le superbloc d'un filesystem, il faut
tomber dans les bons 4 ko pendant les 5 secondes où il est gardé en mémoire
avant écriture, pour faire apparaître un carré bizarre pendant deux secondes
sur une vidéo, il y a plusieurs dizaines de minutes et plusieurs centaines
de méga-octets).

Mais ces problèmes sont bien réels. D'ailleurs, dans les architectures
sérieuses dotées de mémoire à détection d'erreur, quand une erreur est
détectée, l'OS décide de planter net, sans plus rien écrire sur les disques
ou échanger sur le réseau. Quand on pense aux conséquences que peut avoir un
bit modifié dans la valeur d'une transaction bancaire, on voit tout de suite
la sagesse de cette mesure.

Az Sam

19/08/2007 à 14:19

"speedsoft.nospam" a écrit dans le message de news:
46c58e3e$0$420$

Je suppose que ces assertions gratuites, dont le seul intérêt
est AMHA d'assouvir un inextinguible besoin d'avoir ... le dernier mot,
reposent
sur une expérimentation planifiée et reproductible ! Car tout cela est
truffé d'imprécisions : "une partie", "les semaines.. ou ... les mois"
(peut-être les semestres, les années, les siècles), "ça peut suffire" (ou
ça pourrait suffire... mais... ça suffit pas !)

et c'est reparti... t'es quand meme infatiguable :-))))))))))

--
Cordialement,
Az Sam.

speedsoft.nospam

19/08/2007 à 18:58

"Az Sam" a écrit dans le message de news:
46c83568$0$5113$

"speedsoft.nospam" a écrit dans le message de news:
46c58e3e$0$420$

Je suppose que ces assertions gratuites, dont le seul intérêt
est AMHA d'assouvir un inextinguible besoin d'avoir ... le dernier mot,
reposent
sur une expérimentation planifiée et reproductible ! Car tout cela est
truffé d'imprécisions : "une partie", "les semaines.. ou ... les mois"
(peut-être les semestres, les années, les siècles), "ça peut suffire" (ou
ça pourrait suffire... mais... ça suffit pas !)

et c'est reparti... t'es quand meme infatiguable :-))))))))))

=========== Ben oui, quoi !

Y balance des "Lois" à partir de quelques observations, qu'il "déclare" non
reproductibles.
En fait il s'agit d'un problème d'échantillonage...
Que veux tu, on ne se refait pas..; déformation professionnelle je suppose !

Nicolas George

19/08/2007 à 19:19

"speedsoft.nospam" wrote in message
<46c876d6$0$410$:

Y balance des "Lois" à partir de quelques observations, qu'il "déclare" non
reproductibles.
En fait il s'agit d'un problème d'échantillonage...

Je suis un particulier, je n'ai ni les moyens ni l'envie d'acheter des
centaines de barrettes mémoire et de faire tourner des tests pendant
plusieurs semaines d'affilée. Si toi tu en as les moyens, tant mieux pour
toi.

Cependant, entre mes achats personnels et les achats de quelques personnes
de mon entourage en qui j'ai toute confiance techniquement, j'ai un éventail
assez large d'observations pour me forger une idée extrêmement fiable.

Le point essentiel, c'est que j'ai les compétences techniques nécessaires
pour diagnostiquer à coup sûr un problème de mémoire quand j'en observe un
dans les bonnes conditions. Et les personnes de mon entourage dont je
parlais plus haut également. C'est la condition sine qua non pour accumuler
les observations.

D'après ton discours, tu sembles ne pas avoir ces compétences. L'hypothèse
la plus plausible est donc que tu as souffert de problèmes de mémoire par le
passé, mais que tu ne les as pas identifiés comme tels.

speedsoft.nospam

20/08/2007 à 10:04

"Nicolas George" <nicolas$ a écrit dans le message de
news: 46c87b98$0$401$

"speedsoft.nospam" wrote in message
<46c876d6$0$410$:
Y balance des "Lois" à partir de quelques observations, qu'il "déclare"
non
reproductibles.
En fait il s'agit d'un problème d'échantillonage...

Je suis un particulier, je n'ai ni les moyens ni l'envie d'acheter des
centaines de barrettes mémoire et de faire tourner des tests pendant
plusieurs semaines d'affilée. Si toi tu en as les moyens, tant mieux pour
toi.
Bien sur que non ! Mais la formulation de ta remarque montre la portée

réelle de l'évènement. Car si il faut "des centaines de barettes" à tester
pendant des semaines, quelle est le risque réel au niveau d'une utilisation
quotidienne . De plus tu ne reviens pas sur mes questions du 18/08 1:10, qui
me semblent essentielles pour tirer des conclusions pertinentes ! Dans la
série, quid des mécanismes de contrôle des données écrites sur le disque par
le SE ? Y en a-t-il ? risque pour qu'ils soient "dépassés" lors de
l'écriture de données corrompues ?

Cependant, entre mes achats personnels et les achats de quelques personnes
de mon entourage en qui j'ai toute confiance techniquement, j'ai un
éventail
assez large d'observations pour me forger une idée extrêmement fiable.

C'est exactement ce que disaient "les experts" aux débuts de l'évaluation
des médicaments, sur une dizaine de cas... (Je suis le Pr Dugland vous
pensez bien que s'il le produit est efficace, je le verrai !! -sur une
dizaine de cas.... Il en faut aujourd'hui plusieurs milliers)

Le point essentiel, c'est que j'ai les compétences techniques nécessaires
pour diagnostiquer à coup sûr un problème de mémoire quand j'en observe un
dans les bonnes conditions. Et les personnes de mon entourage dont je
parlais plus haut également. C'est la condition sine qua non pour
accumuler
les observations.

Je ne remets pas en cause tes compétences, pour ce qui est de détecter "UN
événement" problème de mémoire, mais la hiérarchisation généralisée des
conclusions : LES no name posent plus de problèmes que LES "de marque", car
il existe trop de facteurs de variabilité en jeu. C'est exactement comme si
tu disais : j'ai un outil de mesure fiable de la pression artérielle, je
l'ai mesurée chez "quelques personnes" qui prennent du "lobépé". Leur
pression est anormale, c'est donc que le lobépé est un médicament inefficace
!!

D'après ton discours, tu sembles ne pas avoir ces compétences. L'hypothèse
la plus plausible est donc que tu as souffert de problèmes de mémoire par
le
passé, mais que tu ne les as pas identifiés comme tels.

Encore une fois, rien ne te permets de l'affirmer dans la mesure où tu n'as
aucune idée de la fréquence de ce type d'événement dans "mes" conditions
d'utilisation. Car même si l'outil n'est pas "absolu" (lequel l'est ?), le
fait de passer systématiquement les barettes sous memtest pendant plusieurs
heures, permet très vraisemblablement de réduire la population de barettes à
risque !

"Nicolas George" <nicolas$george@salle-s.org> a écrit dans le message de
news: 46c87b98$0$401$426a34cc@news.free.fr...

"speedsoft.nospam" wrote in message
<46c876d6$0$410$426a74cc@news.free.fr>:

Y balance des "Lois" à partir de quelques observations, qu'il "déclare"
non
reproductibles.
En fait il s'agit d'un problème d'échantillonage...

Je suis un particulier, je n'ai ni les moyens ni l'envie d'acheter des
centaines de barrettes mémoire et de faire tourner des tests pendant
plusieurs semaines d'affilée. Si toi tu en as les moyens, tant mieux pour
toi.
Bien sur que non ! Mais la formulation de ta remarque montre la portée

réelle de l'évènement. Car si il faut "des centaines de barettes" à tester
pendant des semaines, quelle est le risque réel au niveau d'une utilisation
quotidienne . De plus tu ne reviens pas sur mes questions du 18/08 1:10, qui
me semblent essentielles pour tirer des conclusions pertinentes ! Dans la
série, quid des mécanismes de contrôle des données écrites sur le disque par
le SE ? Y en a-t-il ? risque pour qu'ils soient "dépassés" lors de
l'écriture de données corrompues ?

Cependant, entre mes achats personnels et les achats de quelques personnes
de mon entourage en qui j'ai toute confiance techniquement, j'ai un
éventail
assez large d'observations pour me forger une idée extrêmement fiable.

C'est exactement ce que disaient "les experts" aux débuts de l'évaluation
des médicaments, sur une dizaine de cas... (Je suis le Pr Dugland vous
pensez bien que s'il le produit est efficace, je le verrai !! -sur une
dizaine de cas.... Il en faut aujourd'hui plusieurs milliers)

Le point essentiel, c'est que j'ai les compétences techniques nécessaires
pour diagnostiquer à coup sûr un problème de mémoire quand j'en observe un
dans les bonnes conditions. Et les personnes de mon entourage dont je
parlais plus haut également. C'est la condition sine qua non pour
accumuler
les observations.

Je ne remets pas en cause tes compétences, pour ce qui est de détecter "UN
événement" problème de mémoire, mais la hiérarchisation généralisée des
conclusions : LES no name posent plus de problèmes que LES "de marque", car
il existe trop de facteurs de variabilité en jeu. C'est exactement comme si
tu disais : j'ai un outil de mesure fiable de la pression artérielle, je
l'ai mesurée chez "quelques personnes" qui prennent du "lobépé". Leur
pression est anormale, c'est donc que le lobépé est un médicament inefficace
!!

D'après ton discours, tu sembles ne pas avoir ces compétences. L'hypothèse
la plus plausible est donc que tu as souffert de problèmes de mémoire par
le
passé, mais que tu ne les as pas identifiés comme tels.

Encore une fois, rien ne te permets de l'affirmer dans la mesure où tu n'as
aucune idée de la fréquence de ce type d'événement dans "mes" conditions
d'utilisation. Car même si l'outil n'est pas "absolu" (lequel l'est ?), le
fait de passer systématiquement les barettes sous memtest pendant plusieurs
heures, permet très vraisemblablement de réduire la population de barettes à
risque !

Vous avez filtré cet utilisateur ! Consultez son message

"Nicolas George" <nicolas$ a écrit dans le message de
news: 46c87b98$0$401$

"speedsoft.nospam" wrote in message
<46c876d6$0$410$:
Y balance des "Lois" à partir de quelques observations, qu'il "déclare"
non
reproductibles.
En fait il s'agit d'un problème d'échantillonage...

Je suis un particulier, je n'ai ni les moyens ni l'envie d'acheter des
centaines de barrettes mémoire et de faire tourner des tests pendant
plusieurs semaines d'affilée. Si toi tu en as les moyens, tant mieux pour
toi.
Bien sur que non ! Mais la formulation de ta remarque montre la portée

réelle de l'évènement. Car si il faut "des centaines de barettes" à tester
pendant des semaines, quelle est le risque réel au niveau d'une utilisation
quotidienne . De plus tu ne reviens pas sur mes questions du 18/08 1:10, qui
me semblent essentielles pour tirer des conclusions pertinentes ! Dans la
série, quid des mécanismes de contrôle des données écrites sur le disque par
le SE ? Y en a-t-il ? risque pour qu'ils soient "dépassés" lors de
l'écriture de données corrompues ?

Cependant, entre mes achats personnels et les achats de quelques personnes
de mon entourage en qui j'ai toute confiance techniquement, j'ai un
éventail
assez large d'observations pour me forger une idée extrêmement fiable.

C'est exactement ce que disaient "les experts" aux débuts de l'évaluation
des médicaments, sur une dizaine de cas... (Je suis le Pr Dugland vous
pensez bien que s'il le produit est efficace, je le verrai !! -sur une
dizaine de cas.... Il en faut aujourd'hui plusieurs milliers)

Le point essentiel, c'est que j'ai les compétences techniques nécessaires
pour diagnostiquer à coup sûr un problème de mémoire quand j'en observe un
dans les bonnes conditions. Et les personnes de mon entourage dont je
parlais plus haut également. C'est la condition sine qua non pour
accumuler
les observations.

Je ne remets pas en cause tes compétences, pour ce qui est de détecter "UN
événement" problème de mémoire, mais la hiérarchisation généralisée des
conclusions : LES no name posent plus de problèmes que LES "de marque", car
il existe trop de facteurs de variabilité en jeu. C'est exactement comme si
tu disais : j'ai un outil de mesure fiable de la pression artérielle, je
l'ai mesurée chez "quelques personnes" qui prennent du "lobépé". Leur
pression est anormale, c'est donc que le lobépé est un médicament inefficace
!!

D'après ton discours, tu sembles ne pas avoir ces compétences. L'hypothèse
la plus plausible est donc que tu as souffert de problèmes de mémoire par
le
passé, mais que tu ne les as pas identifiés comme tels.

Encore une fois, rien ne te permets de l'affirmer dans la mesure où tu n'as
aucune idée de la fréquence de ce type d'événement dans "mes" conditions
d'utilisation. Car même si l'outil n'est pas "absolu" (lequel l'est ?), le
fait de passer systématiquement les barettes sous memtest pendant plusieurs
heures, permet très vraisemblablement de réduire la population de barettes à
risque !

Nicolas George

20/08/2007 à 12:15

"speedsoft.nospam" wrote in message
<46c94b13$0$398$:

De plus tu ne reviens pas sur mes questions du 18/08 1:10, qui
me semblent essentielles pour tirer des conclusions pertinentes !

J'ai dû louper ce message. Je vais voir.

Dans la
série, quid des mécanismes de contrôle des données écrites sur le disque par
le SE ? Y en a-t-il ?

Non. Enfin, évidemment, il y a les mécanismes matériels : la mémoire à
parité, ou encore mieux la mémoire à correction d'erreur. Qui de toutes
façons est de la mémoire beaucoup plus fiable à la base que de la noname.

Des mécanismes logiciels, ce n'est essentiellement pas possible. Déjà, l'OS
ne pourrait vérifier l'intégrité des données que sur l'intervalle de temps
après l'indexation initiale : ça peut réduire la fenêtre sensible, mais mais
il est absolument impossible de la fermer. D'autre part, une telle
vérification aurait un coût absolument faramineux.

C'est exactement ce que disaient "les experts" aux débuts de l'évaluation
des médicaments, sur une dizaine de cas... (Je suis le Pr Dugland vous
pensez bien que s'il le produit est efficace, je le verrai !! -sur une
dizaine de cas.... Il en faut aujourd'hui plusieurs milliers)

Il y a deux différences entre la situation présente et ta comparaison :

- L'évaluation d'un médicament ne demande pas seulement de prouver
l'efficacité, mais aussi de prouver l'absence d'effets secondaires graves.
Ici, le seul effet secondaire, on le connaît déjà : c'est que ça coûte un
peu plus cher.

- Je n'ai pas d'intérêt personnel à convaincre qui que ce soit : je ne vends
pas de mémoire, ni ne touche de commissions sur les ventes de mémoire de
marque plutôt que de mémoire noname.

Je ne remets pas en cause tes compétences, pour ce qui est de détecter "UN
événement" problème de mémoire, mais la hiérarchisation généralisée des
conclusions : LES no name posent plus de problèmes que LES "de marque", car
il existe trop de facteurs de variabilité en jeu.

Mais je n'ai pas parlé de détecter « UN événement » : je l'ai dit, entre mes
achats personnels et ceux de mon entourage, et entre les problèmes constatés
sur le long terme, et ceux qui se voient tout de suite à memtest pour peu
qu'on le laisse tourner assez longtemps, j'ai un échantillon assez large
d'observations. Et la corrélation est tellement marquée que c'est amplement
suffisant.

Après, il y a certains biais dans mon échantillon, par exemple quasiment
toute la mémoire concernée a été achetée dans le 12e arrondissement de
Paris. Mais pour le coup, je ne crois pas une seconde à l'influence que ça
peut avoir.

Encore une fois, rien ne te permets de l'affirmer dans la mesure où tu n'as
aucune idée de la fréquence de ce type d'événement dans "mes" conditions
d'utilisation. Car même si l'outil n'est pas "absolu" (lequel l'est ?), le
fait de passer systématiquement les barettes sous memtest pendant plusieurs
heures, permet très vraisemblablement de réduire la population de barettes à
risque !

Oui, ça la réduit. Mais à la base, je rappelle que la mémoire noname, c'est
de la mémoire qui a été jugée pas assez fiable pour être vendue sous un
label (et une garantie) de marque. En d'autres termes, c'est de la mémoire
qui a déjà échoué des tests plus fiables que memtest.

D'ailleurs, puisque tu fais le test systématiquement, tu peux peut-être nous
éclairer sur tes observations : parmi les barrettes que tu détectes
défectueuses, quelle proportion est noname ?

"speedsoft.nospam" wrote in message
<46c94b13$0$398$426a74cc@news.free.fr>:

De plus tu ne reviens pas sur mes questions du 18/08 1:10, qui
me semblent essentielles pour tirer des conclusions pertinentes !

J'ai dû louper ce message. Je vais voir.

Dans la
série, quid des mécanismes de contrôle des données écrites sur le disque par
le SE ? Y en a-t-il ?

Non. Enfin, évidemment, il y a les mécanismes matériels : la mémoire à
parité, ou encore mieux la mémoire à correction d'erreur. Qui de toutes
façons est de la mémoire beaucoup plus fiable à la base que de la noname.

Des mécanismes logiciels, ce n'est essentiellement pas possible. Déjà, l'OS
ne pourrait vérifier l'intégrité des données que sur l'intervalle de temps
après l'indexation initiale : ça peut réduire la fenêtre sensible, mais mais
il est absolument impossible de la fermer. D'autre part, une telle
vérification aurait un coût absolument faramineux.

C'est exactement ce que disaient "les experts" aux débuts de l'évaluation
des médicaments, sur une dizaine de cas... (Je suis le Pr Dugland vous
pensez bien que s'il le produit est efficace, je le verrai !! -sur une
dizaine de cas.... Il en faut aujourd'hui plusieurs milliers)

Il y a deux différences entre la situation présente et ta comparaison :

- L'évaluation d'un médicament ne demande pas seulement de prouver
l'efficacité, mais aussi de prouver l'absence d'effets secondaires graves.
Ici, le seul effet secondaire, on le connaît déjà : c'est que ça coûte un
peu plus cher.

- Je n'ai pas d'intérêt personnel à convaincre qui que ce soit : je ne vends
pas de mémoire, ni ne touche de commissions sur les ventes de mémoire de
marque plutôt que de mémoire noname.

Je ne remets pas en cause tes compétences, pour ce qui est de détecter "UN
événement" problème de mémoire, mais la hiérarchisation généralisée des
conclusions : LES no name posent plus de problèmes que LES "de marque", car
il existe trop de facteurs de variabilité en jeu.

Mais je n'ai pas parlé de détecter « UN événement » : je l'ai dit, entre mes
achats personnels et ceux de mon entourage, et entre les problèmes constatés
sur le long terme, et ceux qui se voient tout de suite à memtest pour peu
qu'on le laisse tourner assez longtemps, j'ai un échantillon assez large
d'observations. Et la corrélation est tellement marquée que c'est amplement
suffisant.

Après, il y a certains biais dans mon échantillon, par exemple quasiment
toute la mémoire concernée a été achetée dans le 12e arrondissement de
Paris. Mais pour le coup, je ne crois pas une seconde à l'influence que ça
peut avoir.

Encore une fois, rien ne te permets de l'affirmer dans la mesure où tu n'as
aucune idée de la fréquence de ce type d'événement dans "mes" conditions
d'utilisation. Car même si l'outil n'est pas "absolu" (lequel l'est ?), le
fait de passer systématiquement les barettes sous memtest pendant plusieurs
heures, permet très vraisemblablement de réduire la population de barettes à
risque !

Oui, ça la réduit. Mais à la base, je rappelle que la mémoire noname, c'est
de la mémoire qui a été jugée pas assez fiable pour être vendue sous un
label (et une garantie) de marque. En d'autres termes, c'est de la mémoire
qui a déjà échoué des tests plus fiables que memtest.

D'ailleurs, puisque tu fais le test systématiquement, tu peux peut-être nous
éclairer sur tes observations : parmi les barrettes que tu détectes
défectueuses, quelle proportion est noname ?

Vous avez filtré cet utilisateur ! Consultez son message

"speedsoft.nospam" wrote in message
<46c94b13$0$398$:

De plus tu ne reviens pas sur mes questions du 18/08 1:10, qui
me semblent essentielles pour tirer des conclusions pertinentes !

J'ai dû louper ce message. Je vais voir.

Dans la
série, quid des mécanismes de contrôle des données écrites sur le disque par
le SE ? Y en a-t-il ?

Non. Enfin, évidemment, il y a les mécanismes matériels : la mémoire à
parité, ou encore mieux la mémoire à correction d'erreur. Qui de toutes
façons est de la mémoire beaucoup plus fiable à la base que de la noname.

Des mécanismes logiciels, ce n'est essentiellement pas possible. Déjà, l'OS
ne pourrait vérifier l'intégrité des données que sur l'intervalle de temps
après l'indexation initiale : ça peut réduire la fenêtre sensible, mais mais
il est absolument impossible de la fermer. D'autre part, une telle
vérification aurait un coût absolument faramineux.

C'est exactement ce que disaient "les experts" aux débuts de l'évaluation
des médicaments, sur une dizaine de cas... (Je suis le Pr Dugland vous
pensez bien que s'il le produit est efficace, je le verrai !! -sur une
dizaine de cas.... Il en faut aujourd'hui plusieurs milliers)

Il y a deux différences entre la situation présente et ta comparaison :

- L'évaluation d'un médicament ne demande pas seulement de prouver
l'efficacité, mais aussi de prouver l'absence d'effets secondaires graves.
Ici, le seul effet secondaire, on le connaît déjà : c'est que ça coûte un
peu plus cher.

- Je n'ai pas d'intérêt personnel à convaincre qui que ce soit : je ne vends
pas de mémoire, ni ne touche de commissions sur les ventes de mémoire de
marque plutôt que de mémoire noname.

Je ne remets pas en cause tes compétences, pour ce qui est de détecter "UN
événement" problème de mémoire, mais la hiérarchisation généralisée des
conclusions : LES no name posent plus de problèmes que LES "de marque", car
il existe trop de facteurs de variabilité en jeu.

Mais je n'ai pas parlé de détecter « UN événement » : je l'ai dit, entre mes
achats personnels et ceux de mon entourage, et entre les problèmes constatés
sur le long terme, et ceux qui se voient tout de suite à memtest pour peu
qu'on le laisse tourner assez longtemps, j'ai un échantillon assez large
d'observations. Et la corrélation est tellement marquée que c'est amplement
suffisant.

Après, il y a certains biais dans mon échantillon, par exemple quasiment
toute la mémoire concernée a été achetée dans le 12e arrondissement de
Paris. Mais pour le coup, je ne crois pas une seconde à l'influence que ça
peut avoir.

Encore une fois, rien ne te permets de l'affirmer dans la mesure où tu n'as
aucune idée de la fréquence de ce type d'événement dans "mes" conditions
d'utilisation. Car même si l'outil n'est pas "absolu" (lequel l'est ?), le
fait de passer systématiquement les barettes sous memtest pendant plusieurs
heures, permet très vraisemblablement de réduire la population de barettes à
risque !

Oui, ça la réduit. Mais à la base, je rappelle que la mémoire noname, c'est
de la mémoire qui a été jugée pas assez fiable pour être vendue sous un
label (et une garantie) de marque. En d'autres termes, c'est de la mémoire
qui a déjà échoué des tests plus fiables que memtest.

D'ailleurs, puisque tu fais le test systématiquement, tu peux peut-être nous
éclairer sur tes observations : parmi les barrettes que tu détectes
défectueuses, quelle proportion est noname ?

[RAM] Ajout d'une barrette sur portable

10 réponses

Veuillez sélectionner un problème