Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.sci.electronics > #241219 > unrolled thread

Halbleiteralterung

Back to article view | Back to de.sci.electronics

Contents

  Halbleiteralterung R.Kiefer.SPAEM@gmx.de (Ralf Kiefer) - 2018-02-23 15:04 +0100
    Re: Halbleiteralterung Matthias Weingart <mwnews@pentax.boerde.de> - 2018-02-23 14:52 +0000
      Re: Halbleiteralterung R.Kiefer.SPAEM@gmx.de (Ralf Kiefer) - 2018-02-23 16:40 +0100
      Re: Halbleiteralterung Rolf Bombach <rolfnospambombach@invalid.invalid> - 2018-02-27 22:53 +0100
        Re: Halbleiteralterung Hanno Foest <hurga-news2@tigress.com> - 2018-02-28 00:03 +0100
          Re: Halbleiteralterung "Ralph A. Schmid, dk5ras" <ralph@schmid.xxx> - 2018-03-02 09:30 +0100
            Re: Halbleiteralterung v_borchert@despammed.com (Volker Borchert) - 2018-03-02 20:48 +0000
              Re: Halbleiteralterung "horst.d.winzler" <horst.d.winzler@web.de> - 2018-03-03 06:07 +0100
              Re: Halbleiteralterung "Ralph A. Schmid, dk5ras" <ralph@schmid.xxx> - 2018-03-05 15:43 +0100
                Re: Halbleiteralterung v_borchert@despammed.com (Volker Borchert) - 2018-03-05 21:49 +0000
                  Re: Halbleiteralterung "horst.d.winzler" <horst.d.winzler@web.de> - 2018-03-06 11:38 +0100
          Re: Halbleiteralterung v_borchert@despammed.com (Volker Borchert) - 2018-03-03 08:06 +0000
            Re: Halbleiteralterung R.Kiefer.SPAEM@gmx.de (Ralf Kiefer) - 2018-03-03 13:39 +0100
            Re: Halbleiteralterung Hanno Foest <hurga-news2@tigress.com> - 2018-03-04 23:58 +0100
          Re: Halbleiteralterung Matthias Weingart <mwnews@pentax.boerde.de> - 2018-03-05 07:36 +0000
    Re: Halbleiteralterung Leo Baumann <charly020664@yahoo.de> - 2018-02-23 15:59 +0100
    Re: Halbleiteralterung Rafael Deliano <rafael_deliano@arcor.de> - 2018-02-23 17:18 +0100
      Re: Halbleiteralterung R.Kiefer.SPAEM@gmx.de (Ralf Kiefer) - 2018-02-23 18:16 +0100
        Re: Halbleiteralterung Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2018-02-23 18:23 +0100
          Re: Halbleiteralterung R.Kiefer.SPAEM@gmx.de (Ralf Kiefer) - 2018-02-23 19:19 +0100
            Re: Halbleiteralterung Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2018-02-23 19:24 +0100
              Re: Halbleiteralterung R.Kiefer.SPAEM@gmx.de (Ralf Kiefer) - 2018-02-23 22:56 +0100
                Re: Halbleiteralterung Martin Peters <martin.peters@news.uni-stuttgart.de> - 2018-02-24 12:15 +0000
                  Re: Halbleiteralterung R.Kiefer.SPAEM@gmx.de (Ralf Kiefer) - 2018-02-24 16:07 +0100
                    Re: Halbleiteralterung Andreas Neumann <an5275@sedo.com> - 2018-02-24 17:12 +0100
                    Re: Halbleiteralterung Martin Peters <martin.peters@news.uni-stuttgart.de> - 2018-02-24 16:21 +0000
            Re: Halbleiteralterung Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2018-02-24 07:16 +0100
              Re: Halbleiteralterung R.Kiefer.SPAEM@gmx.de (Ralf Kiefer) - 2018-02-24 16:07 +0100
                Re: Halbleiteralterung Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2018-02-25 00:24 +0100
                  Re: Halbleiteralterung R.Kiefer.SPAEM@gmx.de (Ralf Kiefer) - 2018-02-25 15:34 +0100
      Re: Halbleiteralterung Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2018-02-23 18:19 +0100
        Re: Halbleiteralterung Eric Bruecklmeier <usenet@nerdcraft.de> - 2018-02-23 18:24 +0100
          Re: Halbleiteralterung Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2018-02-23 18:35 +0100
            Re: Halbleiteralterung Dieter Wiedmann <dieter.wiedmann@t-online.de> - 2018-02-23 18:40 +0100
            Re: Halbleiteralterung Eric Bruecklmeier <usenet@nerdcraft.de> - 2018-02-23 19:34 +0100
          Re: Halbleiteralterung R.Kiefer.SPAEM@gmx.de (Ralf Kiefer) - 2018-02-23 19:19 +0100
            Re: Halbleiteralterung Eric Bruecklmeier <usenet@nerdcraft.de> - 2018-02-23 19:36 +0100
              Re: Halbleiteralterung Hanno Foest <hurga-news2@tigress.com> - 2018-02-23 22:04 +0100
                Re: Halbleiteralterung Eric Bruecklmeier <usenet@nerdcraft.de> - 2018-02-24 09:48 +0100
        Re: Halbleiteralterung v_borchert@despammed.com (Volker Borchert) - 2018-02-27 19:33 +0000
          Re: Halbleiteralterung Rolf Bombach <rolfnospambombach@invalid.invalid> - 2018-02-27 23:02 +0100
        Re: Halbleiteralterung Rolf Bombach <rolfnospambombach@invalid.invalid> - 2018-02-27 22:57 +0100
          Re: Halbleiteralterung R.Kiefer.SPAEM@gmx.de (Ralf Kiefer) - 2018-02-27 23:40 +0100
      Re: Halbleiteralterung Patrick Schaefer <pa.schaefer@web.de> - 2018-02-24 14:23 +0100
        Re: Halbleiteralterung Hanno Foest <hurga-news2@tigress.com> - 2018-02-24 18:57 +0100
          Re: Halbleiteralterung Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2018-02-24 19:33 +0100
        Re: Halbleiteralterung Rafael Deliano <rafael_deliano@arcor.de> - 2018-02-25 07:33 +0100
          Re: Halbleiteralterung Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2018-02-25 08:14 +0100
      Re: Halbleiteralterung Christian Treffler <CTreffler.NG.Dev0@gmx.net> - 2018-02-24 15:07 +0100
        Re: Halbleiteralterung Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2018-02-24 15:15 +0100
          Re: Halbleiteralterung R.Kiefer.SPAEM@gmx.de (Ralf Kiefer) - 2018-02-24 16:07 +0100
            Re: Halbleiteralterung Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2018-02-24 16:13 +0100
              Re: Halbleiteralterung Dieter Wiedmann <dieter.wiedmann@t-online.de> - 2018-02-24 16:16 +0100
              Re: Halbleiteralterung R.Kiefer.SPAEM@gmx.de (Ralf Kiefer) - 2018-02-24 17:12 +0100
    Re: Halbleiteralterung Werner Holtfreter <holtfreter@gmx.de> - 2018-02-23 22:10 +0100
    Re: Halbleiteralterung Wolf gang P u f f e <remail@gmx.com> - 2018-02-23 22:37 +0100
      Re: Halbleiteralterung R.Kiefer.SPAEM@gmx.de (Ralf Kiefer) - 2018-02-23 22:56 +0100
    Re: Halbleiteralterung Marcel Mueller <news.5.maazl@spamgourmet.org> - 2018-02-23 23:28 +0100
    Re: Halbleiteralterung v_borchert@despammed.com (Volker Borchert) - 2018-02-27 17:25 +0000
      Re: Halbleiteralterung R.Kiefer.SPAEM@gmx.de (Ralf Kiefer) - 2018-02-27 23:40 +0100
        Re: Halbleiteralterung Markus Elsken <markus.elsken@ewetel.net> - 2018-02-28 16:33 +0100
          Re: Halbleiteralterung R.Kiefer.SPAEM@gmx.de (Ralf Kiefer) - 2018-02-28 16:51 +0100
            Re: Halbleiteralterung Michael Limburg <mlimb@gmx.de> - 2018-03-01 16:59 +0100
    Re: Halbleiteralterung Thomas Stanka <usenet_nospam_valid@stanka-web.de> - 2018-03-02 02:17 -0800
    Re: Halbleiteralterung Falk Dµebbert <falk@duebbert.com> - 2018-03-04 11:55 +0100
      Re: Halbleiteralterung R.Kiefer.SPAEM@gmx.de (Ralf Kiefer) - 2018-03-04 14:27 +0100
        Re: Halbleiteralterung Falk Dµebbert <falk@duebbert.com> - 2018-03-04 21:02 +0100
          Re: Halbleiteralterung R.Kiefer.SPAEM@gmx.de (Ralf Kiefer) - 2018-03-05 00:03 +0100

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#241503

