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

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

RoHS

Started byHanno Foest <hurga-news2@tigress.com>
First post2019-09-15 12:12 +0200
Last post2019-09-24 11:13 -0700
Articles 20 on this page of 106 — 25 participants

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

Contents

  RoHS Hanno Foest <hurga-news2@tigress.com> - 2019-09-15 12:12 +0200
    Re: RoHS Rolf Bombach <rolfnospambombach@invalid.invalid> - 2019-09-15 19:30 +0200
      Re: RoHS Hanno Foest <hurga-news2@tigress.com> - 2019-09-15 19:55 +0200
    Re: RoHS Marcel Mueller <news.5.maazl@spamgourmet.org> - 2019-09-16 07:34 +0200
      Re: RoHS Hanno Foest <hurga-news2@tigress.com> - 2019-09-16 10:46 +0200
        Re: RoHS Rolf Bombach <rolfnospambombach@invalid.invalid> - 2019-09-17 22:20 +0200
          Re: RoHS Volker Bartheld <news2019@bartheld.net> - 2019-09-18 13:01 +0200
    Re: RoHS w-buechsenschuetz@web.de - 2019-09-16 01:13 -0700
    Re: RoHS Andreas Bockelmann <xotzil@gmx.de> - 2019-09-16 11:55 +0200
      Re: RoHS Eric Bruecklmeier <usenet@nerdcraft.de> - 2019-09-16 12:09 +0200
        Re: RoHS Ralph Aichinger <ra@pi.h5.or.at> - 2019-09-16 12:27 +0200
          Re: RoHS Andreas Bockelmann <xotzil@gmx.de> - 2019-09-16 13:31 +0200
          Re: RoHS Marc Haber <mh+usenetspam1118@zugschl.us> - 2019-09-16 15:00 +0200
            Re: RoHS Guido Grohmann <guido.grohmann@gmx.de> - 2019-09-16 18:09 +0200
        Re: RoHS Andreas Bockelmann <xotzil@gmx.de> - 2019-09-16 13:30 +0200
      Re: RoHS Hanno Foest <hurga-news2@tigress.com> - 2019-09-16 12:26 +0200
        Re: RoHS Andreas Bockelmann <xotzil@gmx.de> - 2019-09-16 13:32 +0200
        Re: RoHS Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-09-16 14:08 +0200
          Re: RoHS Eric Bruecklmeier <usenet@nerdcraft.de> - 2019-09-16 14:23 +0200
            Re: RoHS Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-09-16 14:40 +0200
            Re: RoHS Rolf Bombach <rolfnospambombach@invalid.invalid> - 2019-09-17 22:24 +0200
              Re: RoHS Eric Bruecklmeier <usenet@nerdcraft.de> - 2019-09-18 09:34 +0200
          Re: RoHS Andreas Bockelmann <xotzil@gmx.de> - 2019-09-16 17:26 +0200
            Re: RoHS Guido Grohmann <guido.grohmann@gmx.de> - 2019-09-16 18:11 +0200
              Re: RoHS Andreas Bockelmann <xotzil@gmx.de> - 2019-09-16 22:04 +0200
      Re: RoHS "Wolfgang Allinger" <all2001@spambog.com> - 2019-09-16 12:02 -0400
        Re: RoHS Helmut Schellong <rip@schellong.biz> - 2019-09-16 20:00 +0200
          Re: RoHS Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-09-16 20:54 +0200
            Re: RoHS Helmut Schellong <rip@schellong.biz> - 2019-09-16 21:15 +0200
              Re: RoHS Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-09-17 10:18 +0200
                Re: RoHS Helmut Schellong <rip@schellong.biz> - 2019-09-17 19:10 +0200
                  Re: RoHS Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2019-09-17 19:16 +0200
                    Re: RoHS Helmut Schellong <rip@schellong.biz> - 2019-09-17 21:45 +0200
            Re: RoHS Volker Bartheld <news2019@bartheld.net> - 2019-09-16 21:19 +0200
              Re: RoHS Bernd Laengerich <Bernd.Laengerich@web.de> - 2019-09-17 10:20 +0200
                Re: RoHS Volker Bartheld <news2019@bartheld.net> - 2019-09-17 10:32 +0200
                  Re: RoHS Bernd Laengerich <Bernd.Laengerich@web.de> - 2019-09-17 12:53 +0200
                    Re: RoHS Volker Bartheld <news2019@bartheld.net> - 2019-09-17 15:14 +0200
                      Re: RoHS Bernd Laengerich <Bernd.Laengerich@web.de> - 2019-09-17 16:13 +0200
                        Re: RoHS Hanno Foest <hurga-news2@tigress.com> - 2019-09-17 16:16 +0200
                          Re: RoHS Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-09-17 16:32 +0200
                      Re: RoHS Volker Bartheld <news2019@bartheld.net> - 2019-09-17 19:35 +0200
                        Re: RoHS Bernd Laengerich <bernd.laengerich@web.de> - 2019-09-17 20:25 +0200
            Re: RoHS Helmut Schellong <rip@schellong.biz> - 2019-09-16 22:10 +0200
              Re: RoHS Rupert Haselbeck <mein-rest-muell@gmx.de> - 2019-09-19 11:10 +0200
                Re: RoHS Volker Bartheld <news2019@bartheld.net> - 2019-09-19 11:35 +0200
                  SSD (was Re: RoHS) "Wolfgang Allinger" <all2001@spambog.com> - 2019-09-19 09:29 -0400
                    Re: SSD (was Re: RoHS) Helmut Schellong <rip@schellong.biz> - 2019-09-19 17:15 +0200
                    Re: SSD (was Re: RoHS) Stefan Heimers <stefan.usenet@heimers.ch> - 2019-09-19 21:38 +0200
                  Re: RoHS Helmut Schellong <rip@schellong.biz> - 2019-09-19 16:36 +0200
                Re: RoHS Ralph Aichinger <ra@pi.h5.or.at> - 2019-09-19 11:36 +0200
                  Re: RoHS Hanno Foest <hurga-news2@tigress.com> - 2019-09-19 12:57 +0200
                    Re: RoHS Ralph Aichinger <ra@pi.h5.or.at> - 2019-09-19 12:59 +0200
                    Re: RoHS Helmut Schellong <rip@schellong.biz> - 2019-09-19 16:44 +0200
                      Re: RoHS Marc Haber <mh+usenetspam1118@zugschl.us> - 2019-09-21 09:36 +0200
                        Re: RoHS Hergen Lehmann <hlehmann.expires.5-11@snafu.de> - 2019-09-21 13:36 +0200
                          Re: RoHS Ralph Aichinger <ra@pi.h5.or.at> - 2019-09-21 22:43 +0200
                            Re: RoHS Volker Bartheld <news2019@bartheld.net> - 2019-09-22 10:18 +0200
                              Re: RoHS Ralph Aichinger <ra@pi.h5.or.at> - 2019-09-22 10:22 +0200
                                Re: RoHS olaf <olaf@criseis.ruhr.de> - 2019-09-22 11:26 +0200
                                Re: RoHS Eric Bruecklmeier <usenet@nerdcraft.de> - 2019-09-22 11:51 +0200
                                Re: RoHS Hanno Foest <hurga-news2@tigress.com> - 2019-09-22 15:57 +0200
                                Re: RoHS Volker Bartheld <news2019@bartheld.net> - 2019-09-22 16:07 +0200
                              Re: RoHS Hanno Foest <hurga-news2@tigress.com> - 2019-09-22 15:54 +0200
                            Re: RoHS olaf <olaf@criseis.ruhr.de> - 2019-09-22 11:20 +0200
                              Re: RoHS Volker Bartheld <news2019@bartheld.net> - 2019-09-22 16:16 +0200
                        Re: RoHS Helmut Schellong <rip@schellong.biz> - 2019-09-21 18:48 +0200
                          Re: RoHS Ralph Aichinger <ra@pi.h5.or.at> - 2019-09-21 22:44 +0200
                            Re: RoHS Volker Bartheld <news2019@bartheld.net> - 2019-09-22 10:17 +0200
                              Re: RoHS Klaus Butzmann <kb.usenet@butzomail.de> - 2019-09-22 11:39 +0200
                                Re: RoHS Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2019-09-22 11:44 +0200
                                  Re: RoHS Uhu <Euleuhu@nest.de> - 2019-09-22 11:48 +0200
                                  Re: RoHS Rupert Haselbeck <mein-rest-muell@gmx.de> - 2019-09-22 17:30 +0200
                                    Re: RoHS Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2019-09-22 19:57 +0200
                                    Re: RoHS Volker Bartheld <news2019@bartheld.net> - 2019-09-23 07:40 +0200
                                      Re: RoHS Rupert Haselbeck <mein-rest-muell@gmx.de> - 2019-09-24 21:20 +0200
                                        Re: RoHS Volker Bartheld <news2019@bartheld.net> - 2019-09-25 10:53 +0200
                                          Re: RoHS Hanno Foest <hurga-news2@tigress.com> - 2019-09-25 12:13 +0200
                                            Re: RoHS Volker Bartheld <news2019@bartheld.net> - 2019-09-25 12:52 +0200
                                Re: RoHS Volker Bartheld <news2019@bartheld.net> - 2019-09-22 16:18 +0200
                                  Re: RoHS Klaus Butzmann <kb.usenet@butzomail.de> - 2019-09-22 17:28 +0200
                              Re: RoHS "horst-d.winzler" <horst.d.winzler@web.de> - 2019-09-22 12:23 +0200
                                Re: RoHS Volker Bartheld <news2019@bartheld.net> - 2019-09-22 16:19 +0200
                                  Re: RoHS "horst-d.winzler" <horst.d.winzler@web.de> - 2019-09-22 20:42 +0200
                                    Re: RoHS Volker Bartheld <news2019@bartheld.net> - 2019-09-23 07:41 +0200
                            Re: RoHS Helmut Schellong <rip@schellong.biz> - 2019-09-22 19:20 +0200
                              Re: RoHS Marc Haber <mh+usenetspam1118@zugschl.us> - 2019-09-25 11:32 +0200
                                Re: RoHS Ralph Aichinger <ra@pi.h5.or.at> - 2019-09-25 13:36 +0200
                                  Re: RoHS Marc Haber <mh+usenetspam1118@zugschl.us> - 2019-09-25 14:40 +0200
                                  Re: RoHS Helmut Schellong <rip@schellong.biz> - 2019-09-25 15:26 +0200
                                    Re: RoHS Ralph Aichinger <ra@pi.h5.or.at> - 2019-09-25 16:02 +0200
                                      Re: RoHS Helmut Schellong <rip@schellong.biz> - 2019-09-25 17:03 +0200
                                        Re: RoHS Hanno Foest <hurga-news2@tigress.com> - 2019-09-25 18:05 +0200
                                Re: RoHS Helmut Schellong <rip@schellong.biz> - 2019-09-25 14:18 +0200
                                  Re: RoHS Hanno Foest <hurga-news2@tigress.com> - 2019-09-25 14:29 +0200
                                    Re: RoHS Helmut Schellong <rip@schellong.biz> - 2019-09-25 15:18 +0200
                                      Re: RoHS Eric Bruecklmeier <usenet@nerdcraft.de> - 2019-09-25 15:21 +0200
                                        Re: RoHS Helmut Schellong <rip@schellong.biz> - 2019-09-25 16:37 +0200
                                          Re: RoHS Eric Bruecklmeier <usenet@nerdcraft.de> - 2019-09-25 16:41 +0200
                                      Re: RoHS Hanno Foest <hurga-news2@tigress.com> - 2019-09-25 16:05 +0200
                                        Re: RoHS Helmut Schellong <rip@schellong.biz> - 2019-09-25 17:05 +0200
                          Re: RoHS Marc Haber <mh+usenetspam1118@zugschl.us> - 2019-09-22 18:50 +0200
          Re: RoHS Bernd Laengerich <bernd.laengerich@web.de> - 2019-09-16 21:20 +0200
          Re: RoHS "Wolfgang Allinger" <all2001@spambog.com> - 2019-09-16 21:44 -0400
    Re: RoHS Thomas Heger <ttt_heg@web.de> - 2019-09-23 07:20 +0200
    Re: RoHS Joerg <news@analogconsultants.com> - 2019-09-24 11:13 -0700

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

