Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
NewsMarvell stellt nativen PCIe/NAND-Controller für SSDs vor
Solid State Drives gewinnen auch im Unternehmensbereich zunehmend an Bedeutung, zum Beispiel für Datenbank- und Cloud-Anwendungen. Doch während im Desktop-Bereich die Leistung aktueller High-End-SSDs in der Regel gar nicht ganz benötigt wird, lechzen Server bei gewissen Anwendungen geradezu nach mehr IOPS.
Na endlich!
Habe ein OCZ RevoDrive2 x2 als Tempdrive (neben 2x Corsair Force3 @ RAID0 als Systemdrive), aber das ist im Endeffekt doch nur ein SATA FakeRAID mit kleinen SATA SSDs was so in den PCIe Slot gesteckt wird. Total unnötig, das SATA Protokoll dazwischenzuschalten.
Der hier gezeigt Ansatz ist der richtige Weg für Geschwindigkeiten und Skalierbarkeit Abseits des SATA/SAS Standards.
Ist der große Chip auf dem Haupt-PCB direkt neben dem PCIe Stecker etwa der PCIe Switch? So wie ich das verstanden habe, benötigen diese kleinen "SSDs" nur noch einen Switch um gemeinsam direkt ans PCIe Interface gehängt zu werden?
Das Teil ist über nur eine PCIe Rev.2 Lane angebunden, damit kommt man dann nach Abzug des Overhead dürfte da so maximal 450MB/s möglich sein, zumal auch nur ein 4 Kanal Flash Controller verbaut ist und die NANDs dann auch nur 133MB/s schaffen müssen, was ja heute eigentlich Standard ist. Wenn die dann bei 8 Controllern auf einer Karte halbwegs skalieren, so müssten 3.2GB/s seq. lesend erreichbar sein. Ist jedenfalls ein sehr interessantes Produkt und vom einzelnen Modul welche fest auf dem Mainboard z.B. eines Notebooks steckt bis zur Overkilll PCIe SSD skalierbar zu sein öffnet ja auch einen gewaltigen Markt. Nachdem Marvell ja bisher nur einen einzigen SSD Controller gebracht hat ist es jedenfalls gut zu wissen, dass die Firma da am Ball bleibt.
Erstaunlich ist aber, dass gerade OCZ der erster Kunde für den neuen Controller ist. Bisher hatte OCZ doch auf Sandforce gesetzt und dann Indilinx gekauft um einen eigenen Controller im Hause machen zu können, den sie mit dem Everest ja auch schon vorgestellt haben. Nun bandeln sie mit Marvell an. Das kann nur darauf hindeuten, dass sie entweder mit Sandforce nicht mehr so eng zusammenarbeiten, denn die Rolle des Entwicklungspartners hat ja nun wohl Intel übernommen und andererseits ihren eigenen Everest nicht die IOPS beibringen könne, die im Unternehmensumfeld nötig sind, da hat der Indilinx ja immer noch gewaltigen Aufholbedarf.
Zumindest bin ich mal gespannt, was da an Produkten kommen wird und wie schnell Microsoft dann auch TRIM für solche SSDs ermöglichen wird. Bisher werden TRIM Kommandos ja nicht an RAID oder SAS Controller geschickt. Bei SAS ist das zwar halbwegs verständlich, da TRIM ein SATA Kommando ist und SCSI dafür das Unmap Kommando hat. Aber da das S-ATA Tunneling Protocol (STP) ein Teil des SAS Standarts ist und es erlaubt an jedem SAS Controller auch SATA SSDs zu betrieben, müsste Windows diesen eigentlich auch TRIM Kommandos schicken, wenn eine solche SATA SSDs am SAS Controller hängt.
Ergänzung ()
And.! schrieb:
Ist der große Chip auf dem Haupt-PCB direkt neben dem PCIe Stecker etwa der PCIe Switch?
Ja, denn man kann nicht einfach so viele Controller an den PCIe Bus hängen wie man Lanes hat. Überlicherweise werden diese als x1, x4, x8 und x16 genutzt, wobei der eben auch ein Limit an Controllern gibt, die vorhanden sein dürfen. So erlauben die gebräculichen Chipsätze mit 16 PCIe Lanes für die Graka eben oft entweder nur 1x16 oder maximal 2x8, aber eben nicht 1x8 und 8x1, das geht nicht. Der Switch fasst dann eben diese 8x1 zu 1x8 für den Chipssatz auf dem Board zusammen, dass damit nur einen Controller ansprechen muss.
Man sieht das ja auch z.B. hier über die neuen Atom:
Die können sohar 4 x2 aber eben nicht 8 x1, denn bei 4 Controllern ist offenbar Schluss und auch Kombinationen wie 1 x4, 1 x2 und 2 x1 gehen eben einfach nicht, es geht immer nur, was der Hersteller vorgesehen hat oder man nimmt einen Switch oder Multiplexer.
Sie dürften aber gegebenenfalls eher ein Nischendasein fristen, denn der Marvell 88NV9145 ist ein nativer PCIe-NAND-Controller für den Einsatz in PCIe-SSDs und wäre nur mit Zusatzchips in SATA- beziehungsweise SAS-Laufwerken einsetzbar.
Warum wird im Artikel behauptet, dass das Teil für Desktopanwendungen nur mit SAS oder SATA-Controller nutzbar wäre? Falls sich das auf den Endverbraucher bezieht, der kann auch PCIe für Laufwerke benutzen. Haben hier ja auch schon ein paar Leute genannt.
@Holt
Soweit ich das verstanden habe liegt hier der Fokus auf IOPS und nicht auf dem (sequentiellen) Datendurchsatz.
Warum wird im Artikel behauptet, dass das Teil für Desktopanwendungen nur mit SAS oder SATA-Controller nutzbar wäre? Falls sich das auf den Endverbraucher bezieht, der kann auch PCIe für Laufwerke benutzen. Haben hier ja auch schon ein paar Leute genannt.
Da der nächste SATA Standard sowieso auf PCIe aufsetzen wird, wäre es einmal denkbar, dass Marvell dies dann auch in die FW integriert und das damit gewissermassen nachträglich zur ersten SATA 4 SSD wird oder sich der Standard nicht mehr durchsetzen wird und man künftig SSDs einfach am direkt an PCIe Lanes betreibt. Das SATA Protokoll ist ja nie für SSDs entwickelt worden und etwas komplett neues was den alten Ballast aus HDD Zeiten wo noch über Köpfe, Zylinder und Sektoren adressiert wurde und auf Geräte mit nur 1.5Gb/s Rücksicht genommen werden muss, abwirft wäre dann auch nicht ganz falsch.
fandre schrieb:
Soweit ich das verstanden habe liegt hier der Fokus auf IOPS und nicht auf dem (sequentiellen) Datendurchsatz.
Das stimmt, aber die seq. Transferraten sollten bei entsprechender Datenverteilung auch ebenso skalieren, denn wenn nicht wäre das zumindest für Heimanwender total uninteressant, da einzelne 4k Zugriffe auch nicht (viel) schneller werden dürften (die wird man wohl kaum über die Controller verteilen) und schon die IOPS eines Controller alle bisherigen SATA SSDs übertreffen und kaum ein Heimanwender deren IOPS wirklich ausnuzen kann. Da sollte dann also schon auch mehr seq. Transferraten drin sein, damit man auch einen Vorteil spürt, denn billig werden die Teile sicher nicht sein. Aber ein Board mit 4 Controllern zu je 32 bis 128GB könnte unter den Enthusiasten schon seine Abnehmer finden. Das wäre jedenfalls sinnvoller als die Revos die man jetzt kaufen kann.
@Holt
Vielleicht konnte OCZ mit dem teilweise schlechten Ruf des Sandforce in der Geschäftswelt keinen Fuß fassen und versucht jetzt ganz opportunistisch einen angesehenen Controller-Hersteller im eigenen Produkt zu verwursten.
Nach der Gleichung "OCZ + Marvell = schlechter Ruf + guter Ruf > 2 x schlechter Ruf = OCZ + Sandforce"
Oder sie sehen ein, dass die Sandforce-Controller nicht gut oder verlässlich genug sind, um im Enterprise-Umfeld ernstgenommen zu werden?
Interessantes Produkt jedenfalls. Wobei ich natürlich skeptisch bin, was die Performancezuwächse in der Praxis und weitere Hasenfüße (Holt hat ja schon Limitierungen genannt) angeht...
Bei den Ausfallsraten aktueller SSDs haben diese noch nichts in Business Rechnern verloren, geschweige denn in einem Server. Wenn dann sogar einfach nur ein Controller mit Flash direkt an den PCIe Bus gehängt wird ohne RAID Controller, dann ist das noch sehr viel unverantwortlicher. Für mehr als ein paar temporäre Dateien für manche wissenschaftliche Simulationen taugt das Ding nicht.
Merlin-,- lauft Anandtech habendie das Teil sogar zusammen entwickelt, werden aber wohl die Controller mit jeweils eigenem Logo bringen. Dann wäre der Imagetransfer von Marvell zu PCZ sicher geringer.
Es könnte halt auch sein, wie Anandtech es im Test der Octane 128GB vermutet: Intel arbeitet jetzt massiv daran dem Sandforce endlich stabil zu machen um ihn in der 520er Reihe zu verbauen und wird diese Arbeit dann nicht mit den anderen SF-Kunden teilen wollen. Dann könnten sie ja keine Premiumpreise durchsetzen um die gewohnt ambitionierten Margen zu erwirtschaften. Kommt dann wirklich eine Intel mit Sandfoce und läuft dann plötzlich stabil, problemlos und womöglich noch schneller (ich vermute Intel wird dem SF endlich ein externe Cache RAM spendieren, davon profitiert die Performance sicher und die anderen Anbieter können dann nicht einfach die FW nachrüsten), wird es für die anderen Anbieter schwerer sich zu behaupten.
OCZ versucht dem eben nach zwei Seiten zu entkommen, einmal die eigenen Indilinx im Consumerbereich und jetzt wohl mit Marvell im Enterprisebereich.
Wie funktioniert denn die Datenverteilung auf die einzelnen Module?
Vor den einzelnen Controllern hängt ja nur ein simpler PCIe-Switch und kein Controller, der für so etwas zuständig sein könnte.
Dass nur 4 Kanäle pro Controller genutzt werden finde ich jetzt nicht so verwunderlich. Mit dem jetzigen NAND-Interface mit 133 MB/s hat man mit 4 Kanälen die PCIe-Lane schon voll ausgelastet.
Ähm... man korrigiere mich, wenn ich falsch liege, aber der Satz ist doch totaler Blödsinn, oder?
Dieser Chip benutzt PCIe als Anbindung und steuert dann direkt den NAND an.
Gewöhnliche Controller sind SAS/SATA auf NAND.
Bisherige PCIe-Lösungen setzen oft auf PCIe->SATA/SAS auf der PCIe-Karte=>NAND
Wie funktioniert denn die Datenverteilung auf die einzelnen Module?
Vor den einzelnen Controllern hängt ja nur ein simpler PCIe-Switch und kein Controller, der für so etwas zuständig sein könnte.
Das wird wohl vom Treibe geregelt und da der Controller keinem Standard folgt, dürfte zumindest vorerst die gane Lösung mit der Softwareunterstüzung stehen oder fallen.
HighTech-Freak schrieb:
Ähm... man korrigiere mich, wenn ich falsch liege, aber der Satz ist doch totaler Blödsinn, oder?
Dieser Chip benutzt PCIe als Anbindung und steuert dann direkt den NAND an.
Gewöhnliche Controller sind SAS/SATA auf NAND.
Bisherige PCIe-Lösungen setzen oft auf PCIe->SATA/SAS auf der PCIe-Karte=>NAND
S.o. man braucht eine Software die mit den Controllern kommuniziert um das ganze nutzen zu können. Aber die künftige „SATA Express“ wird ja physikalsich auch auf PCIe aufsetzen und damit ist es nicht auszuschliessen, dass man dann irgendwann durchaus zu einem Standard kommt, der auch von dem Controller unterstützt wird, immerhin sitzt Marvell bei der Standartierungsorganisation für SATA ja mit am Tisch. Die Skalierbarkeit der PCIe Lanes auf den kommenden SATA Standart auszudehnen ist doch nur ein kleiner und sehr logischer Schritt. Zumal man durch die Zusammenfassung mehrer Lanes (dem Feature was gerade die Attraktivität und Skalierbarkeit von PCIe ausmacht) den gleichen Standard einerseits lange beibehalten und andererseits an die sich ständig und schell erhöhenden Performanceanforderungen anpassen kann.
Sind Protokoll und Treiber erst einmal etabliert, wozu braucht man dann noch ein SAS/SATA Protokoll?
@Holt: Danke für die Erklärung! SATA-Express kannte ich auch noch nicht...
Trotzdem habe ich es noch nicht ganz gerafft (k.A., vlt. steh ich auf der Leitung):
Ein nativer PCIe->NAND Controller(/Laufwerk) kommuniziert mit dem Host direkt über PCIe. Der SATA und SAS-"Umweg" werden defacto umgangen und der overhead eliminiert. Entsprechende Treiber sind natürlich notwendig. Wie sollte ich einen solchen Controller, dessen Host-Schnittstelle PCIe ist in ein SAS/SATA-Laufwerk integrieren, das als Hostschnittstelle nur SAS/SATA hat?
Wenn ich ein Laufwerk haben will, dass ich sowohl über SAS/SATA anbinden kann als auch über PCIe, dann brauche ich einen entsprechenden PCIe-NAND-Controller, der sich auch als SAS/SATA-"Client" ansprechen lässt. Das mit diesem Controller zu bewerkstelligen würde bedeuten, dass man ihn parallel zu dem SAS/SATA-"client" betreiben würde und beide direkt auf den NAND zugreifen können müssten, was ich mir etwas komplex in der Entwicklung vorstellen würde... (d.h. um genau zu sein: die totale Frickellösung)
BTW: funktioniert PCIe-Hotplug eigentlich? Auch unter Windows? Theoretisch sollte es das ja, aber praktisch siehts da ja oft gaaanz anders aus... -.-'
Das wird wohl vom Treibe geregelt und da der Controller keinem Standard folgt, dürfte zumindest vorerst die gane Lösung mit der Softwareunterstüzung stehen oder fallen.
S.o. man braucht eine Software die mit den Controllern kommuniziert um das ganze nutzen zu können.
Sind Protokoll und Treiber erst einmal etabliert, wozu braucht man dann noch ein SAS/SATA Protokoll?