Volker Borchert schrieb:
> 
> Spekulatius:
> 
> Wasser hat ein epsilon-r von 80. Das könnte schon das Timing versauen
> oder die Nebenkapazitäten so vergrößern, daß die wenigen Elektronen aus
> der Zelle keine erkennbare Eins mehr ergeben.

Übertakten sollte helfen, ab ca. 50 GHz spielt das dann kaum mehr eine Rolle.

80 dürfte sich nur ausbilden, wenn viele Molekülschichten übereinander
zu liegen kommen, das ist keine Eigenschaft eines einzigen Moleküls.
Die Sperrschichtkapazitäten oder die dünnen SiO2 Schichten im Chip
dürften eh die grösseren Kapazitätswerte aufweisen.

-- 
mfg Rolf Bombach

[toc] | [prev] | [next] | [standalone]

#241502

Gerrit Heitsch schrieb:
> On 02/23/2018 05:18 PM, Rafael Deliano wrote:
>>> Liegt's an parasitären Widerständen oder Kapazitäten auf den Dies, die
>>> aufgrund des Alters entstehen und das Timing verschlechtern?
>>
>> Ehedem ( anno DIL ) war die Annahme, daß Plastikgehäuse im Gegensatz
>> zu Keramik Feuchtigkeit aufnehmen und damit die Lebensdauer dieser
>> ICs begrenzt ist. Hausnummer war 1mm Eindringtiefe / Jahr für IC-Gehäuse. Inzwischen ist das Plastik sehr dünn geworden.
> 
> Ja, aber es laufen noch jede Menge 8Bit-Systeme aus den 80ern und deren Chipgehäuse sind keine 35mm dick.
> 
> Auch verschwindet das Wasser wieder wenn der IC benutzt wird und sich damit aufheizt.