#264034

FromRolf Bombach <rolfnospambombach@invalid.invalid>
Date2019-09-17 22:24 +0200
Message-ID<qlrfdr$d8g$1@dont-email.me>
In reply to#263933
Eric Bruecklmeier schrieb:
> Am 16.09.2019 um 14:08 schrieb Johannes Bauer:
> 
>> https://www.youtube.com/watch?v=E9aZZxNptp0#t=2m23s
> 
> Was nimmt der ein?

Panzerschokolade.

-- 
mfg Rolf Bombach

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

#264052

FromEric Bruecklmeier <usenet@nerdcraft.de>
Date2019-09-18 09:34 +0200
Message-ID<gue4vqFi73dU2@mid.individual.net>
In reply to#264034
Am 17.09.19 um 22:24 schrieb Rolf Bombach:
> Eric Bruecklmeier schrieb:
>> Am 16.09.2019 um 14:08 schrieb Johannes Bauer:
>>
>>> https://www.youtube.com/watch?v=E9aZZxNptp0#t=2m23s
>>
>> Was nimmt der ein?
> 
> Panzerschokolade.
> 

So wirkt es.

-- 
Ich muss nicht kultiviert *aussehen* - ich bin es.

Profiklaus in d.r.f.

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

#263948

FromAndreas Bockelmann <xotzil@gmx.de>
Date2019-09-16 17:26 +0200
Message-ID<qlogkc.8co.1@wxp-nb-pm.local>
In reply to#263932
Johannes Bauer schrieb:
> On 16.09.19 12:26, Hanno Foest wrote:
> 
>> (Ich habs nie komplett
>> verstanden, zumal es da wohl mehr als eine Fehlerursache gab)
> 
> Yep. Louis Rossmann beschreibt recht gut, dass offenbar in einigen BGAs
> eben nicht die Balls brechen, sondern die Verbindungen innerhalb des BGA
> durch thermische Belastung brechen:

