Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > de.rec.fotografie > #283602 > unrolled thread
| Started by | Dieter Lefeling <didis.mehlbox@web.de> |
|---|---|
| First post | 2017-09-29 19:38 +0200 |
| Last post | 2017-10-06 22:32 +0200 |
| Articles | 20 on this page of 214 — 41 participants |
Back to article view | Back to de.rec.fotografie
Mal wieder: Rechner (auch) für Bildbearbeitung Dieter Lefeling <didis.mehlbox@web.de> - 2017-09-29 19:38 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Sebastian Suchanek <sebastian.suchanek@gmx.de> - 2017-09-29 21:54 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Dieter Lefeling <didis.mehlbox@web.de> - 2017-09-29 23:01 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Uwe Naumann <news_nospam@vieledinge.de> - 2017-09-30 10:53 +0200
Re: Mal wieder: Rechner (auch) f?r Bildbearbeitung Olaf Kaluza <olaf@criseis.ruhr.de> - 2017-09-30 11:51 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Frank Möller <butterspiegeleiauftoast42@protonmail.com> - 2017-09-30 12:15 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Detlef Wirsing <detlef.wirsing@gmx.de> - 2017-09-30 14:12 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Frank Möller <butterspiegeleiauftoast42@protonmail.com> - 2017-09-30 19:34 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Falk Dµebbert <falk@duebbert.com> - 2017-09-30 20:24 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung "Thomas Krenzel ." <thurgan-news@gmx.de> - 2017-09-30 20:54 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Frank Möller <butterspiegeleiauftoast42@protonmail.com> - 2017-09-30 20:56 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Falk Dµebbert <falk@duebbert.com> - 2017-09-30 21:33 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Frank Möller <butterspiegeleiauftoast42@protonmail.com> - 2017-09-30 21:57 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Falk Dµebbert <falk@duebbert.com> - 2017-09-30 23:03 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Klaus Esser <klausesser@klausesser.de> - 2017-10-02 07:21 -0700
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Falk Dµebbert <falk@duebbert.com> - 2017-10-02 22:06 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Klaus Esser <klausesser@klausesser.de> - 2017-10-03 07:49 -0700
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Klaus Esser <klausesser@klausesser.de> - 2017-10-03 08:24 -0700
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Uwe Naumann <news_nospam@vieledinge.de> - 2017-09-30 21:51 +0200
(OT) Agent und aehnliche Katastrophen (was: Mal wieder: Rechner (auch) für Bildbearbeitung) Frank Möller <butterspiegeleiauftoast42@protonmail.com> - 2017-09-30 22:03 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Sebastian Suchanek <sebastian.suchanek@gmx.de> - 2017-09-30 17:03 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Falk Dµebbert <falk@duebbert.com> - 2017-09-30 20:33 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Sebastian Suchanek <sebastian.suchanek@gmx.de> - 2017-09-30 20:42 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Falk Dµebbert <falk@duebbert.com> - 2017-10-01 02:01 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Sebastian Suchanek <sebastian.suchanek@gmx.de> - 2017-10-01 19:47 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Dieter Lefeling <didis.mehlbox@web.de> - 2017-09-30 21:40 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Sebastian Suchanek <sebastian.suchanek@gmx.de> - 2017-09-30 23:44 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Patrick Rudin <taxi_bs@gmx.ch> - 2017-09-29 22:28 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Dieter Lefeling <didis.mehlbox@web.de> - 2017-09-29 23:07 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Patrick Rudin <taxi_bs@gmx.ch> - 2017-09-30 13:14 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Frank Möller <butterspiegeleiauftoast42@protonmail.com> - 2017-09-30 13:35 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Falk Dµebbert <falk@duebbert.com> - 2017-09-30 17:03 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Frank Möller <butterspiegeleiauftoast42@protonmail.com> - 2017-09-30 19:29 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Falk Dµebbert <falk@duebbert.com> - 2017-09-30 20:59 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Frank Möller <butterspiegeleiauftoast42@protonmail.com> - 2017-09-30 21:07 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Dieter Lefeling <didis.mehlbox@web.de> - 2017-09-30 21:49 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Luigi Rotta <luigi@rotta.ch> - 2017-09-30 22:49 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Dieter Lefeling <didis.mehlbox@web.de> - 2017-09-30 22:52 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Johannes Leckebusch <jlnospam@johannes-leckebusch.de> - 2017-10-01 00:08 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Luigi Rotta <luigi@rotta.ch> - 2017-10-01 21:10 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Bernd Laengerich <bernd.laengerich@web.de> - 2017-10-01 23:55 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Patrick Rudin <taxi_bs@gmx.ch> - 2017-09-30 23:12 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Wolfgang Exler <spam@suppenzoom.de> - 2017-10-02 05:50 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Ralph Aichinger <ra@pi.h5.or.at> - 2017-10-02 07:33 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Jürgen Gerkens <J.Gerkens@nurfuerspam.de> - 2017-10-02 09:07 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Falk Dµebbert <falk@duebbert.com> - 2017-10-02 22:09 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Oliver Jennrich <oliver.jennrich@gmx.net> - 2017-10-02 23:05 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Detlef Wirsing <detlef.wirsing@gmx.de> - 2017-10-01 11:47 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Hendric Stattmann <jimi@gmx.ch> - 2017-10-27 20:05 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Sebastian Suchanek <sebastian.suchanek@gmx.de> - 2017-09-30 17:09 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Dieter Lefeling <didis.mehlbox@web.de> - 2017-09-30 20:32 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Frank Möller <butterspiegeleiauftoast42@protonmail.com> - 2017-09-30 20:49 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Falk Dµebbert <falk@duebbert.com> - 2017-09-30 21:35 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Sebastian Suchanek <sebastian.suchanek@gmx.de> - 2017-09-30 23:46 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Bernd Mayer <beam.bam.boom@knuut.de> - 2017-10-02 18:00 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Wolfgang Exler <spam@suppenzoom.de> - 2017-10-02 05:40 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung "Thomas Krenzel ." <thurgan-news@gmx.de> - 2017-09-29 22:31 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Ralph Aichinger <ra@pi.h5.or.at> - 2017-09-29 22:37 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung "Thomas Krenzel ." <thurgan-news@gmx.de> - 2017-09-29 22:46 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Wolfgang Exler <spam@suppenzoom.de> - 2017-10-02 05:58 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Dieter Lefeling <didis.mehlbox@web.de> - 2017-10-02 09:42 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Wolfgang Exler <spam@suppenzoom.de> - 2017-10-03 22:38 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Wolfgang Exler <spam@suppenzoom.de> - 2017-10-02 05:54 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Dieter Lefeling <didis.mehlbox@web.de> - 2017-09-29 22:51 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Wolfgang Exler <spam@suppenzoom.de> - 2017-10-02 06:03 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Hans-Joerg Schlaberg <info@schlaberg.de> - 2017-10-02 08:11 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Ralph Aichinger <ra@pi.h5.or.at> - 2017-10-02 09:53 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung "Thomas Krenzel ." <thurgan-news@gmx.de> - 2017-10-02 12:41 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Hans-Joerg Schlaberg <info@schlaberg.de> - 2017-10-02 13:09 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung "Thomas Krenzel ." <thurgan-news@gmx.de> - 2017-10-02 13:20 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Wolfgang Exler <spam@suppenzoom.de> - 2017-10-03 22:42 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Falk Dµebbert <falk@duebbert.com> - 2017-10-03 23:57 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Hans-Joerg Schlaberg <info@schlaberg.de> - 2017-10-04 07:44 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Falk Dµebbert <falk@duebbert.com> - 2017-09-30 17:07 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung "Thomas Krenzel ." <thurgan-news@gmx.de> - 2017-09-30 17:42 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Wolfgang Exler <spam@suppenzoom.de> - 2017-10-02 06:17 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Jürgen Gerkens <J.Gerkens@nurfuerspam.de> - 2017-09-29 23:31 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung "Thomas Krenzel ." <thurgan-news@gmx.de> - 2017-09-30 10:03 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Oliver Thum <oliver@thum.li> - 2017-09-29 14:58 -0700
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Olaf Kaluza <olaf@criseis.ruhr.de> - 2017-09-29 22:17 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Wolfgang Kynast <wky@gmx.de> - 2017-09-30 09:36 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Dieter Lefeling <didis.mehlbox@web.de> - 2017-09-30 23:37 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Bernd Laengerich <bernd.laengerich@web.de> - 2017-10-01 00:10 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Ralph Aichinger <ra@pi.h5.or.at> - 2017-10-01 11:46 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Bernd Laengerich <bernd.laengerich@web.de> - 2017-10-01 23:52 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Wolfgang Strobl <news4@mystrobl.de> - 2017-10-02 22:02 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Frank Möller <butterspiegeleiauftoast42@protonmail.com> - 2017-10-02 10:58 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Bernd Mayer <beam.bam.boom@knuut.de> - 2017-10-02 18:14 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Jürgen Gerkens <J.Gerkens@nurfuerspam.de> - 2017-10-01 11:58 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Ralph Aichinger <ra@pi.h5.or.at> - 2017-10-01 11:44 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Heino Tiedemann <rotkaps_spam_trap@gmx.de> - 2017-09-30 12:47 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Wolfgang Exler <spam@suppenzoom.de> - 2017-10-02 06:27 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung "Thomas Krenzel ." <thurgan-news@gmx.de> - 2017-10-02 12:49 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Falk Dµebbert <falk@duebbert.com> - 2017-10-02 22:11 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Wolfgang Exler <spam@suppenzoom.de> - 2017-10-03 22:46 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Bernd Laengerich <bernd.laengerich@web.de> - 2017-10-03 23:33 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Wolfgang Exler <spam@suppenzoom.de> - 2017-10-05 00:02 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Frank Möller <butterspiegeleiauftoast42@protonmail.com> - 2017-09-30 12:07 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Ralph Aichinger <ra@pi.h5.or.at> - 2017-09-30 14:42 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung romualvitoux@gmail.com - 2017-09-30 07:10 -0700
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Falk Dµebbert <falk@duebbert.com> - 2017-09-30 16:47 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Bernd Laengerich <bernd.laengerich@web.de> - 2017-09-30 22:48 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Dieter Lefeling <didis.mehlbox@web.de> - 2017-09-30 22:53 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Bernd Laengerich <bernd.laengerich@web.de> - 2017-09-30 23:33 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Falk Dµebbert <falk@duebbert.com> - 2017-09-30 23:56 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Dieter Lefeling <didis.mehlbox@web.de> - 2017-10-02 01:26 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Jürgen Gerkens <J.Gerkens@nurfuerspam.de> - 2017-10-02 12:39 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Rainer Knaepper <rainerk@smial.prima.de> - 2017-10-02 10:36 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Dieter Lefeling <didis.mehlbox@web.de> - 2017-10-02 12:19 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Wolfgang Kynast <wky@gmx.de> - 2017-10-02 12:29 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Dieter Lefeling <didis.mehlbox@web.de> - 2017-10-02 13:11 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Jürgen Gerkens <J.Gerkens@nurfuerspam.de> - 2017-10-02 13:30 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Frank Möller <butterspiegeleiauftoast42@protonmail.com> - 2017-10-02 13:45 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Jürgen Gerkens <J.Gerkens@nurfuerspam.de> - 2017-10-02 14:00 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Frank Möller <butterspiegeleiauftoast42@protonmail.com> - 2017-10-02 14:08 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Jürgen Gerkens <J.Gerkens@nurfuerspam.de> - 2017-10-02 14:24 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Frank Möller <butterspiegeleiauftoast42@protonmail.com> - 2017-10-02 20:32 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Bernd Laengerich <bernd.laengerich@web.de> - 2017-10-02 18:21 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Frank Möller <butterspiegeleiauftoast42@protonmail.com> - 2017-10-02 20:32 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Bernd Laengerich <bernd.laengerich@web.de> - 2017-10-02 23:09 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Wolfgang Strobl <news4@mystrobl.de> - 2017-10-02 22:48 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Frank Möller <butterspiegeleiauftoast42@protonmail.com> - 2017-10-04 13:18 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Jürgen Gerkens <J.Gerkens@nurfuerspam.de> - 2017-10-04 13:36 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Frank Möller <butterspiegeleiauftoast42@protonmail.com> - 2017-10-04 13:53 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Jürgen Gerkens <J.Gerkens@nurfuerspam.de> - 2017-10-04 14:42 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Frank Möller <butterspiegeleiauftoast42@protonmail.com> - 2017-10-04 14:50 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Jürgen Gerkens <J.Gerkens@nurfuerspam.de> - 2017-10-04 15:12 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Frank Möller <butterspiegeleiauftoast42@protonmail.com> - 2017-10-04 15:40 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Jürgen Gerkens <J.Gerkens@nurfuerspam.de> - 2017-10-04 17:10 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Klaus Esser <klausesser@klausesser.de> - 2017-10-04 08:48 -0700
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Frank Möller <butterspiegeleiauftoast42@protonmail.com> - 2017-10-04 18:26 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Frank Möller <butterspiegeleiauftoast42@protonmail.com> - 2017-10-04 18:19 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Jürgen Gerkens <J.Gerkens@nurfuerspam.de> - 2017-10-04 18:34 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Frank Möller <butterspiegeleiauftoast42@protonmail.com> - 2017-10-04 18:42 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Jürgen Gerkens <J.Gerkens@nurfuerspam.de> - 2017-10-04 19:15 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Jürgen Gerkens <J.Gerkens@nurfuerspam.de> - 2017-10-04 18:57 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Frank Möller <butterspiegeleiauftoast42@protonmail.com> - 2017-10-04 19:03 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Bernd Laengerich <Bernd.Laengerich@web.de> - 2017-10-05 09:17 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Klaus Esser <klausesser@klausesser.de> - 2017-10-04 13:05 -0700
Re: Mal wieder: Rechner (auch) für Bildbearbeitung "Thomas Krenzel ." <thurgan-news@gmx.de> - 2017-10-04 13:58 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Rainer Knaepper <rainerk@smial.prima.de> - 2017-10-04 09:37 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Jürgen Gerkens <J.Gerkens@nurfuerspam.de> - 2017-10-04 10:58 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Jürgen Gerkens <J.Gerkens@nurfuerspam.de> - 2017-10-04 12:56 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Frank Möller <butterspiegeleiauftoast42@protonmail.com> - 2017-10-04 13:20 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Frank Möller <butterspiegeleiauftoast42@protonmail.com> - 2017-10-04 12:56 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Rainer Knaepper <rainerk@smial.prima.de> - 2017-10-04 09:23 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Wolfgang Strobl <news4@mystrobl.de> - 2017-10-02 22:21 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Thomas Poeschmann <der_thomas3@freenet.de> - 2017-10-03 19:55 +0000
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Dieter Lefeling <didis.mehlbox@web.de> - 2017-10-04 15:59 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Frank Möller <butterspiegeleiauftoast42@protonmail.com> - 2017-10-04 16:20 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Dieter Lefeling <didis.mehlbox@web.de> - 2017-10-04 19:13 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Frank Möller <butterspiegeleiauftoast42@protonmail.com> - 2017-10-04 20:51 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Jürgen Gerkens <J.Gerkens@nurfuerspam.de> - 2017-10-04 17:00 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Dieter Lefeling <didis.mehlbox@web.de> - 2017-10-04 19:29 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Jürgen Gerkens <J.Gerkens@nurfuerspam.de> - 2017-10-04 20:36 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Helmut Faugel <helmut.faugel@mnet-online.de> - 2017-10-04 19:49 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Thomas Poeschmann <der_thomas3@freenet.de> - 2017-10-04 21:41 +0000
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Helmut Faugel <helmut.faugel@mnet-online.de> - 2017-10-05 00:17 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Thomas Poeschmann <der_thomas3@freenet.de> - 2017-10-05 12:22 +0000
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Jochen Petry <jochen@knipsbildchenknipser.de> - 2017-10-05 14:52 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Thomas Poeschmann <der_thomas3@freenet.de> - 2017-10-05 13:50 +0000
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Klaus Esser <klausesser@klausesser.de> - 2017-10-05 07:11 -0700
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Wolfgang Strobl <news4@mystrobl.de> - 2017-10-05 19:02 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Wolfgang Kynast <wky@gmx.de> - 2017-10-05 19:43 +0200
[OT] Gehen Sie weiter, hier gibt es nichts zu sehen Wolfgang Strobl <news4@mystrobl.de> - 2017-10-05 22:46 +0200
Re: [OT] Gehen Sie weiter, hier gibt es nichts zu sehen Helmut Faugel <helmut.faugel@mnet-online.de> - 2017-10-05 23:25 +0200
Re: [OT] Gehen Sie weiter, hier gibt es nichts zu sehen Wolfgang Kynast <wky@gmx.de> - 2017-10-06 09:37 +0200
Re: [OT] Gehen Sie weiter, hier gibt es nichts zu sehen Wolfgang Kynast <wky@gmx.de> - 2017-10-06 00:03 +0200
Re: [OT] Gehen Sie weiter, hier gibt es nichts zu sehen Wolfgang Strobl <news4@mystrobl.de> - 2017-10-06 00:36 +0200
Re: [OT] Gehen Sie weiter, hier gibt es nichts zu sehen Wolfgang Kynast <wky@gmx.de> - 2017-10-06 09:40 +0200
Re: [OT] Gehen Sie weiter, hier gibt es nichts zu sehen Wolfgang Strobl <news4@mystrobl.de> - 2017-10-07 01:43 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Frank Möller <butterspiegeleiauftoast42@protonmail.com> - 2017-10-05 22:59 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Helmut Faugel <helmut.faugel@mnet-online.de> - 2017-10-05 23:12 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Patrick Rudin <taxi_bs@gmx.ch> - 2017-10-06 14:32 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Thomas Poeschmann <der_thomas3@freenet.de> - 2017-10-05 19:00 +0000
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Jochen Petry <jochen@jp-o-matic.de> - 2017-10-06 00:04 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Thomas Poeschmann <der_thomas3@freenet.de> - 2017-10-06 06:40 +0000
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Patrick Rudin <taxi_bs@gmx.ch> - 2017-10-04 20:47 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung "Thomas Krenzel ." <thurgan-news@gmx.de> - 2017-10-04 21:39 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Thomas Poeschmann <der_thomas3@freenet.de> - 2017-10-04 21:27 +0000
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Helmut Faugel <helmut.faugel@mnet-online.de> - 2017-10-05 00:06 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Dieter Lefeling <didis.mehlbox@web.de> - 2017-10-05 00:17 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Thomas Poeschmann <der_thomas3@freenet.de> - 2017-10-05 10:51 +0000
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Frank Möller <butterspiegeleiauftoast42@protonmail.com> - 2017-10-06 10:30 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Thomas Poeschmann <der_thomas3@freenet.de> - 2017-10-06 10:05 +0000
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Frank Möller <butterspiegeleiauftoast42@protonmail.com> - 2017-10-06 14:46 +0200
ECC-RAM (was: Re: Mal wieder: Rechner (auch) für Bildbearbeitung) Michael Unger <spam.to.unger@spamgourmet.com> - 2017-10-06 16:06 +0200
Re: ECC-RAM Frank Möller <butterspiegeleiauftoast42@protonmail.com> - 2017-10-06 18:31 +0200
Re: ECC-RAM Falk Dµebbert <falk@duebbert.com> - 2017-10-09 18:11 +0200
Re: ECC-RAM v_borchert@despammed.com (Volker Borchert) - 2017-10-10 18:39 +0000
Re: ECC-RAM Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2017-10-10 21:37 +0200
Re: ECC-RAM v_borchert@despammed.com (Volker Borchert) - 2017-10-10 20:26 +0000
Re: ECC-RAM Matthias Weingart <mwnews@pentax.boerde.de> - 2017-10-11 06:44 +0000
Re: ECC-RAM Patrick Schaefer <pa.schaefer@web.de> - 2017-10-11 22:13 +0200
Re: ECC-RAM Rolf Bombach <rolfnospambombach@invalid.invalid> - 2017-10-11 22:47 +0200
Re: ECC-RAM Helmut Faugel <helmut.faugel@mnet-online.de> - 2017-10-10 23:32 +0200
Re: ECC-RAM Gerhard Hoffmann <gerhard@hoffmann-hochfrequenz.de> - 2017-10-11 02:59 +0200
Re: ECC-RAM v_borchert@despammed.com (Volker Borchert) - 2017-10-11 03:15 +0000
Re: ECC-RAM Helmut Faugel <helmut.faugel@mnet-online.de> - 2017-10-11 09:12 +0200
Re: ECC-RAM v_borchert@despammed.com (Volker Borchert) - 2017-10-22 16:46 +0000
Re: ECC-RAM Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2017-10-11 09:21 +0200
Re: ECC-RAM Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2017-10-11 13:14 +0200
Re: ECC-RAM Matthias Weingart <mwnews@pentax.boerde.de> - 2017-10-11 06:50 +0000
Re: ECC-RAM Hanno Foest <hurga-news2@tigress.com> - 2017-10-11 15:09 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Rainer Knaepper <rainerk@smial.prima.de> - 2017-10-06 18:27 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Frank Möller <butterspiegeleiauftoast42@protonmail.com> - 2017-10-06 18:51 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Rainer Knaepper <rainerk@smial.prima.de> - 2017-10-06 21:56 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Frank Möller <butterspiegeleiauftoast42@protonmail.com> - 2017-10-07 00:00 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Rainer Knaepper <rainerk@smial.prima.de> - 2017-10-06 18:14 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Dieter Lefeling <didis.mehlbox@web.de> - 2017-10-06 19:53 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Frank Möller <butterspiegeleiauftoast42@protonmail.com> - 2017-10-06 20:10 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Dieter Lefeling <didis.mehlbox@web.de> - 2017-10-06 22:13 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Frank Möller <butterspiegeleiauftoast42@protonmail.com> - 2017-10-06 23:55 +0200
Re: Mal wieder: Rechner (auch) für Bildbearbeitung Matthias Andree <matthias.andree@gmx.de> - 2017-10-06 22:32 +0200
Page 10 of 11 — ← Prev page 1 … 8 9 [10] 11 Next page →
| From | Helmut Faugel <helmut.faugel@mnet-online.de> |
|---|---|
| Date | 2017-10-05 00:06 +0200 |
| Message-ID | <or3m0k$6bs$1@news-1.m-online.net> |
| In reply to | #284097 |
Am 04.10.2017 um 23:27 schrieb Thomas Poeschmann: > Dieter Lefeling <didis.mehlbox@web.de> wrote: >> Wenn es zu Gunsten der Lebensdauer ist, würde ich sonst einfach eine >> Version nehmen, die von sich aus die 1290 MHz bietet. Gibt es ja auch. > > Ähm, da müsste ich jetzt nachlesen. Grafikkartentod kenne ich nur durch > physische Gewalt. Ich kenne vor allem mistige Lötstellen der BGAs (Ball Grid Arrays). In der Arbeit wird da regelmäßig eines der Powerbooks zum Servicefall und auch mein altes Notebook von Dell hatte vor nach mehr als 7 Jahren so ein Problem ... > Performance unter Lightroom lässt sich sehr gut vom CineBench R15 Multi > ablesen. Doppelter Benchmark-Wert ist in LR doppelt so schnell. Mehr oder > weniger. Für mich ist das wichtig, so ein Zeitraffer hat 400-1000 Bilder. > Für 40 Sekunden. Für Dich heisst das auch Warten auf die Vorschau usw. Das > kann nerven. > i5-7600 ist schon ok. Bei 20 Megapixel Files kann man damit was machen. > Gerade wenn Du in 36er Serien denkst. Mein Notebook ist 20% langsamer und > das ist in Ordnung für mich, so 4-5 Sek bis das Bild in LR entwickelt ist. Tja, und DaVinci Resolve entwickelt in der selben Zeit mehr als ein Dutzend Raws ... > Beim Film wartest Du ja auch ne Woche auf die Entwicklung. Das macht der Dieter im Keller ;-) >> Für die angepeilte Konfiguration ist ein 120-mm-Lüfter vorne und ein >> 92-mm-Teil hinten vorgesehen. Dazu noch ein CPU-Lüfter, fertig. > > Hmm. Wenn ein 120mm Lüfter hinten gleich viel kostet... Aber die Frage ist > ob das Gehäuse das kann. Apple hat es damals mit dem G4/1,25GHz gezeigt wie man es nicht macht. Ein Lüftergeräusch wie eine Flugzeugturbine sowie USB 1.2 statt USB 2.0 liesen meine Ambitionen Obst einzusetzen endgültig sterben. -- Helmut Faugel
[toc] | [prev] | [next] | [standalone]
| From | Dieter Lefeling <didis.mehlbox@web.de> |
|---|---|
| Date | 2017-10-05 00:17 +0200 |
| Message-ID | <8elatc5lc5lmearqotmt538ehnjrls8cs2@4ax.com> |
| In reply to | #284097 |
Thomas Poeschmann schrieb: > [ Schnelle Grafikkarte ] > > Wenn Du mal n Video schauen willst ist es egal. Aber schon beim Encoding > eines Videos (kann ja mal vorkommen) und auch in PS und LR kann die Karte > unterstützen. Ich mache kein Video. Denke ich jedenfalls mal. 8-) Bei meinem letzten Rechner habe ich noch extra Firewire vorgesehen, das seinerzeit der Standard für DV war. Heute ist nicht nur die Technik eine andere. Auch mit AV-Präsentationen (Wings wurde erwähnt) habe ich nicht viel am Hut. > Link: > https://www.pugetsystems.com/labs/articles/Photoshop-CC-2017-NVIDIA-GeForce-GPU-Performance-899/ Interessant, dass die verschiedenen Karten gar nicht so viel Unterschied in der Performance bringen, und dass sie bei vielem sogar fast gleichauf liegen und selbst die boardinterne Grafik mithalten kann. > Und dann gibt es noch wie Stumpfl Wings, die brauchen so eine Grafikkarte > unbedingt. Ich erinnere mich an den Kampf eines Kollegen mit AV-Schwerpunkt, der immer hart an der Grenze der verfügbaren Hardware arbeitete. > > - geht das Übertakten nicht zu Lasten der Lebensdauer? > > Du übertaktest ja nicht, sondern machst was der Hersteller empfiehlt. Und > wenn der das so verkauft... Der Chip-Hersteller (Nvidia) gibt 1290 MHz als Basistakt an. Und gibt die Möglichkeit zum übertakten. Daher das OC (overclock) in der Bezeichnung diverser Karten. > Wenn man übertakten will, müsste man mehr kühlen. Deswegen sind gerne mal zwei Lüfter drauf. Oder bei anderen nur einer, wenn das reicht. Immhin wird die Kühlung aber anscheinend geregelt, so dass die Lüfter bei "Normalbetrieb" aus bleiben können. > > - wie ich es sehe, kann man im "Treiber" meist verschiedene Modi mit > > unterschiedlichen Taktraten einstellen. Ist es üblich, dass man dort > > auch auf die Standard-1290-MHz "runter" kann? > > Hmm ich würde da nix verstellen. Nicht *ver*stellen, sondern *ein*stellen. Man kann schließlich verschiedene Betriebsarten wählen. > Die Karte idelt doch eh wenn Du die nicht > brauchst. Generell würde ich die Kiste so nutzen, wie man mir die > hinstellt. Du willst ja nicht schrauben, hast Du gesagt. So ist es. Daher stellt sich die Frage nach der Karte, bei der die Ressourcen am besten geschont werden. > > Die Überlegung ist: > > > > - 250 GB System-SSD + 250 GB Daten-SSD > > - 500 GB SSD für beides > > - 500 GB System-SSD + 500 GB Daten-SSD $-) > > > > Eine HDD dann nur als externes Datenlager. > > Also so gesplittetes Zeug kann doof sein, da liegen dann auf c: noch 100 GB > brach und dann ärgert man sich. Also 1x 500 GB SSD. > Jürgen empfahl, den Nutzerordner auf d: zu packen. Die vorgeschlagene Arbeitsweise setzt anscheinend auf zwei separate SSD/HDDs. > Oder mach eine 500 GB > SSD und erstelle im Monatrhytmus ein BACKUP auf einer externen kleinen > Platte ^^ Beides geht. Das Backup erfordert Disziplin. Musst Du wissen. Und > machen. So in die Richtung wird es wohl gehen. > > RAM ist nun ja ein systemkritisches Bauteil. Gibt es da Empfehlungen? > > Ich glaube das ist egal, 2400 ist gängig. Darf halt nicht braten, wie an > anderer Stelle geschrieben. Fällt in Asien vom Band... "Darf nicht braten" soll wohl heißen, ohne diese "Kühlkörper". Das wird dann aber schwierig, gibt da nicht viel ohne ECC. > Beim Film wartest Du ja auch ne Woche auf die Entwicklung. Heute, ja. Auch mal länger. Früher (tm) habe ich keine Stunde gewartet. 8-) > Hmm. Wenn ein 120mm Lüfter hinten gleich viel kostet... Aber die Frage ist > ob das Gehäuse das kann. Das im Moment favorisierte Gehäuse ist für 120 + 92 mm vorgesehen. > Bei mir hängt der unter dem Schreibtisch. Nur als Idee... Das ist hier etwas ...weniger konventionell. Aber so kann ich am effektivsten arbeiten. So, jetzt muss ich aufpassen, dass das nicht wieder so wird wie damals mit dem Staubsauger. Da habe ich ein Vierteljahr nach dem perfekten Gerät gesucht. Die Dinge verselbständigen sich manchmal. Und dann gibt es zu einigen Punkten divergierende Ansichten, was die Sache nicht leichter macht. Jetzt muss langsam mal ein Punkt gemacht werden. Dieter
[toc] | [prev] | [next] | [standalone]
| From | Thomas Poeschmann <der_thomas3@freenet.de> |
|---|---|
| Date | 2017-10-05 10:51 +0000 |
| Message-ID | <1785014632.528893291.234526.der_thomas3-freenet.de@news.individual.de> |
| In reply to | #284106 |
Dieter Lefeling <didis.mehlbox@web.de> wrote: > Deswegen sind gerne mal zwei Lüfter drauf. Oder bei anderen nur einer, > wenn das reicht. Immhin wird die Kühlung aber anscheinend geregelt, so > dass die Lüfter bei "Normalbetrieb" aus bleiben können. Wenn du mir die genaue Bezeichnung sagst, dann kann ich auch nachschauen ob im c't Heftarchiv etwas positives oder negatives über das Modell drin steht. Gerade was die Lautstärke angeht. > Das wird dann aber schwierig, gibt da nicht viel ohne ECC. ECC gibt es nur bei AMD oder im Xeon. Habe ich die letzten 20 Jahre nicht vermisst, und mein Rechner läuft jeden Tag. Oder mehrere Rechner. Was aber nur bedeutet dass die statistische Wahrscheinlichkeit eines Speicherausfalls immer höher wird :) Schau einfach das der Speicher noch ein bisschen im Luftstrom ist. Normalerweise musst du dir darüber keine Gedanken machen, wenn eh zwei Gehäuselüfter verbaut sind.
[toc] | [prev] | [next] | [standalone]
| From | Frank Möller <butterspiegeleiauftoast42@protonmail.com> |
|---|---|
| Date | 2017-10-06 10:30 +0200 |
| Message-ID | <061017.103007.520#23@m-id.net.gr.vu> |
| In reply to | #284124 |
Thomas Poeschmann schrieb: > Dieter Lefeling <didis.mehlbox@web.de> wrote: >> Das wird dann aber schwierig, gibt da nicht viel ohne ECC. > ECC gibt es nur bei AMD oder im Xeon. Habe ich die letzten 20 Jahre nicht > vermisst, und mein Rechner läuft jeden Tag. Oder mehrere Rechner. Was aber > nur bedeutet dass die statistische Wahrscheinlichkeit eines > Speicherausfalls immer höher wird :) Tja, die Crux ist, daß Du bei Non-ECC-RAM gar nicht wissen kannst, ob er OK ist. Aber selbst dann, wenn Du einen Memtest über Nacht laufen läßt und der positiv ausfällt, kann es direkt danach beginnen, daß Fehler auftreten, und sei es nur sporadisch. Dummerweise zeigen solche Fehler sich auch nicht zwangsläufig in Blue Screens. Sie müssen auch nicht ständig auftreten, sporadisch ist das noch viel "interessanter". Mir sind meine Daten jedenfalls so viel wert, daß ich mittlerweile nur noch ECC-RAM verwende. Wenn das heißt, daß dann die CPU-Wahl etwas eingeschränkt ist, dann sei's drum. Gleichzeitig ist es nämlich sogar noch günstiger. Das ist ja der Witz schlechthin: Die i7 und i5 sind schweineteuer, enthalten dem Anwender aber ECC vor, was man beim günstigen AMD FX und beim neuen Ryzen jedoch "selbstverständlich einfach so" mit bekommt. Und die Käufer lassen das nicht nur mit sich machen, sondern sabbern diesem kastrierten Intel-Zeux wie Süchtige hinterher. Ziemlich strange, das. --
[toc] | [prev] | [next] | [standalone]
| From | Thomas Poeschmann <der_thomas3@freenet.de> |
|---|---|
| Date | 2017-10-06 10:05 +0000 |
| Message-ID | <2111792614.528976791.669427.der_thomas3-freenet.de@news.individual.de> |
| In reply to | #284197 |
Frank Möller <butterspiegeleiauftoast42@protonmail.com> wrote: > Thomas Poeschmann schrieb: >> Dieter Lefeling <didis.mehlbox@web.de> wrote: > >>> Das wird dann aber schwierig, gibt da nicht viel ohne ECC. > >> ECC gibt es nur bei AMD oder im Xeon. Habe ich die letzten 20 Jahre nicht >> vermisst, und mein Rechner läuft jeden Tag. Oder mehrere Rechner. Was aber >> nur bedeutet dass die statistische Wahrscheinlichkeit eines >> Speicherausfalls immer höher wird :) > > Tja, die Crux ist, daß Du bei Non-ECC-RAM gar nicht wissen kannst, ob er OK > ist. Aber selbst dann, wenn Du einen Memtest über Nacht laufen läßt und der > positiv ausfällt, kann es direkt danach beginnen, daß Fehler auftreten, und > sei es nur sporadisch. > > Dummerweise zeigen solche Fehler sich auch nicht zwangsläufig in Blue > Screens. Sie müssen auch nicht ständig auftreten, sporadisch ist das noch > viel "interessanter". Die Folgen eines Speicherfehler sind beruflich bei mir so, das Sie sofort sichtbar wären. Die Auswirkungen sind aber auch mehr oder weniger folgenlos. Und auf dem Produktivsystem gibt es dann ECC. Im privaten Bereich, was die Verarbeitung von Bildern angeht, ist das ebenfalls sichtbar und es gibt ein Backup. Das Backup zeigt dabei Konflikte auf, die ich als Mensch beheben muss. Der Fehler kann überall stecken. In der SSD, im Prozessor Mikrokernel, in elektromagnetischen Störungen, im Mainbord-Fehler, im Betrübssystem, in der Spannungsversorgung. Oh mein Gott, wenn ich darüber auch nur nachdenke wird mir schon schlecht. Und jetzt auch noch Nicht-ECC.
[toc] | [prev] | [next] | [standalone]
| From | Frank Möller <butterspiegeleiauftoast42@protonmail.com> |
|---|---|
| Date | 2017-10-06 14:46 +0200 |
| Message-ID | <061017.144654.572#23@m-id.net.gr.vu> |
| In reply to | #284199 |
Thomas Poeschmann schrieb: > Frank Möller <butterspiegeleiauftoast42@protonmail.com> wrote: >> Thomas Poeschmann schrieb: >>> Dieter Lefeling <didis.mehlbox@web.de> wrote: >>>> Das wird dann aber schwierig, gibt da nicht viel ohne ECC. >>> ECC gibt es nur bei AMD oder im Xeon. Habe ich die letzten 20 Jahre nicht >>> vermisst, und mein Rechner läuft jeden Tag. Oder mehrere Rechner. Was aber >>> nur bedeutet dass die statistische Wahrscheinlichkeit eines >>> Speicherausfalls immer höher wird :) >> Tja, die Crux ist, daß Du bei Non-ECC-RAM gar nicht wissen kannst, ob er OK >> ist. Aber selbst dann, wenn Du einen Memtest über Nacht laufen läßt und der >> positiv ausfällt, kann es direkt danach beginnen, daß Fehler auftreten, und >> sei es nur sporadisch. >> Dummerweise zeigen solche Fehler sich auch nicht zwangsläufig in Blue >> Screens. Sie müssen auch nicht ständig auftreten, sporadisch ist das noch >> viel "interessanter". > Die Folgen eines Speicherfehler sind beruflich bei mir so, das Sie sofort > sichtbar wären. Die Auswirkungen sind aber auch mehr oder weniger > folgenlos. Und auf dem Produktivsystem gibt es dann ECC. > Im privaten Bereich, was die Verarbeitung von Bildern angeht, ist das > ebenfalls sichtbar... Das behauptest Du halt, wissen kannst Du das ohne ECC nicht. > ... und es gibt ein Backup. Das Backup zeigt dabei Konflikte auf, die ich > als Mensch beheben muss. Fein, Du machst also bei jeder Datei und bei jeder Änderung einer Datei einen Prüfsummenabgleich. Glaube ich erstens nicht und bringt in der Form auch nix, denn die Datei, die Du gerade geändert hast, hat logischerweise eine andere Prüfsumme. Ob allerdings bei den Änderungen resp. beim Speichern ein RAM-Fehler zugeschlagen hat, ist nicht zwingend mit bloßem Auge zu sehen und wird in diesem Fall logischerweise auch mit dem weltbesten Prüfsummenverfahren nicht erkannt. Du kannst jetzt sagen: "Das ist mir wurscht". OK. Aber Du kannst nicht sagen, eventuelle RAM-Fehler hättest Du definitiv bemerkt. > Der Fehler kann überall stecken. Du willst es jetzt halt verwässern und damit bagatellisieren. Aber nein, ein RAM-Fehler kann _nicht_ "überall" stecken. Er steckt im RAM oder er existiert nicht. Ob er existiert, weißt Du halt nicht. Ich mit ECC _weiß_ es. > In der SSD, im Prozessor Mikrokernel, in elektromagnetischen Störungen, > im Mainbord-Fehler, im Betrübssystem, in der Spannungsversorgung. Fall Du damit andeuten willst, daß es außer RAM-Fehlern auch andere Hardware-Fehler geben kann: Ja, die Möglichkeit besteht. Falls Du damit andeuten willst, ECC wäre blödsinnig: Nein. Blödsinnig wäre es, ECC für blödsinnig zu halten. > Oh mein Gott, wenn ich darüber auch nur nachdenke wird mir schon > schlecht. Und jetzt auch noch Nicht-ECC. Ist halt das typische Gebrabbel der Intel-Süchtigen, wenn man sie mal ungeschminkt auf eine der größten Schwachstellen dieser Produktschiene hinweist. Aber was soll man machen, wenn man merkt, daß man für mangelhafte Produkte auch noch "Gourmetpreise" zahlt, weil's ja so "hip" ist? Da muß man dann mal eben schnell den Herricht machen. --
[toc] | [prev] | [next] | [standalone]
| From | Michael Unger <spam.to.unger@spamgourmet.com> |
|---|---|
| Date | 2017-10-06 16:06 +0200 |
| Subject | ECC-RAM (was: Re: Mal wieder: Rechner (auch) für Bildbearbeitung) |
| Message-ID | <f3pha7FffumU2@mid.individual.net> |
| In reply to | #284214 |
On 2017-10-06 14:46, "Frank Möller" wrote: > [...] > > [...] Aber nein, > ein RAM-Fehler kann _nicht_ "überall" stecken. Er steckt im RAM oder er > existiert nicht. Ob er existiert, weißt Du halt nicht. Ich mit ECC _weiß_ > es. So wie ich das vor langer Zeit mal mitbekommen hatte, kann man einen _einzelnen_ Bit-Fehler korrigieren und einen _doppelten_ zuverlässig erkennen; darüber hinaus waren keine Aussagen mehr möglich. Hat sich das mittlerweile geändert? > [...] Michael -- Real names enhance the probability of getting real answers. My e-mail account at DECUS Munich is no longer valid.
[toc] | [prev] | [next] | [standalone]
| From | Frank Möller <butterspiegeleiauftoast42@protonmail.com> |
|---|---|
| Date | 2017-10-06 18:31 +0200 |
| Subject | Re: ECC-RAM |
| Message-ID | <061017.183105.885#80@m-id.net.gr.vu> |
| In reply to | #284217 |
Michael Unger schrieb: > On 2017-10-06 14:46, "Frank Möller" wrote: >> [...] Aber nein, >> ein RAM-Fehler kann _nicht_ "überall" stecken. Er steckt im RAM oder er >> existiert nicht. Ob er existiert, weißt Du halt nicht. Ich mit ECC _weiß_ >> es. > So wie ich das vor langer Zeit mal mitbekommen hatte, kann man einen > _einzelnen_ Bit-Fehler korrigieren und einen _doppelten_ zuverlässig > erkennen; darüber hinaus waren keine Aussagen mehr möglich. Bei 1- und 2-Bit-Fehlern stimmt das, was Du sagst, darüber hinaus ist es AFAIK etwas anders. Auch Mehr-Bit-Fehler werden üblicherweise erkannt. Es kann jedoch vorkommen, daß _einzelne_ Mehr-Bit-Fehler nicht erkannt werden. Dies kann aber nur bei ebensolchen Mehr-Bit-Fehlern und nur in einzelnen Fällen passieren. Damit ist die Geschichte jedoch nicht zu Ende, denn zunächst muß man noch feststellen, daß ca. 99 % aller auftretenden RAM-Fehler generell 1-Bit-Fehler sind. Einem 2-Bit-Fehler gehen üblicherweise erst einmal 1-Bit-Fehler voraus. Wenn dann mal irgendwann auch Mehr-Bit-Fehler auftreten, ist das also prinzipiell schon mal eine mikroskopisch kleine Wahrscheinlichkeit, daß es sie überhaupt gibt, bevor man die Warnungen im Log (1-Bit-Fehler) und die Blue Screens (2-Bit-Fehler) bemerken konnte. Daß ein Mehr-Bit-Fehler plötzlich unvermittelt auftritt, ist also schon mal extrem selten. Noch seltener ist es, daß ein Mehr-Bit-Fehler plötzlich unvermittelt auftritt _und_ es sich auch noch um einen solchen handelt, der bei der Prüfung nicht erkannt wird. Die Wahrscheinlichkeit, daß Mehr-Bit-Fehler auftreten _und_ diesen vorher keine 1-Bit-Fehler _und_ auch keine 2-Bit-Fehler vorausgingen _und_ es sich dann ausgerechnet auch noch immer um nicht erkannte Mehr-Bit-Fehler handelt, ist so derartig winzig, daß man AFAIK dafür dann keine zusätzlichen Mechanismen mehr vorgesehen hat. --
[toc] | [prev] | [next] | [standalone]
| From | Falk Dµebbert <falk@duebbert.com> |
|---|---|
| Date | 2017-10-09 18:11 +0200 |
| Subject | Re: ECC-RAM |
| Message-ID | <org73r$ueb$1@news.albasani.net> |
| In reply to | #284217 |
Am 06.10.17 um 16:06 schrieb Michael Unger: > On 2017-10-06 14:46, "Frank Möller" wrote: > >> [...] >> >> [...] Aber nein, >> ein RAM-Fehler kann _nicht_ "überall" stecken. Er steckt im RAM oder er >> existiert nicht. Ob er existiert, weißt Du halt nicht. Ich mit ECC _weiß_ >> es. > > So wie ich das vor langer Zeit mal mitbekommen hatte, kann man einen > _einzelnen_ Bit-Fehler korrigieren und einen _doppelten_ zuverlässig > erkennen; darüber hinaus waren keine Aussagen mehr möglich. Hat sich das > mittlerweile geändert? Das ist pro Block richtig. Bei 1-8-organisiertem RAM und 4 Modulen kannst Du also 32 Fehler korrigieren. Windows >7 kann mit ECC-Fehlern übrigens entscheiden, ob es BSOD macht oder einfach weiterläuft. Falk D.
[toc] | [prev] | [next] | [standalone]
| From | v_borchert@despammed.com (Volker Borchert) |
|---|---|
| Date | 2017-10-10 18:39 +0000 |
| Subject | Re: ECC-RAM |
| Message-ID | <orj45g$fvv$1@Gaia.teknon.de> |
| In reply to | #284217 |
Michael Unger wrote: > On 2017-10-06 14:46, "Frank Möller" wrote: > > > [...] > > > > [...] Aber nein, > > ein RAM-Fehler kann _nicht_ "überall" stecken. Er steckt im RAM oder er > > existiert nicht. Ob er existiert, weißt Du halt nicht. Ich mit ECC _weiß_ > > es. > > So wie ich das vor langer Zeit mal mitbekommen hatte, kann man einen > _einzelnen_ Bit-Fehler korrigieren und einen _doppelten_ zuverlässig > erkennen; darüber hinaus waren keine Aussagen mehr möglich. Hat sich das > mittlerweile geändert? Kommt auf den Code an, Stichwort "Hamming-Distanz". Gängige Verfahren mit (n+2) Prüfbits für (2^n) Nutzbits haben eine solche von 4, d.h. beliebige zwei gültige Speicherworte unterscheiden sich an mindestens 4 Stellen. Bei zwei gekippten Bits kann man damit zwar noch erkennen, daß dies der Fall ist, aber nicht mehr, von welcher Seite man kam. Durch geeignete Prüfsummen erreicht man außerdem, daß jedes gültige Speicherwort mindestens zwei Nullen und mindestens zwei Einsen enthält und erkennt so außerdem "alles 0" oder "alles 1". Man nimmt dabei an, daß die Wahrscheinlichkeiten für mehrere Kipper in ein und demselben Wort mit steigendes Anzahl so klein werden, daß die bei mehr als hd/2 theoretisch möglichen Falscherkennungen "nicht" vorkommen. So wenigstens IIRC die Theorie. Siehe beispielsweise die Datenblätter zu den TTLs 74LS6xx von TI, da waren auch die Prüfsummenformeln genau beschrieben. Hat die eigentlich irgendjemand mal wirklich in der Hand gehabt oder waren sie Vaporware? Ich hoffe trotzdem, daß Avionik, Medizintechnik und Kernkraftwerke _kein_ ECC-DRAM verwenden sondern SRAM ;-) -- "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]
| From | Gerrit Heitsch <gerrit@laosinh.s.bawue.de> |
|---|---|
| Date | 2017-10-10 21:37 +0200 |
| Subject | Re: ECC-RAM |
| Message-ID | <orj7ip$ef5$1@news.bawue.net> |
| In reply to | #284426 |
On 10/10/2017 08:39 PM, Volker Borchert wrote: > Michael Unger wrote: >> On 2017-10-06 14:46, "Frank Möller" wrote: >> >>> [...] >>> >>> [...] Aber nein, >>> ein RAM-Fehler kann _nicht_ "überall" stecken. Er steckt im RAM oder er >>> existiert nicht. Ob er existiert, weißt Du halt nicht. Ich mit ECC _weiß_ >>> es. >> >> So wie ich das vor langer Zeit mal mitbekommen hatte, kann man einen >> _einzelnen_ Bit-Fehler korrigieren und einen _doppelten_ zuverlässig >> erkennen; darüber hinaus waren keine Aussagen mehr möglich. Hat sich das >> mittlerweile geändert? > > Kommt auf den Code an, Stichwort "Hamming-Distanz". Gängige Verfahren > mit (n+2) Prüfbits für (2^n) Nutzbits haben eine solche von 4, d.h. > beliebige zwei gültige Speicherworte unterscheiden sich an mindestens > 4 Stellen. Bei zwei gekippten Bits kann man damit zwar noch erkennen, > daß dies der Fall ist, aber nicht mehr, von welcher Seite man kam. > Durch geeignete Prüfsummen erreicht man außerdem, daß jedes gültige > Speicherwort mindestens zwei Nullen und mindestens zwei Einsen enthält > und erkennt so außerdem "alles 0" oder "alles 1". Es gibt auch ECC-Kodierungen die mehr können. Stichwort 'Chipkill'. Damit kannst du bis zu 4 defekte Bits erkennen und korrigieren und 8 zuverlässig erkennen. Diese Stufe braucht man allerdings eher selten, NASA z.B. > Man nimmt dabei an, daß die Wahrscheinlichkeiten für mehrere Kipper > in ein und demselben Wort mit steigendes Anzahl so klein werden, daß > die bei mehr als hd/2 theoretisch möglichen Falscherkennungen "nicht" > vorkommen. Bei 'Chipkill'-ECC wird davon ausgegangen, daß auch mal ein ganzer IC ausfallen kann und deshalb werden die ECC-Bits so verteilt, daß das System danach trotzdem noch funktioniert. Man könnte es als RAID5 fürs RAM bezeichnen. :) > So wenigstens IIRC die Theorie. Siehe beispielsweise die Datenblätter > zu den TTLs 74LS6xx von TI, da waren auch die Prüfsummenformeln genau > beschrieben. Hat die eigentlich irgendjemand mal wirklich in der Hand > gehabt oder waren sie Vaporware? Ich kenne nur den 74LS688, aber das ist ein reiner Vergleicher, er sagt dir ob an den beiden 8Bit-Inputs dasselbe Bitmuster anliegt. Den gab es, ich hab ihn verbaut gesehen. Ist von der Funktion her identisch zum 74F521. Typische Anwendung waren I/O-Karten bei denen man die Adresse per Software ändern konnte. So ziemlich jede Karte für den Amiga die dessen Autoconfig-Logik benutzte hatte einen 74LS688 oder 74F521 in der Schaltung. > Ich hoffe trotzdem, daß Avionik, Medizintechnik und Kernkraftwerke > _kein_ ECC-DRAM verwenden sondern SRAM ;-) SRAM ist immer noch sehr teuer wenn man es mit DRAM vergleicht... und genauso Hardware, auch dort sterben hin und wieder Zellen. Ohne ECC geht es also auch bei SRAM nicht. Gerrit
[toc] | [prev] | [next] | [standalone]
| From | v_borchert@despammed.com (Volker Borchert) |
|---|---|
| Date | 2017-10-10 20:26 +0000 |
| Subject | Re: ECC-RAM |
| Message-ID | <orjaco$hdg$1@Gaia.teknon.de> |
| In reply to | #284432 |
In de.rec.fotografie, Gerrit Heitsch wrote: > On 10/10/2017 08:39 PM, Volker Borchert wrote: > > > So wenigstens IIRC die Theorie. Siehe beispielsweise die Datenblätter > > zu den TTLs 74LS6xx von TI, da waren auch die Prüfsummenformeln genau > > beschrieben. Hat die eigentlich irgendjemand mal wirklich in der Hand > > gehabt oder waren sie Vaporware? > > Ich kenne nur den 74LS688, aber das ist ein reiner Vergleicher, Den kenn ich natürlich auch, müßten noch irgendwo ein paar herumliegen. <databook vendor="TI" vintage="1985"> Ich meinte aber 630..631 error detection and correction 16 bit 632..633 error detection and correction 32 bit with byte write 634..635 error detection and correction 32 bit 636..637 error detection and correction 8 bit insbesondere im Zusammenspiel mit 600..603 memory refresh controller 604..607 octal 2-input multiplexed registers 608 memory cycle controller 610..613 memory mappers </> -- "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]
| From | Matthias Weingart <mwnews@pentax.boerde.de> |
|---|---|
| Date | 2017-10-11 06:44 +0000 |
| Subject | Re: ECC-RAM |
| Message-ID | <XnsA80B58F00BA00AlwLookOnTBrightSide@penthouse.boerde.de> |
| In reply to | #284432 |
Gerrit Heitsch <gerrit@laosinh.s.bawue.de>: > >> Ich hoffe trotzdem, daÇY Avionik, Medizintechnik und Kernkraftwerke >> _kein_ ECC-DRAM verwenden sondern SRAM ;-) > > SRAM ist immer noch sehr teuer wenn man es mit DRAM vergleicht... und > genauso Hardware, auch dort sterben hin und wieder Zellen. Ohne ECC geht > es also auch bei SRAM nicht. Ist RAM nicht anfällig gegen Alphateilchen, die aus dem Gehäusematerial kommen? (DRAM sicherlich mehr als SRAM). M. --
[toc] | [prev] | [next] | [standalone]
| From | Patrick Schaefer <pa.schaefer@web.de> |
|---|---|
| Date | 2017-10-11 22:13 +0200 |
| Subject | Re: ECC-RAM |
| Message-ID | <f47cc3Fmj7pU1@mid.individual.net> |
| In reply to | #284453 |
Am 11.10.2017 08:44 schrieb Matthias Weingart: > Ist RAM nicht anfällig gegen Alphateilchen, die aus dem Gehäusematerial > kommen? (DRAM sicherlich mehr als SRAM). So ist es. Ich kann mich an einen Artikel aus den '80ern erinnern, in dem nachgewiesen wurde, dass Computer maximal 500k RAM haben dürfen um weniger als einen Bitkipper pro Tag zu haben. IBM hat das zum Anlass genommen, um seinem PC (mit 64kB) und PC/XT (mit bis zu 640kB -- mehr braucht niemand ;-) Paritätsbits zu spendieren. Zum Glück haben die RAM-Hersteller das Problem mit der 256kbit-Chipgeneration in den Griff bekommen. Patrick
[toc] | [prev] | [next] | [standalone]
| From | Rolf Bombach <rolfnospambombach@invalid.invalid> |
|---|---|
| Date | 2017-10-11 22:47 +0200 |
| Subject | Re: ECC-RAM |
| Message-ID | <orm00b$34i$1@dont-email.me> |
| In reply to | #284453 |
Matthias Weingart schrieb: > Gerrit Heitsch <gerrit@laosinh.s.bawue.de>: > >> >>> Ich hoffe trotzdem, daÇY Avionik, Medizintechnik und Kernkraftwerke >>> _kein_ ECC-DRAM verwenden sondern SRAM ;-) >> >> SRAM ist immer noch sehr teuer wenn man es mit DRAM vergleicht... und >> genauso Hardware, auch dort sterben hin und wieder Zellen. Ohne ECC geht >> es also auch bei SRAM nicht. > > Ist RAM nicht anfällig gegen Alphateilchen, die aus dem Gehäusematerial > kommen? (DRAM sicherlich mehr als SRAM). Heutige Gehäusematerialien sind speziell ausgesucht. Problem scheint heute kosmische Strahlung zu sein. https://en.wikipedia.org/wiki/Soft_error#Cosmic_rays_creating_energetic_neutrons_and_protons Suche nach "bit flip cosmic ray" fördert einiges zutage, die Grenze zur Verschwörungstheorie verschwimmt allerdings. -- mfg Rolf Bombach
[toc] | [prev] | [next] | [standalone]
| From | Helmut Faugel <helmut.faugel@mnet-online.de> |
|---|---|
| Date | 2017-10-10 23:32 +0200 |
| Subject | Re: ECC-RAM |
| Message-ID | <orjeaa$q2e$1@news-1.m-online.net> |
| In reply to | #284426 |
Am 10.10.2017 um 20:39 schrieb Volker Borchert: > So wenigstens IIRC die Theorie. Siehe beispielsweise die Datenblätter > zu den TTLs 74LS6xx von TI, da waren auch die Prüfsummenformeln genau > beschrieben. Hat die eigentlich irgendjemand mal wirklich in der Hand > gehabt oder waren sie Vaporware? ECC-RAM gabs in diveren VAXen ... -- Helmut Faugel
[toc] | [prev] | [next] | [standalone]
| From | Gerhard Hoffmann <gerhard@hoffmann-hochfrequenz.de> |
|---|---|
| Date | 2017-10-11 02:59 +0200 |
| Subject | Re: ECC-RAM |
| Message-ID | <f458mlF7fr2U1@mid.individual.net> |
| In reply to | #284426 |
Am 10.10.2017 um 20:39 schrieb Volker Borchert: > So wenigstens IIRC die Theorie. Siehe beispielsweise die Datenblätter > zu den TTLs 74LS6xx von TI, da waren auch die Prüfsummenformeln genau > beschrieben. Hat die eigentlich irgendjemand mal wirklich in der Hand > gehabt oder waren sie Vaporware? Ich habe das schon mal zu 80386-Zeiten auf einer Multibus-Karte benutzt. War aber WIMRE in meinem Fall Intel oder Fairchild. Das war damals, als echte Panik aufkam wegen Bitkippern in RAMs in den edlen Keramik- gehäusen. Plastikgehäuse waren eher nicht betroffen, es waren irgend- welche Isotope in der Keramik, die Alphastrahlen verschossen haben. (Kam später raus.) > Ich hoffe trotzdem, daß Avionik, Medizintechnik und Kernkraftwerke > _kein_ ECC-DRAM verwenden sondern SRAM ;-) SRAM ist keinen Deut besser. Eine Zelle, die getroffen wird, vergisst ihren Inhalt. Sie enthält mehr Transistoren, also gibt sie ein noch größeres Ziel ab. FPGAs speichern ihre Programmierung üblicherweise in einem riesigen statischen RAM ab. Das macht ihre Benutzung in der Raumfahrt ziemlich heikel. Man kann aber nicht darauf verzichten. Ich habe gerade ein Projekt hinter mir, wo der Konfigurationsspeicher des FPGAs alle halbe Minuten neu aus einem Rom geladen wurde. Die Benutzerlogik, also das, was das FPGA wirklich tun soll, war dann dreifach redundant, in der Hoffnung, dass es in der halben Minute nicht 2 Nachbarn mit gleicher Funktion trifft. Das Nachladen wurde vom FPGA selbst gesteuert. Das ist dann so, als ob man selber den Teppich austauscht auf dem man steht. Oder, als ob man sich selbst operiert und sein eigenes Gehirn gegen ein Backup austauscht. Das krankste, was ich jemals habe bauen müssen. Wenn man das alles richtig und bewiesen hat, kann immer noch der Spannungsregler einen "single event upset" bekommen. Der ist dann für eine Millisekunde besinnungslos und dreht so lange ganz auf oder ganz zu. Der Rest des Reglers muss das abkönnen ohne daß was abkocht. Bei ECC kann man dermaßen viel falsch machen, dass es für mich eher das Problem ist, als dessen Lösung es gilt. Wenn man etwas in den Weltraum schießt, dann muss man wegen der dortigen Strahlenbelastung eben durch und muss beweisen, dass das auch funktioniert. Unter meinem Schreibtisch würde ein China-Motherboard mit ECC-Feature eher keine Heimat finden. Gruß, Gerhard
[toc] | [prev] | [next] | [standalone]
| From | v_borchert@despammed.com (Volker Borchert) |
|---|---|
| Date | 2017-10-11 03:15 +0000 |
| Subject | Re: ECC-RAM |
| Message-ID | <ork2cc$njf$1@Gaia.teknon.de> |
| In reply to | #284446 |
In de.rec.fotografie, Gerhard Hoffmann wrote: > Am 10.10.2017 um 20:39 schrieb Volker Borchert: > > > Ich hoffe trotzdem, daß Avionik, Medizintechnik und Kernkraftwerke > > _kein_ ECC-DRAM verwenden sondern SRAM ;-) > > SRAM ist keinen Deut besser. Eine Zelle, die getroffen wird, vergisst > ihren Inhalt. Sie enthält mehr Transistoren, also gibt sie ein noch > größeres Ziel ab. Ist der kontinuierliche Stromfluß einer SRAM Zelle wirklich genauso empfindlich gegen vorbeiknallende Strahlung wie die wenigen hundert (Aussage des Dozenten 1987 - heute vermutlich noch deutlich weniger) Elektronen eines DRAM-Kondensators? Verblüfft vb -- "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]
| From | Helmut Faugel <helmut.faugel@mnet-online.de> |
|---|---|
| Date | 2017-10-11 09:12 +0200 |
| Subject | Re: ECC-RAM |
| Message-ID | <orkg9o$1p7h$1@gwdu112.gwdg.de> |
| In reply to | #284447 |
Am 11.10.2017 um 05:15 schrieb Volker Borchert: > In de.rec.fotografie, Gerhard Hoffmann wrote: >> Am 10.10.2017 um 20:39 schrieb Volker Borchert: >> >>> Ich hoffe trotzdem, daß Avionik, Medizintechnik und Kernkraftwerke >>> _kein_ ECC-DRAM verwenden sondern SRAM ;-) >> >> SRAM ist keinen Deut besser. Eine Zelle, die getroffen wird, vergisst >> ihren Inhalt. Sie enthält mehr Transistoren, also gibt sie ein noch >> größeres Ziel ab. > > Ist der kontinuierliche Stromfluß einer SRAM Zelle 1 uA geteilt durch 1 Million Speicherzellen ist wieviel? > wirklich genauso > empfindlich gegen vorbeiknallende Strahlung wie die wenigen hundert > (Aussage des Dozenten 1987 - heute vermutlich noch deutlich weniger) > Elektronen eines DRAM-Kondensators? Wenige hundert? Kann ich mir nicht so recht vorstellen, denn in den letzten 30 Jahren ist die Kapazität je Speicherzelle gerademal von rund 100 fF auf etwa 25 fF geschrumpft und man hat Klimmzüge gemacht um diese Kapazität hinzubekommen (zB. Hafniumoxid als Dielektrikum). Einige zehntausend Elektronen, wie in einem satt belichteten Pixel, scheint realistischer. -- Helmut Faugel
[toc] | [prev] | [next] | [standalone]
| From | v_borchert@despammed.com (Volker Borchert) |
|---|---|
| Date | 2017-10-22 16:46 +0000 |
| Subject | Re: ECC-RAM |
| Message-ID | <osii0f$3fm$2@Gaia.teknon.de> |
| In reply to | #284457 |
Helmut Faugel wrote: > Am 11.10.2017 um 05:15 schrieb Volker Borchert: > > > > Ist der kontinuierliche Stromfluß einer SRAM Zelle wirklich genauso > > empfindlich gegen vorbeiknallende Strahlung wie die wenigen hundert > > (Aussage des Dozenten 1987 - heute vermutlich noch deutlich weniger) > > Elektronen eines DRAM-Kondensators? > > Wenige hundert? Kann ich mir nicht so recht vorstellen, denn in den > letzten 30 Jahren ist die Kapazität je Speicherzelle gerademal von > rund 100 fF auf etwa 25 fF geschrumpft und man hat Klimmzüge gemacht > um diese Kapazität hinzubekommen (zB. Hafniumoxid als Dielektrikum). > > Einige zehntausend Elektronen, wie in einem satt belichteten Pixel, > scheint realistischer. 100fF = 1E-13 As/V 1As ~ 6,24E+18 e Sieht so aus, als habe der gute Mann sich damals geirrt oder handele es sich um 30 Jahre alte fakenews... -- "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]
Page 10 of 11 — ← Prev page 1 … 8 9 [10] 11 Next page →
Back to top | Article view | de.rec.fotografie
csiph-web