Meiner Meinung nach wandert das Wasser eh molekülweise rein und tut
dann sein Unheil. Möglicherweise spielt da die Temperatur gar keine
Rolle oder sogar eine schädliche. Alle alten DEC-Prozessoren sind
zuverlässig daran verreckt, die aus der frühen LSI-11-Zeit herum.

-- 
mfg Rolf Bombach

[toc] | [prev] | [next] | [standalone]

#241506

Rolf Bombach wrote:

> Möglicherweise spielt da die Temperatur gar keine
> Rolle oder sogar eine schädliche.

Den Rechner, in dem diese RAMs die sehr vielen Jahre verbracht haben,
habe ich nahezu täglich eingeschaltet und täglich wieder ausgeschaltet.
D.h. der kam in Pausenzeiten vielleicht auf 18Grad, ggf. an sehr kalten
Wintertagen und der Nachtabsenkung der Raumheizung auf 16Grad, aber im
laufenden Betrieb als Gehäusetemperatur sicher nicht über 50Grad,
vermutlich nicht mal wesentlich über 40Grad, weil das Gehäuse sehr gut
gekühlt ist.

Im anderen G3 b/w, den ich seit über 12Jahren fast rund um die Uhr
betreibe, hatte ich vor ein paar Jahren auch mal ein RAM-Problem, das
sich in manchen Punkten ähnlich zeigte, aber nicht ganz identisch.
Insbesondere hatte ich keine eindeutige Problemlösung gefunden.

Gruß, Ralf

[toc] | [prev] | [next] | [standalone]

#241291

Am 23.02.2018 17:18 schrieb Rafael Deliano:

 > Ehedem ( anno DIL ) war die Annahme, daß Plastikgehäuse im Gegensatz
 > zu Keramik Feuchtigkeit aufnehmen und damit die Lebensdauer dieser
 > ICs begrenzt ist. Hausnummer war 1mm Eindringtiefe / Jahr für
 > IC-Gehäuse. Inzwischen ist das Plastik sehr dünn geworden.