Was erklären könnte, warum das Nachbacken der Grafikkarte nur sehr 
kurzfristig half.


-- 
  Mit freundlichen Grüßen
    Andreas Bockelmann

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

#263953

FromGuido Grohmann <guido.grohmann@gmx.de>
Date2019-09-16 18:11 +0200
Message-ID<gu9qgmFl7j2U2@mid.individual.net>
In reply to#263948
Andreas Bockelmann schrieb:
> Johannes Bauer schrieb:
>> On 16.09.19 12:26, Hanno Foest wrote:
>>
>>> (Ich habs nie komplett
>>> verstanden, zumal es da wohl mehr als eine Fehlerursache gab)
>>
>> Yep. Louis Rossmann beschreibt recht gut, dass offenbar in einigen BGAs
>> eben nicht die Balls brechen, sondern die Verbindungen innerhalb des BGA
>> durch thermische Belastung brechen:
> 
> Was erklären könnte, warum das Nachbacken der Grafikkarte nur sehr 
> kurzfristig half.
> 
Kurzfristig oder kurzzeitig?

Guido

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

#263967

FromAndreas Bockelmann <xotzil@gmx.de>
Date2019-09-16 22:04 +0200
Message-ID<qlp0t0.8f0.1@wxp-nb-pm.local>
In reply to#263953
Guido Grohmann schrieb:
> Andreas Bockelmann schrieb:
>> Johannes Bauer schrieb:
>>> On 16.09.19 12:26, Hanno Foest wrote:
>>>
>>>> (Ich habs nie komplett
>>>> verstanden, zumal es da wohl mehr als eine Fehlerursache gab)
>>>
>>> Yep. Louis Rossmann beschreibt recht gut, dass offenbar in einigen BGAs
>>> eben nicht die Balls brechen, sondern die Verbindungen innerhalb des BGA
>>> durch thermische Belastung brechen:
>>
>> Was erklären könnte, warum das Nachbacken der Grafikkarte nur sehr 
>> kurzfristig half.
>>
> Kurzfristig oder kurzzeitig?
> 
> Guido
> 
Kurzzeitig

-- 
  Mit freundlichen Grüßen
    Andreas Bockelmann

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

#263955

From"Wolfgang Allinger" <all2001@spambog.com>
Date2019-09-16 12:02 -0400
Message-ID<Etz8CMLjQoB@allinger-307049.user.uni-berlin>
In reply to#263924
On 16 Sep 19 at group /de/sci/electronics in article qlnt7f.85c.1@wxp-nb-pm.local
<xotzil@gmx.de>  (Andreas Bockelmann)  wrote:

> Hanno Foest schrieb:
>> Hallo allerseits,
>>
>> vielleicht doch mal wieder ein Elektronikthema...
>>
>> Nachdem der Himmel trotz bleifreien Lötens - anders als von den
>> Bedenkenträgern prophezeit - zumindest nicht generell gefallen ist, würde
>> mich mal interessieren, ob den Leuten, die mit Ausfallursachen
>> elektronischer Baugruppen zu tun haben, schon mal vermehrt diesbezügliches
>> aufgefallen ist. Also z.B. "tin whiskers".


> Mir ist nach Einführung der RoHS-Pest eine Grafikkarte im Notebook
> ausgefallen, weil sich die BGA-Kontaktierung des Grafikchips gelöst hatte.
> Ein Nachbacken im Backofen half zwar, aber nur sehr kurzfristig.

