> Alle, die auf professionelle, also kommerzielle Software, setzen und
> nicht auf OpenSource-Bastelware, für die besteht keine Gefahr!
>
> Quelle: Oben genannter Heise-Artikel:
> […]
> Intel beruhigt jedoch, der Fehler sei auf kommerziellen Plattformen
> und mit kommerzieller Software noch nie beobachtet worden.
> […]
>
> Wer allerdings auf z.B. das BastelOS Linux setzt, für den besteht
> natürlich die Geafahr, dass er durch seine minderwertige Frickelware
> mit solchen und natürlich vielen anderen Problemen rechnen MUSS.
>
> Mal wieder seht ihr: Winows ist einfach besser als Linux - und wieder
> einmal habe ich einen Beweis dafür!
Genau! Und außerdem gilt noch immer: Nachts ist es kälter als
draußen!
>
> Denkt mal darüber nach!
latürnich!
speicherst der logische unterschied durchaus bewusst .. aber was waere
> nun der vorteil NOR-Flashs zu benutzen statt NAND ?
>
> Weiss jemand mehr ?
Da müßte man konkret Baustein-Daten vergleichen. Auf dem ganzen
Flash-Geraffel was du als USB-Sticks, SDRAM etc kriegst ist ja
nochnichtmal die begrenzte Zahl der Schreibzyklen erwähnt, geschweige
denn spezifiziert. Die Zahl der Schreibzyklen änderte sich auch je
nach Anwendung im Laufe der Entwicklung.
CPUs und FPGAs waren anfangs auf 10 Schreibzyklen spezifiert, das
liegt heute deutlich höher. Reine Flash-Speicherchips stiegen in der
Zuverlässigkeit bis über 10^6 Schreibzyklen, Tendenz ist bei NAND mit
der Verkleinerung der Geometrien aber wieder sinkend.
http://de.wikipedia.org/wiki/Flash-Speicher
http://en.wikipedia.org/wiki/Flash_memory
Vergleich NOR-NAND:
http://www.linuxdevices.com/articles/AT4422361427.html
Der Hersteller MICRON scheint nur noch NAND herzustellen, NOR war in
google zu finden, aber nicht auf der Website:
http://www.micron.com/products/nand/
http://www.micron.com/products/nor/
Und über Samsungs jüngsten NAND:
http://www.heise.de/newsticker/meldung/74785
http://www.heise.de/ix/news/foren/go.shtml?read=1
Ich nehme an das war die Absicht hinter “Jedec” (also die
> Entwicklung
> neuer Speicherverfahren, die moeglichst nicht von einer Firma
> alleine
> kontrolliert werden). Bedauerlicherweise hat sich Rambus sich ja
> anscheinend mit den patentierbaren Ideen davongemacht.
Wie wäre es dann mit einer Klage gegen RAMBUS. Wenn die was gemeinsam
entwickeln, kann RAMBUS nicht einfach sagen “Machts gut Ihr Trottel,
ich verkaufe Euch jetzt unsere Entwicklung.” Das ist dann ebenfalls
Diebstahl geistigen Eigentums.
> Wenn man sich
> ansieht auf was alles Patente gewaehrt werden, so wuerde es mich
> wundern, wenn die Rambus Patente nicht so allgemein gehalten
> waeren,
> dass die Entwicklung neuer Standards eben nicht trivial waere.
Wird Zeit, daß die Leute in den Patentämtern mal gegen kompetente
ausgetauscht werden. Kann ja nicht sein, daß man alles was sich
technisch anhört patentieren kann, nur weil der Typ damit nichts
anfangen kann.
Farnsworth
> und wenn man sich auf Kapitalverbrecher beschränken würde: Mord,
> Entführung, organisierte Kriminalität. Aber wies aussieht, sollen
> damit auch Falschparker international gesucht werden. Es ist wie
> immer: Die Einschränkungen werden für Schwerverbrecher gemacht und
> die kleinen Fische und unschuldigen trifft es.
Schlimmer noch: die Schwerverbrecher haben ja oft die nötige
Technologie und sind weit voraus. Die kriegt man damit soweiso nicht.
Aber letztlich will ja die Musik- und Film-Industrie auch die Namen
derer wissen, die ihre Medien tauschen. Und ich sehe schon wie
komplette Falschparker-Ringe zerschlagen werden und das Bush-mäßig
als großer Erfolg der neuen Gesetze hingestellt wird. Eine arme Welt,
in der sowas hanebüchenes möglich ist. Naja, wenigstens wird es am
schnellsten die Politiker selbst treffen, denn: Wenn irgendwo Daten
rumliegen, sind sie in 99% der Fälle schlecht geschützt (gerade bei
Providern haben so viele Massen an Personen Zugriff auf sowas), d.h.,
Bild
speicherhabe heute mein neues Notebook bekommen und dabei eine Frage:
angeblich ist in dem Notebook 2x SO-Dimm mit 512MB vom Typ DDR-2
PC533 verbaut. Ich hatte nun damit gerechnet, von SiSoft Sandra eine
Geschwindigkeit von 266MHz angezeigt zu bekommen. Stattdessen zeigt
Sandra aber eine Geschwindigkeit von “2x 160 Mhz (320MHz Datenrate)”.
Ist das normal und ich verstehe das einfach nicht richtig, oder taugt
das Notebook nichts?
Danke fuer eure Hilfe,
Campus
Die sonstige Ausstattung laut Sandra:
SiSoftware Sandra
System
Hersteller : HYRICAN_AG
Modell : M660JE
Version : REFERENCE
Seriennummer : 0123456789
Nr : 4FF59000-0000839C-00000000-00000000
Gehäuse
Hersteller : CLEVO
Typ : Desktop
Abschließbar : Nein
Mainboard
Hersteller : CLEVO
MP Unterstützung : 1 Prozessor(en)
MPS Version : 1.40
Modell : M660JE
Version : REFERENCE
Seriennummer : 0123456789
System Speichersteuerung
Ort : Mainboard
Fehlerkorrektur : Kein(e)
Anzahl von Speichersteckplätzen : 2
Maximal installierbarer Speicher : 4GB
Bank 1 - S1 : DIMM Synchron DRAM 512MB/32
Bank 2 - S2 : DIMM Synchron DRAM 512MB/32
Chipsatz 1
Modell : Advanced Micro Devices (AMD) Athlon 64 / Opteron
HyperTransport Technology Configuration
Bus(se) : PCI PCIe CardBus USB FireWire/1394
Version : 1.02
Front Side Bus Geschwindigkeit : 2x 804MHz (1608MHz Datenrate)
Maximale FSB-Geschwindigkeit / Speichergeschwindigkeit : 2x 800MHz /
2x 400MHz
Ein/Aus-Breite : 16-bit / 16-bit
EA Warteschlangentiefe : 4 Anfrage(n)
Chipsatz 1 Hub Schnittstelle
Typ : HyperTransport
Version : 1.02
Ein/Aus-Breite : 16-bit / 16-bit
Geschwindigkeit : 2x 804MHz (1608MHz Datenrate)
Logische/Chipsatz 1 Speicherbänke
Bank 0 : 512MB DDR2-SDRAM 4.0-4-4-12 (tCL-tRCD-tRP-tRAS) CR1
Bank 1 : 512MB DDR2-SDRAM 4.0-4-4-12 (tCL-tRCD-tRP-tRAS) CR1
Kanäle : 1
Geschwindigkeit : 2x 160MHz (320MHz Datenrate)
Multiplikator : 1/5x
Breite : 128-bit
Speicher-Controller im Prozessor : Ja
Kerne pro Speicher-Controller : 2 Einheit(en)
Auffrischrate : 7.80
speichers, und bleibt es.
> Die Argumentation ist, wie üblich bei Intel, immer die selbe.
> Das Problem wird im Alltag kaum auftreten.
> Kenne ich irgendwie schon von den letzten 10 Fehlern der
> Intelprozessoren.
>
(…)
> ist es schlicht und einfach ein Designfehler beim Hyperthreading
> bzw. beim PowerManagement.
ich kann mir nicht helfen, aber so gravierend finde ich das nun auch
wieder nicht. Extras-Code oder komplexere Chiplogik, die ja auch
wieder potentielle Fehlerquellen bergen können, um exotische
Konfigurationen zu befriedigen, deren Nutzen nicht absehbar ist,
sollte man vermeiden und die Randbedingungen eben spezifizieren, wie
das ja nun wohl (nachträglich) geschehen ist.
Das ist ja wohl ganau das Problem, dass die aktuellen
Rechnerarchitekturen mit allen möglichen und unmöglichen
Konfigurationsvarianten zurechtkommen sollen und dadurch eine
Komplexität erzeugt wird, die letzten Endes nicht mehr beherrscht
wird.
In diesem Falle denke ich, hätte man berechtigt sagen können, it’s a
feature not a bug.
slk04
speichers, und bleibt es.
> Die Argumentation ist, wie üblich bei Intel, immer die selbe.
> Das Problem wird im Alltag kaum auftreten.
> Kenne ich irgendwie schon von den letzten 10 Fehlern der
> Intelprozessoren.
So? Von welchen denn? Ich befuerchte fast, mehr als den FDIV-Bug
kannst Du nicht nennen.
> Ändert aber alles nichts daran, dass es einfach aus Dummheit
> vergessen wurde, einen solchen Fall zu berücksichtigen.
Mein Gott. Auf was fuer einem hohen Ross muss man sitzen, um
derartige Fehler gleich mit der Dummheit der Ingenieure, der Firma
oder was weiss ich mit wessen Dummheit in Verbindung zu bringen.
Intel ist schliesslich kein Billigheimer oder Schlamperladen.
Der Fehler tritt unter unguenstigen Umstaenden auf, was nicht heisst,
dass sie niemand beruecksichtig haette, sondern dass sie nie
ausgiebig getestet wurden, weil niemand die CPU jemals in diesen
Betriebszustand gebracht hat, geschweige denn jemals bringen wird.
Oder hast Du Belege dafuer, dass ein System mit P4 mit HT haeufiger
abstuerzt als normal waere. Ich nicht.
Ich wette, Du hast noch nie ein komplexeres digitales System
entworfen? Hast Du eigentlich nur die geringste Ahnung, welche
Eventualitaeten es bei einem derart komplexen System wie einer
modernen CPU zu beruecksichtigen gilt. Es ist praktisch unmoeglich
hier fehlerfrei zu arbeiten. Intel dokumentiert ihre Bugs seit dem
FDIV-Disaster wenigstens oder zieht CPUs zurueck, wenn die Fehler
wirklich gravierend sind (etwa beim PIII-1133).
> Da das ganze Problem scheinbar in der Kommunikation mit dem Chipsatz
> liegt,
> ist es schlicht und einfach ein Designfehler beim Hyperthreading
> bzw. beim PowerManagement.
Ach wie furchtbar. Wenn Du wuesstest, was fuer Fehler in moderner
Hardware und Software lauern. Wenn Du einen hundertprozentig
fehlerfreien Prozessor woelltest, dann haetten wir vielleicht heute
erst einen fehlerarmen 486er der so teuer waere wie ein P4 - und
selbst fuer dessen Fehlerfreiheit wuerde niemand garantieren
koennen…
queue
speichers teurer ist, als Lizenzgebühren zahlen?
> Weil das länger dauert, als Lizenzgebühren bezahlen?
Auf kurze Sicht schon auf lange Sicht nicht.
Wie war das früher mit den Telefonen bei der Telekom? 2,30DM Miete im
Monat ist natürlich billiger als 149DM für ein eigenes Telefon. Aber
meine Eltern haben in 8 Jahren mehr für dieses Popeltelefon ausgegeben,
als es Wert war.
> Weil man, um einen neuen Standard zu setzen, eine gewaltige
> Marktmacht
> braucht? Intel tut sich ja schon schwer genug, DRDRAM zu
> etablieren,
> selbst wenn er teilweise wesentlich bessere Leistung bringt als
> SDRAM?
Intel ist aber auch nicht DIE Marktmacht. Wenn Intel sagt ich will
DRDRAM und die Speicherhersteller sagen “iss nich” dann iss nich. Und
wer kauft denn heute Boards mit Intelchipsatz? Da AMD immer größer
werdende Marktanteile bekommt, würde ich sagen, daß eher VIA das rennen
macht, da VIA Chipsätze für AMD und Intelboards macht.
Außerdem wenn sich die führenden Chipschmieden zusammenschließen und
RAMBUS außen vor lassen, dann ist das eine Marktmacht.
Farnsworth
speicherst es, und bleibt es.
> > Die Argumentation ist, wie üblich bei Intel, immer die selbe.
> > Das Problem wird im Alltag kaum auftreten.
> > Kenne ich irgendwie schon von den letzten 10 Fehlern der
> > Intelprozessoren.
>
> So? Von welchen denn? Ich befuerchte fast, mehr als den FDIV-Bug
> kannst Du nicht nennen.
>
> > Ändert aber alles nichts daran, dass es einfach aus Dummheit
> > vergessen wurde, einen solchen Fall zu berücksichtigen.
>
>
> Ich wette, Du hast noch nie ein komplexeres digitales System
> entworfen? Hast Du eigentlich nur die geringste Ahnung, welche
> Eventualitaeten es bei einem derart komplexen System wie einer
> modernen CPU zu beruecksichtigen gilt. Es ist praktisch unmoeglich
> hier fehlerfrei zu arbeiten. Intel dokumentiert ihre Bugs seit dem
> FDIV-Disaster wenigstens oder zieht CPUs zurueck, wenn die Fehler
> wirklich gravierend sind (etwa beim PIII-1133).
>
> > Da das ganze Problem scheinbar in der Kommunikation mit dem Chipsatz
> > liegt,
> > ist es schlicht und einfach ein Designfehler beim Hyperthreading
> > bzw. beim PowerManagement.
>