Dieses Problem hatte sich weitgehend erledigt als man anfing, die Chips 
mit einer Siliziumoxid-Schicht zu überziehen ("passivieren").

Bei der CMOS-Serie war das der Übergang von CD4001 / CD4001A auf CD4001B.


Patrick

[toc] | [prev] | [next] | [standalone]

#241335

Am 24.02.2018 um 14:23 schrieb Patrick Schaefer:

> Dieses Problem hatte sich weitgehend erledigt als man anfing, die Chips 
> mit einer Siliziumoxid-Schicht zu überziehen ("passivieren").
> 
> Bei der CMOS-Serie war das der Übergang von CD4001 / CD4001A auf CD4001B.

Das ist echt der Unterschied zwischen A und B? Kann man das irgendwo 
nachlesen? Finde ich hochinteressant!

Hanno

[toc] | [prev] | [next] | [standalone]

#241339

On 02/24/2018 06:57 PM, Hanno Foest wrote:
> Am 24.02.2018 um 14:23 schrieb Patrick Schaefer:
> 
>> Dieses Problem hatte sich weitgehend erledigt als man anfing, die 
>> Chips mit einer Siliziumoxid-Schicht zu überziehen ("passivieren").
>>
>> Bei der CMOS-Serie war das der Übergang von CD4001 / CD4001A auf CD4001B.
> 
> Das ist echt der Unterschied zwischen A und B? Kann man das irgendwo 
> nachlesen? Finde ich hochinteressant!

Wenn das stimmt müssten alle 'A' inzwischen tot sein.

  Gerrit

[toc] | [prev] | [next] | [standalone]

#241355

> Bei der CMOS-Serie war das der Übergang von CD4001 / CD4001A auf CD4001B.

Mir wäre der als Übergang "ohne ESD-Schutz" auf "ESD-Schutz-Dioden" 
geläufig.

Plastik ist weiterhin hygroskopisch, vgl bake out vor reflow löten.

Aufwändige Verfahren a la glassivation sind zwar angepriesen worden,
ich wäre aber skeptisch daß die bei consumer ICs praktische Bedeutung 
hatten.

MfG JRD

[toc] | [prev] | [next] | [standalone]

#241356

On 02/25/2018 07:33 AM, Rafael Deliano wrote:
>> Bei der CMOS-Serie war das der Übergang von CD4001 / CD4001A auf CD4001B.
> 
> Mir wäre der als Übergang "ohne ESD-Schutz" auf "ESD-Schutz-Dioden" 
> geläufig.
> 
> Plastik ist weiterhin hygroskopisch, vgl bake out vor reflow löten.
> 
> Aufwändige Verfahren a la glassivation sind zwar angepriesen worden,
> ich wäre aber skeptisch daß die bei consumer ICs praktische Bedeutung 
> hatten.

Doch, sonst halten die ICs nicht lange. Sogar Commodore hat das bei 
ihren Chips für den C64 (und andere) gemacht. Am Anfang mit ein paar 
Problemen, da sind dann die Chips trotz Passivierung nach einem halben 
Jahr gestorben.

  Gerrit

[toc] | [prev] | [next] | [standalone]

#241298

Rafael Deliano schrieb:

> Ehedem ( anno DIL ) war die Annahme, daß Plastikgehäuse im Gegensatz
> zu Keramik Feuchtigkeit aufnehmen und damit die Lebensdauer dieser
> ICs begrenzt ist. 

Das ist keine Annahme, sondern Fakt. Nicht umsonst werden Halbleiter im
Dry-Pack mit Moisture Sensitivity Indicator ausgeliefert.

> Hausnummer war 1mm Eindringtiefe / Jahr für 
> IC-Gehäuse. Inzwischen ist das Plastik sehr dünn geworden.

Wohl war. MSL3: 168 Stunden Zeit zwischen dem Auspacken und dem
Reflow-Löten.

CU,
Christian

[toc] | [prev] | [next] | [standalone]

#241299

