News Intel zeigt erste NVMe-SSDs für Verbraucher

in Summe: ich hätte dann zwei schicke flotte SSDs

Koppelung: dabei geht es mir darum, daß ja immer wieder "beworben" wird, daß mittlerweile ja alles eigentlich an den PCI-Express-Standard runtergebrochen wird (TB, USB3.x, SataExpress <<-- da steckt es ja schon im Namen) ...

und 16 vs. 10 Gbit/s: hier scheitert es ja derzeit nur daran, daß SataExpress auf den MBs als Verbund zweier Sata3 / 6Gbit/s Anschlüsse plus dem dritten mickrigen iwas-Anschluß daher kommt. und damit Ihnen wohl die Daten nicht abhanden kommen, bremsen sie sich von 2x6 auf in Summe 10Gbit/s runter. sowas nenne ich Resteverwertung / Abwärtskompatibilität.

abschließend an die Hersteller: so, nun mal Butter bei die Fische! wo bleiben die flotten SSDs? hab mir schließlich nicht umsonst ein sauteures MB mit allem Pipapo gekauft, nur um die Anschlüsse verwaist zu sehen. der Chipsatz und alles andere Langweilen sich, da hängen ein DVD-Brenner und ne Sata3 SSd dran. und ein weiterer wird von ner Sata2 HDD veralbert!
 
@up.link: Lass mich raten, Du besitzt ein X99-Board? Willkommen im Club. Ich würde auch gerne was in den M.2-Slot stecken und dann die Daten per PCIe-3.0-x4 übertragen... dauert halt noch ein paar Monate.
 
up.link schrieb:
und 16 vs. 10 Gbit/s: hier scheitert es ja derzeit nur daran, daß SataExpress auf den MBs als Verbund zweier Sata3 / 6Gbit/s Anschlüsse plus dem dritten mickrigen iwas-Anschluß daher kommt. und damit Ihnen wohl die Daten nicht abhanden kommen, bremsen sie sich von 2x6 auf in Summe 10Gbit/s runter.
Nein, total daneben weil kleider keine Ahnung, denn die 10Gb/b haben mit den beiden SATA Ports nicht zu tun, die kommen von den beiden PCIe 2.0 Lanes, die die bisherigen SATA Express Ports bieten, 16Gb/s wären es wenn es zwei PCIe 3.0 Lanes wären, aber das dürfte erst mit Skylake kommen, da dort die PCIe Lanes des Chipsatzes dann auch PCIe 3.0 sein werden.

Zwei SATA Ports wären 12Gb/s, aber SATA erlaubt es nicht zwei Ports zusammenzufassen, weshalb auch SATA Express über SATA nur maximal 6Gb/ bietet, außer man würde zwei SSDs in einem Gehäuse verbauen um so beide Ports zu nutzen, aber dann würde man auch nur mit maximal so 550MB/s eine Datei übertragen können, außer die beiden wären also RAID 0 geschaltet, aber das allen kann man auch jetzt schon mit normalen SATA SSDs und -kabeln machen.

up.link schrieb:
abschließend an die Hersteller: so, nun mal Butter bei die Fische! wo bleiben die flotten SSDs?
Es würde mich nicht wundern, wenn es niemals SATA Express SSDs geben wird, oder allenfalls einige wenige Exoten ohne Bedeutung auf dem Markt. Da SATA Express eben nur maximal 2 PCIe Lanes bietet, was aber schon nicht einmal für eine M.2 SSDs wie dei Samsung SM951 reicht, die mit 2150MB/s lesend angegeben ist, wird der Trend klar PCIe 3.0 x4 und damit auf M.2, Slotkarten oder eben 2.5" mit SFF-8639, wie die Intel DC P3000er und die Samsung XS1715.

Für HDDs wird SATA noch eine Weile reichen, die lasten noch nicht einmal SATA 3Gb/s aus, geschweige denn SATA 6Gb/s.
up.link schrieb:
hab mir schließlich nicht umsonst ein sauteures MB mit allem Pipapo gekauft, nur um die Anschlüsse verwaist zu sehen.
Welches Board hast Du denn was für Anchlüsse möchtest Du dann nun ungehend nutzen? Die Intel um die es in dem Artikel zu diesem Thread geht, wird ja wohl die erste PCIe 3.0 x4 Consumer SSD sein, die Samsungs sind ja OEM bzw. Enterprise SSDs (genau wie die Intel DC P3000er). Noch etwas Geduld, im Laufe des Jahren wird diese Intel kommen und auch noch einige weitere Angebote, da bin ich mir sicher, passende Controller wurden ja schon vor einiger Zeit vorgestellt.
 