+2 IBM Notebooks (T30, T20?), gleiches Problem, backen half nur  
kurzfristig.

> Das war bisher der einzige Ausfall den ich auf Bleifrei zurückführen konnte
> und es ist auch nur eine Vermutung, wenn auch naheliegend.

Ich denke mal, das bei mir einige (im Laufe der Jahre sicher 10-12) HDD  
und ganz sicher eine SSD an der RoHS Pest verstorben sind.

Die HDDs hatte ich funktionsfähig und als gut getestet in meinem  
Büroschrank als backup gelagert, so 1-2 Jahre maximal.

Keine Stöße, Erschütterung, Temperatur 18-32°C... trotzdem gabs beim  
Versuch, gebackupte :) Sachen runterzuholen, jede Menge Fehlermeldungen  
und nach 1-2 weiteren Leseversuchen an meinem Testrechner dann  
Kernschrott.

BTW die 2. SSD (Samsung EVO850) lag als backup ebenfalls dort. Lies sich  
nach 2mon Lagerung nicht mehr lesen. Mein einziger und dafür umso  
heftigerer Daten SuperGau in meiner Praxis. Ich hab auf die harte Tour  
lernen müssen, das SSD nicht als lagerbare Ware gilt ;(((



Saludos (an alle Vernünftigen, Rest sh. sig)
Wolfgang

-- 
Ich bin in Paraguay lebender Trollallergiker :) reply Adresse gesetzt!
Ich diskutiere zukünftig weniger mit Idioten, denn sie ziehen mich auf
ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung! :p
(lt. alter usenet Weisheit)      iPod, iPhone, iPad, iTunes, iRak, iDiot

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

#263961

FromHelmut Schellong <rip@schellong.biz>
Date2019-09-16 20:00 +0200
Message-ID<qloikk$ca8$1@solani.org>
In reply to#263955
On 09/16/2019 18:02, Wolfgang Allinger wrote:

> Ich denke mal, das bei mir einige (im Laufe der Jahre sicher 10-12) HDD
> und ganz sicher eine SSD an der RoHS Pest verstorben sind.
> 
> Die HDDs hatte ich funktionsfähig und als gut getestet in meinem
> Büroschrank als backup gelagert, so 1-2 Jahre maximal.
> 
> Keine Stöße, Erschütterung, Temperatur 18-32°C... trotzdem gabs beim
> Versuch, gebackupte :) Sachen runterzuholen, jede Menge Fehlermeldungen
> und nach 1-2 weiteren Leseversuchen an meinem Testrechner dann
> Kernschrott.
> 
> BTW die 2. SSD (Samsung EVO850) lag als backup ebenfalls dort. Lies sich
> nach 2mon Lagerung nicht mehr lesen. Mein einziger und dafür umso
> heftigerer Daten SuperGau in meiner Praxis. Ich hab auf die harte Tour
> lernen müssen, das SSD nicht als lagerbare Ware gilt ;(((

Bei mir ist das Aufgeführte Jahrzehnte lang lagerbar und benutzbar.
HHDs wie auch SSDs. Alle. Temperatur egal.

Ich kaufe ausschließlich WD 24/7 und SSD SanDisc, Transcend.

SSDs halte ich grundsätzlich für untauglich, Betriebssysteme
darauf laufen zu lassen.
Die werden wegen der großen Zahl von Schreibvorgängen
alle nach etwa einem Jahr defekt sein.


-- 
Mit freundlichen Grüßen
Helmut Schellong   var@schellong.biz
www.schellong.de   www.schellong.com   www.schellong.biz
http://www.schellong.de/c.htm

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

#263963

FromJohannes Bauer <dfnsonfsduifb@gmx.de>
Date2019-09-16 20:54 +0200
Message-ID<qlolpd$7h6$1@news2.open-news-network.org>
In reply to#263961
On 16.09.19 20:00, Helmut Schellong wrote:

> SSDs halte ich grundsätzlich für untauglich, Betriebssysteme
> darauf laufen zu lassen.
> Die werden wegen der großen Zahl von Schreibvorgängen
> alle nach etwa einem Jahr defekt sein.

Nee, das ist definitiv nicht so. Habe viele Rechner, alle mit SSD als
primärer Platte, die älteste SSD jetzt bestimmt 8 Jahre alt oder so und
immernoch bei 98% Kapazität (gerade per smartctl nachgesehen). Meine
860EVO hat ein Jahr knüppelharten Dauereinsatz hinter sich, ist bei 99%
nach geschribenen 4.29 TB.

Gruß,
Johannes


-- 
"Performance ist nicht das Problem, es läuft ja nachher beides auf der
selben Hardware." -- Hans-Peter Diettrich in d.s.e.

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

#263964

FromHelmut Schellong <rip@schellong.biz>
Date2019-09-16 21:15 +0200
Message-ID<qlomvq$f7e$1@solani.org>
In reply to#263963
On 09/16/2019 20:54, Johannes Bauer wrote:
> On 16.09.19 20:00, Helmut Schellong wrote:
> 
>> SSDs halte ich grundsätzlich für untauglich, Betriebssysteme
>> darauf laufen zu lassen.
>> Die werden wegen der großen Zahl von Schreibvorgängen
>> alle nach etwa einem Jahr defekt sein.
> 
> Nee, das ist definitiv nicht so. Habe viele Rechner, alle mit SSD als
> primärer Platte, die älteste SSD jetzt bestimmt 8 Jahre alt oder so und
> immernoch bei 98% Kapazität (gerade per smartctl nachgesehen). Meine
> 860EVO hat ein Jahr knüppelharten Dauereinsatz hinter sich, ist bei 99%
> nach geschribenen 4.29 TB.

Wie ist denn die Speicherplatzausnutzung, also wie voll?


-- 
Mit freundlichen Grüßen
Helmut Schellong   var@schellong.biz
www.schellong.de   www.schellong.com   www.schellong.biz
http://www.schellong.de/c.htm

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

#263980

FromJohannes Bauer <dfnsonfsduifb@gmx.de>
Date2019-09-17 10:18 +0200
Message-ID<qlq4sn$kji$1@news2.open-news-network.org>
In reply to#263964
On 16.09.19 21:15, Helmut Schellong wrote:

>> Nee, das ist definitiv nicht so. Habe viele Rechner, alle mit SSD als
>> primärer Platte, die älteste SSD jetzt bestimmt 8 Jahre alt oder so und
>> immernoch bei 98% Kapazität (gerade per smartctl nachgesehen). Meine
>> 860EVO hat ein Jahr knüppelharten Dauereinsatz hinter sich, ist bei 99%
>> nach geschribenen 4.29 TB.
> 
> Wie ist denn die Speicherplatzausnutzung, also wie voll?

Filesystem              Size  Used Avail Use% Mounted on
/dev/mapper/crypt-root  3,6T  2,1T  1,4T  62% /

Gruß, Johannes

-- 
"Performance ist nicht das Problem, es läuft ja nachher beides auf der
selben Hardware." -- Hans-Peter Diettrich in d.s.e.

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

#264019

FromHelmut Schellong <rip@schellong.biz>
Date2019-09-17 19:10 +0200
Message-ID<qlr416$uhi$1@solani.org>
In reply to#263980
On 09/17/2019 10:18, Johannes Bauer wrote:
> On 16.09.19 21:15, Helmut Schellong wrote:
> 
>>> Nee, das ist definitiv nicht so. Habe viele Rechner, alle mit SSD als
>>> primärer Platte, die älteste SSD jetzt bestimmt 8 Jahre alt oder so und
>>> immernoch bei 98% Kapazität (gerade per smartctl nachgesehen). Meine
>>> 860EVO hat ein Jahr knüppelharten Dauereinsatz hinter sich, ist bei 99%
>>> nach geschribenen 4.29 TB.
>>
>> Wie ist denn die Speicherplatzausnutzung, also wie voll?
> 
> Filesystem              Size  Used Avail Use% Mounted on
> /dev/mapper/crypt-root  3,6T  2,1T  1,4T  62% /

Das ist unkritisch für WearLeveling, da noch viel freier Platz.

Ich bin generell skeptisch, WearLeveling gegenüber:

Wenn ich ein Dateisystem vollfülle, und diesen Inhalt in etwa
immer wieder dorthin schreibe, kann Wear Leveling nicht mehr wirken.
Und nach einigen 1000[0] Schreibvorgängen ist das Flash zerstört.

Es kann nur eine gewisse Anzahl von reservierten Blöcken
eingesetzt werden, was aber kein WearLeveling ist.

Wenn ein Flash 10⁶ Blöcke hat, und 1000 x 10⁶ = 10⁹ geänderte
Blöcke geschrieben werden, und ein WearLeveling perfekt verteilt,
ist das ganze Flash am Ende seiner Lebensdauer.
Ich hätte aber gerne mindestens 10¹⁸ Schreibvorgänge!

Lebensdauer ; Schreibvorgänge je Zelle:
      1.000 (TLC in 21-nm-Fertigung)
      3.000 (MLC in 25-nm-Fertigung)
      5.000 (MLC in 34-nm-Fertigung)
     10.000 (MLC in 50-nm-Fertigung)
    100.000 (SLC in 50-nm-Fertigung)
bis zu 5 Mio. (selektierte SLC-Chips)

Ein Ausweg ist intel-Optane-Speicher, der etwa
1000-fach länger hält als NAND/NOR-Flash.

Mein aktueller PC ist von 2006, mit HDD 500 GB + 1 TB.
Mein nächster PC wird 3 x WD Ultrastar 10 TB
und einen Optane >100 GB als M.2 haben.

.......................................................

Ich hatte angekündigt, auf einer Speicherkarte zu löschen
und das Dateisystem neu anzulegen, weil die Geschwindigkeit
der Karte von 100% auf nur etwa 40% gesunken ist, durch
nur etwa 400 Schreibvorgänge.

Das tat ich heute.
Es brachte nichts!

Ich habe zwei BAK-Karten:
   CF   8 GB, 2006, 102% belegt, 6.5 MB/s, peak 11 MB/s (früher 12)
SDXC 128 GB, 2014,  32% belegt, 9.5 MB/s, peak 12 MB/s (früher 26)
  HDD       , 2006,            ,  22 MB/s, peak 37 MB/s (früher 37)

Die SDXC ist massiv langsamer geworden.
Die hatte mal einen Peak von 26 MB/s!
Es können mehrere Gründe ursächlich sein.


-- 
Mit freundlichen Grüßen
Helmut Schellong   var@schellong.biz
www.schellong.de   www.schellong.com   www.schellong.biz
http://www.schellong.de/c.htm

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

#264020

FromGerrit Heitsch <gerrit@laosinh.s.bawue.de>
Date2019-09-17 19:16 +0200
Message-ID<qlr4d1$5li$1@news.bawue.net>
In reply to#264019
On 9/17/19 7:10 PM, Helmut Schellong wrote:
> On 09/17/2019 10:18, Johannes Bauer wrote:
>> On 16.09.19 21:15, Helmut Schellong wrote:
>>
>>>> Nee, das ist definitiv nicht so. Habe viele Rechner, alle mit SSD als
>>>> primärer Platte, die älteste SSD jetzt bestimmt 8 Jahre alt oder so und
>>>> immernoch bei 98% Kapazität (gerade per smartctl nachgesehen). Meine
>>>> 860EVO hat ein Jahr knüppelharten Dauereinsatz hinter sich, ist bei 99%
>>>> nach geschribenen 4.29 TB.
>>>
>>> Wie ist denn die Speicherplatzausnutzung, also wie voll?
>>
>> Filesystem              Size  Used Avail Use% Mounted on
>> /dev/mapper/crypt-root  3,6T  2,1T  1,4T  62% /
> 
> Das ist unkritisch für WearLeveling, da noch viel freier Platz.
> 
> Ich bin generell skeptisch, WearLeveling gegenüber:
> 
> Wenn ich ein Dateisystem vollfülle, und diesen Inhalt in etwa
> immer wieder dorthin schreibe, kann Wear Leveling nicht mehr wirken.
> Und nach einigen 1000[0] Schreibvorgängen ist das Flash zerstört.

Das ist allerdings nicht die normale Anwendung. Typischerweise werden 
die meisten Daten selten bis gar nicht überschrieben wenn du die SSD 
nicht gerade als Cache nimmst.

Wenn du hingegen immer nur ein paar Dateien überschreibst, dann kommt 
das Wearleveling schon zum Tragen. Intern sortiert die SSD dann Blöcke 
um. Nach aussen ist Block 123456 immer unter dieser Nummer zu finden. 
Intern geht er aber auf Wanderschaft. Dein OS weiss davon nichts und 
braucht es auch nicht wissen.



> Die SDXC ist massiv langsamer geworden.
> Die hatte mal einen Peak von 26 MB/s!
> Es können mehrere Gründe ursächlich sein.

Die kannst du aber nicht mit einer SSD vergleichen, das Wearleveling ist 
deutlich weniger komplex.

  Gerrit

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

#264030

FromHelmut Schellong <rip@schellong.biz>
Date2019-09-17 21:45 +0200
Message-ID<qlrd4l$5v5$1@solani.org>
In reply to#264020
On 09/17/2019 19:16, Gerrit Heitsch wrote:
> On 9/17/19 7:10 PM, Helmut Schellong wrote:
>> On 09/17/2019 10:18, Johannes Bauer wrote:

>>>> Wie ist denn die Speicherplatzausnutzung, also wie voll?
>>>
>>> Filesystem              Size  Used Avail Use% Mounted on
>>> /dev/mapper/crypt-root  3,6T  2,1T  1,4T  62% /
>>
>> Das ist unkritisch für WearLeveling, da noch viel freier Platz.
>>
>> Ich bin generell skeptisch, WearLeveling gegenüber:
>>
>> Wenn ich ein Dateisystem vollfülle, und diesen Inhalt in etwa
>> immer wieder dorthin schreibe, kann Wear Leveling nicht mehr wirken.
>> Und nach einigen 1000[0] Schreibvorgängen ist das Flash zerstört.
> 
> Das ist allerdings nicht die normale Anwendung. Typischerweise werden die 
> meisten Daten selten bis gar nicht überschrieben wenn du die SSD nicht gerade 
> als Cache nimmst.

Ich verwende Flash bisher nur für Backup und Dateispeicher
für Bilder des Oszilloskopes und des Fotoapparates.
Damit kann ich keine Defekte erreichen.

Ich habe Skripte, die millionenfach Daten in HDD-Dateien schreiben.

>> Die SDXC ist massiv langsamer geworden.
>> Die hatte mal einen Peak von 26 MB/s!
>> Es können mehrere Gründe ursächlich sein.
> 
> Die kannst du aber nicht mit einer SSD vergleichen, das Wearleveling ist 
> deutlich weniger komplex.

Richtig.
Ich hatte eine Liste gepostet.
Wenn ich die betrachte, gewinne ich den Eindruck, daß
CF-Speicherkarten besser sind.
Die alte CF von 2006 ist nämlich sehr stabil.
Die CF haben auch ein PATA-Interface.


In einer .pdf von Heise (2013) las ich, daß früher Datenblätter
für SSDs eine Retention-Time von 10 Jahren nannten.
Heute fordern Standards 1 Jahr bei 30⁰C und 3 Monate bei 40⁰C.
Heute wird diese Größe nicht mehr in die Datenblätter geschrieben.
Der Datenerhalt nimmt ab mit der Anzahl der Schreibvorgänge.

Ich las vor vielen Jahren mal über ein EEPROM von AMD
einen Datenerhalt von 20 Jahren bei 125⁰C !
Die Zeiten ändern sich...


-- 
Mit freundlichen Grüßen
Helmut Schellong   var@schellong.biz
www.schellong.de   www.schellong.com   www.schellong.biz
http://www.schellong.de/c.htm

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

#263965

FromVolker Bartheld <news2019@bartheld.net>
Date2019-09-16 21:19 +0200
Message-ID<bvd5j30t043q.dlg@news.bartheld.net>
In reply to#263963
> On 16.09.19 20:00, Helmut Schellong wrote:
>> SSDs halte ich grundsätzlich für untauglich, Betriebssysteme darauf
>> laufen zu lassen. Die werden wegen der großen Zahl von Schreibvorgängen
>> alle nach etwa einem Jahr defekt sein.

Jo. Das Internet ist voll davon, höchste Zeit "Wear Level Balancing" zu
erfinden. Ich hatte mal hierzugroups Daten meiner SSD gepostet, eine
Samsung 840 EVO mit 120GB, angeschafft irgendwann in grauer Vorzeit.

SMART sagt:

[05] Reallocated Sector Count:
100/Always OK, Worst: 100
[09] Power-On Hours/Cycle Count:
98/Always OK, Worst: 98 (6662 hours / 277.6 days)
[0C] Power Cycle Count:
96/Always OK, Worst: 96 (Data = 3884,0)
[B1] Wear Leveling Count:
94/Always OK, Worst: 94 (Data = 68,0)
[B3] Used Reserved Block Count (Total):
100/Always OK, Worst: 100
[B5] Program Fail Count (Total):
100/Always OK, Worst: 100
[B6] Erase Fail Count (Total):
100/Always OK, Worst: 100
[B7] Runtime Bad Block (Total):
100/Always OK, Worst: 100
[BB] Uncorrectable Error Count:
100/Always OK, Worst: 100
[BE] Airflow Temperature:
78/Always OK, Worst: 41 (22.0 °C)
[C3] ECC Error Rate:
200/Always OK, Worst: 200
[C7] SATA CRC Error Count:
100/Always OK, Worst: 100
[EB] POR Recovery Count:
99/Always OK, Worst: 99 (Data = 15,0)
[F1] Total Host Writes:
99/Always OK, Worst: 99 (Data = 942924248,3)
Drive Remaining Life
94%

Also kurz vorm Krepieren, das Teil.

On Mon, 16 Sep 2019 20:54:37 +0200, Johannes Bauer wrote:
> Nee, das ist definitiv nicht so. Habe viele Rechner, alle mit SSD als
> primärer Platte, die älteste SSD jetzt bestimmt 8 Jahre alt oder so und
> immernoch bei 98% Kapazität (gerade per smartctl nachgesehen). Meine
> 860EVO hat ein Jahr knüppelharten Dauereinsatz hinter sich, ist bei 99%
> nach geschriebenen 4.29 TB.

Irrelevant, komm uns bloß nicht mit Fakten. Haupsach, Helmut Schellong hat
(s)ein Bauchgefühl.

Volker

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

#263982

FromBernd Laengerich <Bernd.Laengerich@web.de>
Date2019-09-17 10:20 +0200
Message-ID<gubjapF20ghU1@mid.individual.net>
In reply to#263965
Am 16.09.2019 um 21:19 schrieb Volker Bartheld:

> [09] Power-On Hours/Cycle Count:
> 98/Always OK, Worst: 98 (6662 hours / 277.6 days)

Bei mir Faktor 1.5 bei einer OCZ Vertex3 120GB. War damals fast erschwinglich, 
dürfte so 2012/2013 gewesen sein. Ist halt nur abends ein wenig an.

> [F1] Total Host Writes:
> 99/Always OK, Worst: 99 (Data = 942924248,3)

Blocks oder was sind das? Blocks wären dann knapp 500GB, niedlich. Ich biete 
8TByte total bytes written. Der ganze Crap der ohnehin keine Geschwindigkeit 
braucht (Filme etc.) landet hier auf Dreheisen, SSD für OS, Swap, Hibernate, 
Programme und den ganzen Kleinkram.

In $4MA habe ich vor gut einem Jahr einen neuen Rechner erhalten Sandisk X400 
256GB mit Hardware-Verschlüsselung. Die hat jetzt knapp 5TB TBW, das macht 
knapp 20GB TBW pro Arbeitstag.
Spezifiziert sind 80TB TBW und 5a Garantie.

Bernd

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

#263984

FromVolker Bartheld <news2019@bartheld.net>
Date2019-09-17 10:32 +0200
Message-ID<10je4vqmlldyf.dlg@news.bartheld.net>
In reply to#263982
On Tue, 17 Sep 2019 10:20:41 +0200, Bernd Laengerich wrote:
> Am 16.09.2019 um 21:19 schrieb Volker Bartheld:
>> [09] Power-On Hours/Cycle Count:
>> 98/Always OK, Worst: 98 (6662 hours / 277.6 days)
> Bei mir Faktor 1.5 bei einer OCZ Vertex3 120GB.

Eben. Nach ähnlichen Nutzungszeiten sind mir diverse Drehplatten schon
längst abgeraucht. Und ich rede _nicht_ von den IBM DeathStar.

>> [F1] Total Host Writes:
>> 99/Always OK, Worst: 99 (Data = 942924248,3)

> Blocks oder was sind das?

Keine Ahung. Halt das, was https://www.hwinfo.com so ausspuckt.

> Blocks wären dann knapp 500GB, niedlich.

Keine Ahung, ich erlaube mir da keine Prognose. Fakt ist, daß ich die o. g.
Platte regelmäßig mit temporären Dateien vollschreibe und die dann wieder
lösche. Und es läuft regelmäßig ein Partitionsbackup, 10-20 Restores werde
ich schon auch gehabt haben, denn VirtualBox kann eben nicht alles reißen.

> Der ganze Crap der ohnehin keine Geschwindigkeit braucht (Filme etc.)
> landet hier auf Dreheisen

Ich habe eine 120GB SSD fürs OS, eine 500GB SSD für relevante Daten und ein
10TB NetGear-NAS am GBit-LAN nebst gleichgroßen, externen USB-Platten für
die Langzeitspeicherung. Das hat ein paar Euro gekostet, schont aber die
Nerven.

> In $4MA habe ich vor gut einem Jahr einen neuen Rechner erhalten Sandisk
> X400 256GB mit Hardware-Verschlüsselung. Die hat jetzt knapp 5TB TBW,
> das macht knapp 20GB TBW pro Arbeitstag. Spezifiziert sind 80TB TBW und
> 5a Garantie.

Dann ist die SSD natürlich in vier Jahren tot! Hättste mal lieber eine
Drehplatte genommen. Das ist so eine Art "FSK 6" für Daten
(https://www.spio-fsk.de/?seitid=508&tid=72), denn 5TB auf Dreheisen zu
schreiben, entschleunigt ungemein. Ich sehe das immer bei der Arbeit mit
ffmpeg und VirtualDub. Da kann man bei der SSD nichtmal mehr zum Pinkeln
aufstehen, so schnell rauscht das durch. O tempora, o mores!

Volker

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

#263989

FromBernd Laengerich <Bernd.Laengerich@web.de>
Date2019-09-17 12:53 +0200
Message-ID<gubs9nF3pb2U1@mid.individual.net>
In reply to#263984
Am 17.09.2019 um 10:32 schrieb Volker Bartheld:

> Keine Ahung. Halt das, was https://www.hwinfo.com so ausspuckt.

Hmm, das spuckt bei mir komische Werte aus. Demnach auch nur 744GB, das passt 
nicht. Und es wirft mir aus, daß die SSD erst 33h in Betrieb ist.

Ich habe CrystalDiskInfo benutzt, dort werden die F1-Werte als Hex-Rohdaten 
ausgegeben und das passt mit den ermittelten Werten für TBW, die ich für 
plausibel halte.

> Ich habe eine 120GB SSD fürs OS, eine 500GB SSD für relevante Daten und ein
> 10TB NetGear-NAS am GBit-LAN nebst gleichgroßen, externen USB-Platten für
> die Langzeitspeicherung. Das hat ein paar Euro gekostet, schont aber die
> Nerven.

Sieht hier ähnlich aus, aber nicht ganz so groß. Und damals[TM] wollte ich mit 
500GB SSD nicht leisten, deshalb das Dreheisen.

> Dann ist die SSD natürlich in vier Jahren tot! Hättste mal lieber eine

Das ist mir ehrlich gesagt egal. Zum einen glaube ich da wegen der bisher 
ermittelten Nutzung noch nicht dran, zum anderen wird der Rechner vermutlich 
sowieso vorher ersetzt. Und die "Platten" dürfen wegen Sicherheizbestimmungen 
die 4ma nicht verlassen.

Bernd

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

#263998

FromVolker Bartheld <news2019@bartheld.net>
Date2019-09-17 15:14 +0200
Message-ID<nt9kucqz0e9u.dlg@news.bartheld.net>
In reply to#263989
On Tue, 17 Sep 2019 12:53:43 +0200, Bernd Laengerich wrote:
> Am 17.09.2019 um 10:32 schrieb Volker Bartheld:
>> Keine Ahung. Halt das, was https://www.hwinfo.com so ausspuckt.
> Hmm, das spuckt bei mir komische Werte aus. [...]
> Ich habe CrystalDiskInfo benutzt

Ja, könnte man auch. Ist aber doch müßig. Die These war, daß SSDs mit der
OS-Partition in Nullkommanix kaputtgeschrieben werden. Und die ist
erwiesenermaßen vollkommener Quatsch, egal was für potentiell debattierbare
Argumente zur Widerlegung wir auch vorbringen. Man kann das alles im
Internet recherchieren und stößt dann z. B. auf [1], was weit weniger Anlaß
zur Hysterie bietet.

Daß man bei SSDs das Thema "Datensicherung" komplett ad Acta legen kann,
hat wohl nie jemand ernsthaft behauptet. Irgendwann wird es bei mir
Sector-Reallocations hageln und das ist eben dann der Moment, wo ich die
Platte außer Betrieb nehme und durch eine neue ersetze. Daß das
signifikant früher geschähe als mit Drehplatten, würde mich schon sehr
wundern. Und falls bis dahin nicht sowieso schon der Rechner das Zeitliche
segnet.

> dort werden die F1-Werte als Hex-Rohdaten 
> ausgegeben und das passt mit den ermittelten Werten für TBW, die ich für 
> plausibel halte.

Na gut. Überzeugt. Dann schaue ich das bei nächster Gelegenheit mal nach.
;-)

>> Dann ist die SSD natürlich in vier Jahren tot!

> Das ist mir ehrlich gesagt egal. Zum einen glaube ich da wegen der bisher 
> ermittelten Nutzung noch nicht dran, zum anderen wird der Rechner vermutlich 
> sowieso vorher ersetzt. Und die "Platten" dürfen wegen Sicherheizbestimmungen 
> die 4ma nicht verlassen.

War jetzt ein bisserl ironisch von meiner Seite her.

Volker

[1] https://www.heise.de/newsticker/meldung/SSD-Langzeittest-beendet-Exitus-bei-9-1-Petabyte-3755009.html
https://www.ontrack.com/blog/2018/02/07/how-long-do-ssds-really-last/
http://0b4af6cdc2f0c5998459-c0245c5c937c5dedcca3f1764ecc9b2f.r43.cf2.rackcdn.com/23105-fast16-papers-schroeder.pdf
https://users.ece.cmu.edu/~omutlu/pub/flash-memory-failures-in-the-field-at-facebook_sigmetrics15.pdf
https://techreport.com/review/27909/the-ssd-endurance-experiment-theyre-all-dead/

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

#264004

FromBernd Laengerich <Bernd.Laengerich@web.de>
Date2019-09-17 16:13 +0200
Message-ID<guc800F66u0U1@mid.individual.net>
In reply to#263998
Am 17.09.2019 um 15:14 schrieb Volker Bartheld:

> Na gut. Überzeugt. Dann schaue ich das bei nächster Gelegenheit mal nach.
> ;-)

Mach mal. Ich habe das Standard-Werkzeug smartmontools (Ieh, Kommandozeile!) 
auf die SSD losgelassen und CrystalDiskInfo zeigt zumindest die gleichen Werte 
in bunt an.

> War jetzt ein bisserl ironisch von meiner Seite her.

Ach?! Ach was!

Bernd

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

#264006

FromHanno Foest <hurga-news2@tigress.com>
Date2019-09-17 16:16 +0200
Message-ID<guc86rF6792U1@mid.individual.net>
In reply to#264004
On 17.09.19 16:13, Bernd Laengerich wrote:

> Mach mal. Ich habe das Standard-Werkzeug smartmontools (Ieh, 
> Kommandozeile!) auf die SSD losgelassen und CrystalDiskInfo zeigt 
> zumindest die gleichen Werte in bunt an.

Je nach Plattentyp und smartmontools-version können die Werte schon mal 
etwas eigenwillig sein. Ich weiß gerade nicht, ob ich schon mal bei ner 
SSD die verbleibende Lebensdauer irgendwo mal hab vernünftig ablesen 
können - andererseits benutze ich eher selten aktuelle Hardware.

Hanno

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

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

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

csiph-web