On 02/24/2018 03:07 PM, Christian Treffler wrote:
> Rafael Deliano schrieb:
> 
>> Ehedem ( anno DIL ) war die Annahme, daß Plastikgehäuse im Gegensatz
>> zu Keramik Feuchtigkeit aufnehmen und damit die Lebensdauer dieser
>> ICs begrenzt ist.
> 
> Das ist keine Annahme, sondern Fakt. Nicht umsonst werden Halbleiter im
> Dry-Pack mit Moisture Sensitivity Indicator ausgeliefert.
> 
>> Hausnummer war 1mm Eindringtiefe / Jahr für
>> IC-Gehäuse. Inzwischen ist das Plastik sehr dünn geworden.
> 
> Wohl war. MSL3: 168 Stunden Zeit zwischen dem Auspacken und dem
> Reflow-Löten.

Dabei gehts aber eher um die Vermeidung des Popcorn-Effects als um 
Alterung des ICs. Funktionieren tun die Dinger auch noch Jahre nach dem 
sie aus dem Dry-Pack entnommen wurden.

  Gerrit

[toc] | [prev] | [next] | [standalone]

#241306

Gerrit Heitsch wrote:

> Dabei gehts aber eher um die Vermeidung des Popcorn-Effects als um 
> Alterung des ICs. Funktionieren tun die Dinger auch noch Jahre nach dem
> sie aus dem Dry-Pack entnommen wurden.

So kenne ich das als Begründung ebenso aus der Leiterplattenbestückung
im industriellen Maßstab, denn das betrifft nicht nur Chip-Gehäuse,
sondern genauso Widerstände, Kapazitäten und ein paar andere Bauteile.

Gruß, Ralf

[toc] | [prev] | [next] | [standalone]

#241308

On 02/24/2018 04:07 PM, Ralf Kiefer wrote:
> Gerrit Heitsch wrote:
> 
>> Dabei gehts aber eher um die Vermeidung des Popcorn-Effects als um
>> Alterung des ICs. Funktionieren tun die Dinger auch noch Jahre nach dem
>> sie aus dem Dry-Pack entnommen wurden.
> 
> So kenne ich das als Begründung ebenso aus der Leiterplattenbestückung
> im industriellen Maßstab, denn das betrifft nicht nur Chip-Gehäuse,
> sondern genauso Widerstände, Kapazitäten und ein paar andere Bauteile.

Bei Widerständen und Kapazitäten kenne ich eher den Tombstone-Effect.

  Gerrit

[toc] | [prev] | [next] | [standalone]

#241309

Am 24.02.2018 um 16:13 schrieb Gerrit Heitsch:

> Bei Widerständen und Kapazitäten kenne ich eher den Tombstone-Effect.

Die NRA schlägt vor, dass die Bestücker sich bewaffnen sollten!



CNR, Dieter

[toc] | [prev] | [next] | [standalone]

#241316

Gerrit Heitsch wrote:

> Bei Widerständen und Kapazitäten kenne ich eher den Tombstone-Effect.

Das auch, aber das ist ein anderer Effekt. Dick aufgetragene Lötpaste,
zu unterschiedliches Erwärmen der Lötpaste auf den einzelnen Pads, so
daß das Bauteil auf einer Seite in der verflüssigten Lötpaste bereits
deutlich einsinkt, während es auf der anderen Seite noch auf der
"festen" Lötpaste oben aufliegt. Oberflächenspannung von flüssiger
Lötpaste kann da auch Einfluß haben. Deswegen hat so ein Ofen 15, 18,
besser noch mehr Temperaturzonen, damit das Erwärmen möglichst
gleichmäßig stattfindet. 

Mir haben die Jungz aus der Fertigung berichtet, daß auch das
Hühnerfutter aufpoppen kann, wenn es zu lange "draußen" Luftfeuchtigkeit
gezogen hat, weswegen sie jede ausgepackte Rolle kennzeichnen (häufig
verwendete Bauteile), nach Abrüsten wieder verschweißen (selten
verwendete Bauteile) oder ggf. vor dem Aufrüsten in den Trocknungsofen
legen. Meine Folgerung war, daß die dieses Brimborium nicht veranstalten
würden, wenn sie es noch nie erlebt hätten.  