Holt schrieb:
Erstens habe ich keine Lust auf eine endlos Diskussion mir Dir zumal Du offenbar verstanden hast wie die Protokollebene mit den Layern funktionieren und zweitens fahren AMD und NVidia ein anderes Protokoll ganz oben, also nicht NVMe oder AHCI. Natürlich kann bei AHCI oder NVMe nicht jedes Pakt die vollen 4096 Byte lang sein, da Befehle und ACK ja viel kürzer sind, ohne die geht es aber nicht.
Wenn Du die Aussage von AMD und NVidia mal verlinken würdest, könnte man vielleicht bewerten, auf was sich die 3% wirklich beziehen, aber auch die kommen nicht um die übrigens Layer herum und addieren tun sich die Bits und Bytes, die jeder Layer für sein Protokoll als Header, Adresse, CRC, etc. einfügt, die Effizienz mulipliziert sich und liegt bei jedem Layer unter 1, weil kein Layer ohne zusätzliche Bit oder Bytes nur Nutzdaten überträgt. Nur 3% können da nicht für den ganzen Protokollstack sein.
Äusserst Merkwürdig. Da gibt es auch nichts zu diskutieren und weder NVMe noch AHCI haben etwas mit dem Overhead von PCIe3 zu tun. Ich bin Programmierer unter anderem, aber ich brauch keinen Protokollstack selbst programmieren. Wozu?

Man kann doch einfach mal zugeben sich geirrt zu haben. Wo ist denn dein Problem? Jeder der hier liest ist an den korrekten Fakten interessiert und dafür ist doch ein Forum da und nicht zur Selbstdarstellung. Befehle und ACk sind übrigens Teil des Overheads und nicht des Payloads. Aufbau von Protokoll-Layern sind eigentlich recht simple und nicht schwer zu begreifen.
 
Das Probolem ist, dass nicht ich mich irre sondern Du Dich irrst und offenbar wenig Ahnung von dem Programmieren mit solche Protokollen hast, sonst auch nicht die Frage was AHCI oder NVMe mit dem PCIe Protokoll zu tun haben! Kleiner Hinweis: Die laufen darüber! Wenn AHCI z.B. einen Befehl schickt, dann muss der die ganze Schichten durchlaufen, dass ignorierst Du ständig, man sollte es als Programmier aber schon wissen und das ISO-OSI 7 Schichten Modell kennen! Das ist zwar nicht 1:1 auf PCIe anwendbar, aber wie Du aus den anderen Links erkennen konntest, ist es auch dort (wie bei allen Kommunikationsprotokollen) recht ähnlich und das die Daten von der oberesten Schicht runter bis zur untersten Schicht müssen und dann auf der einen Seite wieder hoch bis zur obersten Schicht, sollte auch klar ein, deshalb kommt man eben nicht um die ganzen Overheads herum, die jede Schicht hinzufügt.
 
Holt schrieb:
Das Probolem ist, dass nicht ich mich irre sondern Du Dich irrst und offenbar wenig Ahnung von dem Programmieren mit solche Protokollen hast, sonst auch nicht die Frage was AHCI oder NVMe mit dem PCIe Protokoll zu tun haben! Kleiner Hinweis: Die laufen darüber!

Ja und? Die haben alle ihren eigenen Protokoll-Overhead. So nennt man das auch technisch korrekt. Das ist kein PCIe-Overhead. Dann schreib das doch einfach so wie es richtig ist. Denk mal über den Begriff "Layer" nach und welcher Layer zu welchem Protokoll gehört. Da GPUs kein AHCI oder NVMe nutzen, kann man das kaum als PCIe-Overhead bezeichnen.

Bei dir scheint das Problem der OSI-Layer 8 zu sein ;)
 
Zuletzt bearbeitet:
Von PCIe Overhead habe ich auch nichts geschrieben, mit dem Mist kommst nur Du jetzt hier an um zu trollen. Ich habe vom Overhead der höheren Protokollayer geschrieben, die Bitkodierung ist ja der unterste Layer und dort eben wegen 8b10b bei PCIe <= 2.0 bzw. 128b130b Kodierung bei PCIe 3.0 sehr unterschiedlichen, aber der Overhead der Layer darüber ist für alle PCIe Versionen gleich, weshalb es sich lohnt den getrennt zu betrachten.
 
Entschuldigung?

Holt schrieb:
Von PCIe Overhead habe ich auch nichts geschrieben, mit dem Mist kommst nur Du jetzt hier an um zu trollen.

Daedal schrieb:
Holt schrieb:
das ist dann auch das Limit für PCIe 3.0 x4, weil die höheren Protokolllayer bei PCIe leider recht viel Overhead produzieren, so 20 bis 25% sind da normal, zusätzlich zum Overhead duch die Bitkodierung der bei PCIe 3.0 ja dank 128b130b Kodierung gering ist.
Welche speziellen Layer meinst du damit? Hast du dazu Details?
 
Zurück
Oben