Das ist die Erfahrung der Leute in der Bestückung genauso wie das
Temperatur- und Luftfeuchtigkeitsfenster, in denen ihre Prozesse gut
funktionieren. Denn auch die Lötpaste zieht Luftfeuchtigkeit, wenn sie
offen lagert oder bereits aufgetragen ist, aber noch vor dem Ofen warten
muß. Das sorgt für einen ähnlichen Effekt, nur daß dann eben kleine
Lötpastenspritzer umherfliegen und ggf. auf ungeeigneten Stellen landen.

Gruß, Ralf

[toc] | [prev] | [next] | [standalone]

#241246

Ralf Kiefer wrote:

> Mein Versuch ein einzelnes DIMM als defekt einzugrenzen mißlang,
> das Fehlerverhalten war unlogisch.

Deine Frage kann ich nicht beantworten, kann aber Beispiele
beitragen, nach denen eine Degradierung einzelner Komponenten im
System extrem schwer zu lokalisieren ist, sofern man keine
Möglichkeit hat, die Einhaltung der Spezifikation der einzelnen
Komponenten zu testen, was wohl die Regel ist:

Die Datenrate zu einer Festplatte brach sehr stark ein, was bei der
Datensicherung auffiel. Alle anderen Festplatten liefen an dem
betreffenden SATA-Port einwandfrei. Der Port schien also in
Ordnung. Die Festplatte bekam dann ihren Platz hinter einem
PCI-SATA-Adapter, der von sich aus langsamer war, aber die
Festplatte tat es mit dieser etwas reduzierten Geschwindigkeit noch
einige Jahre. Erst nachdem sich noch weitere Unregelmäßigkeiten im
Rechnerbetrieb zeigten, war ein neues (gebrauchtes) Motherboard
fällig. Die scheinbar degradierte Festplatte erwachte nun wieder zu
vollem Leben, so dass dann wohl doch der SATA-Port des alten
Mainboard aus der Spezifikation gelaufen war.

Ein ähnliches Problem gibt es, wenn Datenspeichergerät und
Datenspeichermedium getrennt sind, wie bei der beschreibbaren CD.
Ich habe seinerzeit stets akribisch die Qualität des Brands
getestet, aber schließlich geriet doch der Brenner in Verdacht, als
es schlechter wurde. Eine Linsenreinigung half nur kurzfristig, hat
sich also nicht gelohnt. Nach Ersatz des Brenners war alles wieder
gut. Auch hier hat man wenig Möglichkeiten, die Ursache zu finden,
solange kein Totalausfall vorliegt.

Letztes Beispiel ist ein USB-Stick, von dem ich bootete, um
Festplatten zu spiegeln. Gelegentlich, aber eben nicht immer
versagte der Bootvorgang. Glücklicherweise ging der Stick dann
relativ schnell soweit kaputt, dass mir weitere Fehlersuche erspart
blieb: Er war nur noch teilweise auslesbar und blieb dann hängen.
-- 
Gruß Werner
„Der baldige Abgang der Deutschen aber ist
Völkersterben von seiner schönsten Seite.“ Deniz Yücel
http://32521.seu.cleverreach.com/c/30163247/2b9ae7d6adbd-p4jpbk

[toc] | [prev] | [next] | [standalone]

#241247

Am 23.02.2018 um 15:04 schrieb Ralf Kiefer:
...
>
> Mein Versuch ein einzelnes DIMM als defekt einzugrenzen mißlang, das
> Fehlerverhalten war unlogisch. In der Ersatzteilkiste fanden sich andere
> DIMMs, die jetzt problemlos funktionieren. Soweit, so gut :-)
>
> Aber die defekten interessieren mich (auch). Ein anderer G3, der
> deutlich weniger Laufzeit hat, muß zum Testen herhalten. Auch hier
> scheitert der Versuch eines der DIMM-Module als defekt einzugrenzen.
> Jedes einzelne funktioniert im stundenlangen RAM-Test. Baue ich zwei
> ein, hängt's von den Sockeln ab, so funktionierte ein Paar in den beiden
> unteren Sockeln im 16-stündigen RAM-Test, stieg aber schon beim ersten
> Durchlauf aus, wenn ich andere Sockel nahm. Randbemerkung: die Sockel
> sind alle in Ordnung, denn dieser G3 funktioniert mit seinen
> ursprünglichen 4 DIMMs je 256MB problemlos.
>
> Nach diversen kombinatorischen Tests habe ich dieses Spiel als
> aussichtslos aufgegeben. Aber neue Idee: man kann den Basistakt der
> Hauptplatine ändern. Die nächstlangsamere Frequenz unter 100MHz liegt
> bei 94,5MHz. Damit haben alle vier DIMMs sowohl einzeln wie auch im
> Viererpack den RAM-Test überstanden [1]. D.h. die schaffen einfach die
> Geschwindigkeit nicht mehr.

Macht das Ding Dual-Channel-Modus?
Vielleicht erkennt der Speicherkontroller manche Sockelbelegungen mit
Modulen und schaltet in den Dual-Channel-Modus, bei dem dann Probleme
(Timing) auftreten.
Damals, als die ersten Boards mit Dual-Channel-Modus aufkamen, musste
man gleiche Module in bestimmte Sockel stecken, sonst gabs Ärger bei
ungünstigen Kombinationen.
WIMRE konnte man bei manchen BIOSen Dualchannel manuel schalten um
stabile Zustände zu erzwingen.
Ist schon zu lange her, als dass ich mich genauer erinnern könnte was
da genau war.

W.

[toc] | [prev] | [next] | [standalone]

#241249

Wolf gang P u f f e wrote:

> Macht das Ding Dual-Channel-Modus?

Nein, das kann der nicht. Der RAM-Controller ist relativ doof, denn die
Geschwindigkeit aller vier Sockel richtet sich nach dem langsamsten
eingebauten DIMM. Ich achte trotzdem drauf, daß ich keinen wilden Mix
aus unterschiedlichen Herstellern einbaue.


> Damals, als die ersten Boards mit Dual-Channel-Modus aufkamen, musste
> man gleiche Module in bestimmte Sockel stecken, sonst gabs Ärger bei
> ungünstigen Kombinationen.

Das kannten die Macs der vorherigen Generation, die mit FPM- und/oder
EDO-DIMMs.


Gruß, Ralf

[toc] | [prev] | [next] | [standalone]

#241252

On 23.02.18 15.04, Ralf Kiefer wrote:
> Konkreter Fall: DRAM, PC-100 bzw. PC-133.
>
> Mein Mac G3 b/w wurde ungefähr 1999 hergestellt. Seit ungefähr 2005
> nutze ich den täglich zwischen 4 und 16 Stunden, d.h. der hat seither in
> der Größenordnung 40.000 Betriebsstunden. Ausgestattet war er bis vor
> ein paar Tagen mit 256MB-PC133-DIMMs der schnellstmöglichen Sorte
> (2-2-2). Ihm reichen tatsächlich PC-100. Vor ein paar Wochen begann er
> zickig zu werden und stürzte immer häufiger ab. Ein Speichertest zeigte
> Fehler. BTW ausgelaufene oder dickbäuchige Elkos auf der Hauptplatine
> können nicht dazu beitragen, da ausschließlich keramische und Tantal
> verbaut sind.

Jo, jo. Da sind sicher Elkos drauf. Spätestens im Netzteil. Und alle 
Elkos können verrecken, klassische, Tantal und auch die ach so tollen 
Feststoffelkos. Letztere sterben halt leise.


> Aber die defekten interessieren mich (auch). Ein anderer G3, der
> deutlich weniger Laufzeit hat, muß zum Testen herhalten. Auch hier
> scheitert der Versuch eines der DIMM-Module als defekt einzugrenzen.
> Jedes einzelne funktioniert im stundenlangen RAM-Test. Baue ich zwei
> ein, hängt's von den Sockeln ab, so funktionierte ein Paar in den beiden
> unteren Sockeln im 16-stündigen RAM-Test, stieg aber schon beim ersten
> Durchlauf aus, wenn ich andere Sockel nahm. Randbemerkung: die Sockel
> sind alle in Ordnung, denn dieser G3 funktioniert mit seinen
> ursprünglichen 4 DIMMs je 256MB problemlos.

Je weniger Speichermodule desto unkritischer deren Eigenschaften. 
Deshalb geht es oft noch, wenn nur ein Modul im Einsatz ist.

Außerdem ist tatsächlich bei Teilbestückung nicht in jedem Board jeder 
beliebige Slot erlaubt. Da können Signalreflexionen die Qualität negativ 
beeinflussen.

> Nach diversen kombinatorischen Tests habe ich dieses Spiel als
> aussichtslos aufgegeben. Aber neue Idee: man kann den Basistakt der
> Hauptplatine ändern. Die nächstlangsamere Frequenz unter 100MHz liegt
> bei 94,5MHz. Damit haben alle vier DIMMs sowohl einzeln wie auch im
> Viererpack den RAM-Test überstanden [1]. D.h. die schaffen einfach die
> Geschwindigkeit nicht mehr.

So einfach ist es meist nicht, aber dennoch kann diese Maßnahme eine 
ganze Weile lang herhalten.

> Liegt's an parasitären Widerständen oder Kapazitäten auf den Dies, die
> aufgrund des Alters entstehen und das Timing verschlechtern?

Das kann nach der Zeit alles mögliche sein; von Elektromigration bis hin 
zu den klassischen tauben Elkos in der Stromversorgung, die die Sache 
sensibel machen.

> Die
> DRAM-Controller tragen ggf. auch ihren Teil dazu bei. Allerdings
> funktionieren die auf beiden beteiligten Hauptplatinen mit anderen RAMs
> weiterhin problemlos auch mit 100MHz, so daß ich die Schuld eher bei den
> RAMs vermute.

Kann schon sein. Tausche sie aus, und gut ist's. Und wenn das nicht 
hilft, hast Du immer noch die 95 MHz Variante.


> [1] Ich habe für den Test vergangene Nacht sogar den CPU-Takt
> hochgesetzt, um die andere Ecke der Logik zu stressen. Die 350MHz-CPU
> lief daher mit 378MHz und problemlos. Der Rechner hat als Realwelttest
> viele GB zwischen Server und lokaler Festplatte fehlerfrei kopiert.

Bei Netzwerktransfers ist die Speicherlast aufgrund der im Vergleich 
langsamen Netzwerks eher gering.


Marcel

[toc] | [prev] | [next] | [standalone]

#241487

In de.alt.folklore.computer, Ralf Kiefer wrote:
> 
> Konkreter Fall: DRAM, PC-100 bzw. PC-133.
> 
> Liegt's an parasitären Widerständen oder Kapazitäten auf den Dies, die
> aufgrund des Alters entstehen und das Timing verschlechtern? Die
> DRAM-Controller tragen ggf. auch ihren Teil dazu bei. Allerdings
> funktionieren die auf beiden beteiligten Hauptplatinen mit anderen RAMs
> weiterhin problemlos auch mit 100MHz, so daß ich die Schuld eher bei den
> RAMs vermute. 
> 
> Was spielt sich da ab?

Gibt es die Riegel oder die darauf verbauten Einzelchips auch MIL?
Deren Datenblätter oder Anwendungshinweise könnten aufschlußreich sein.

-- 

"I'm a doctor, not a mechanic." Dr Leonard McCoy <mccoy@ncc1701.starfleet.fed>
"I'm a mechanic, not a doctor." Volker Borchert  <v_borchert@despammed.com>

[toc] | [prev] | [next] | [standalone]

#241505

Volker Borchert wrote:

> Gibt es die Riegel oder die darauf verbauten Einzelchips auch MIL?

K.A. Die Chips haben als Aufdruck:
| Lei
| LES32404TA-7.5
| 0212
| 32M*4 SDRAM-7.5-T

Der Verkäufer mit Namen auf dem Aufkleber auf dem DIMM war ein
eigentlich angesehener Händler in der damaligen Mac-Welt: DSP-Memory.
Die Suche nach einem RAM-Chip mit dieser Bezeichnung sieht auf den
ersten Blick nicht besonders erfolgreich aus.


> Deren Datenblätter oder Anwendungshinweise könnten aufschlußreich sein.

Wie werden eigentlich RAMs beschriftet, wenn sie vom Hersteller
ausgesondert werden und dem Recycling übergeben werden? Könnte das
Recycling unter fremder Flagge hier in Form von Auflöten geschehen sein?

Gruß, Ralf
 

[toc] | [prev] | [next] | [standalone]

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

Back to top | Article view | de.sci.electronics

csiph-web