nForce Next

[Demirug]

Ob dieser neue Chipsatz wirklich "nForce-Next" heisen wird kann ich natürlich nicht sagen. Es ist auch eigentlich kein Chipsatz sondern eine ganze Chipsatzfamile.

Kern eines jeden Chips ist ein Switch an den alle Geräte mit einer Punkt zu Punkt Verbindung angeschlossen sind. Soweit noch nichts besonderes. Der Gag kommt jetzt. Es ist ein IP-Switch mit DHCP-Server und "Quality Of Service". Dadurch können sich die einzelnen Geräte ohne die CPU unter Verwendung des IP-Protocols miteinader unterhalten. So kann der Harddisk-Controller direkt zur VPU (Video Processing Unit) streamen und diese streamt dann nach dem dekodieren zur GPU weiter. Soweit so gut aber das Spiel geht noch weiter.

Sobald an dem Switch selbst wieder ein Gerät hängt das Zugang zu einem externen IP-Netzwerk hat kann man auch über die Systemgrenze hinweg streamen. Also zum Beispiel den Sound direkt zur Steroanlage. Auch die geziehlte Remoteaktivierung einzelner Geräte ist möglich solange die Zugangspunkt laufen. Man kann also von der Set-Top Box (natürlich mit nForce Next Chipsatz) im Wohnzimmer die Festplatte (und nur die Festplatte und den IP-Switch) im PC einschalten um einen Film von dieser zu holen.

Für lokale CPU-Geräte Verbindungen gibt es noch zusätzlich einen Highspeed Kanal bei dem sich beide eine Speicherbereich teilen und darüber daten austauschen können.

Als zusätzliches Feature haben die Chipsätze noch eine Option um mehrer virtuelle Systeme zu verwalten. Jedem dieser Systeme kann man Geräte zuordnen (auch entfernte) und auf jedem ein beliebiges OS laufen lassen. Über das jederzeit zugängliche Chipsatz-OS kann man dann zwischen den Systemen schnell umschalten.

PS: Ich habe mir das nicht aus den Fingern gesaugt das ist eine Idee die so wirklich von nVidia kommt.

[reunion]

Zitat:

Original geschrieben von Demirug
Ob dieser neue Chipsatz wirklich "nForce-Next" heisen wird kann ich natürlich nicht sagen. Es ist auch eigentlich kein Chipsatz sondern eine ganze Chipsatzfamile.

Kern eines jeden Chips ist ein Switch an den alle Geräte mit einer Punkt zu Punkt Verbindung angeschlossen sind. Soweit noch nichts besonderes. Der Gag kommt jetzt. Es ist ein IP-Switch mit DHCP-Server und "Quality Of Service". Dadurch können sich die einzelnen Geräte ohne die CPU unter Verwendung des IP-Protocols miteinader unterhalten. So kann der Harddisk-Controller direkt zur VPU (Video Processing Unit) streamen und diese streamt dann nach dem dekodieren zur GPU weiter. Soweit so gut aber das Spiel geht noch weiter.

Sobald an dem Switch selbst wieder ein Gerät hängt das Zugang zu einem externen IP-Netzwerk hat kann man auch über die Systemgrenze hinweg streamen. Also zum Beispiel den Sound direkt zur Steroanlage. Auch die geziehlte Remoteaktivierung einzelner Geräte ist möglich solange die Zugangspunkt laufen. Man kann also von der Set-Top Box (natürlich mit nForce Next Chipsatz) im Wohnzimmer die Festplatte (und nur die Festplatte und den IP-Switch) im PC einschalten um einen Film von dieser zu holen.

Für lokale CPU-Geräte Verbindungen gibt es noch zusätzlich einen Highspeed Kanal bei dem sich beide eine Speicherbereich teilen und darüber daten austauschen können.

Als zusätzliches Feature haben die Chipsätze noch eine Option um mehrer virtuelle Systeme zu verwalten. Jedem dieser Systeme kann man Geräte zuordnen (auch entfernte) und auf jedem ein beliebiges OS laufen lassen. Über das jederzeit zugängliche Chipsatz-OS kann man dann zwischen den Systemen schnell umschalten.

PS: Ich habe mir das nicht aus den Fingern gesaugt das ist eine Idee die so wirklich von nVidia kommt.

Soll diese option schon im nächsten Nforce-Chipsatz enthalten sein oder ist das nur eine Idee???

Und was für Vorteile würde das eigendlich bringen außer einer vermutlich höheren Geschw.???

Total Connectivity im Total-Media-Home-Network bei maximiertem Ease-of-Use und environment friendly power-saving and noise prevention features.

Genug Anglizismen?

Q

[Demirug]

Zitat:

Original geschrieben von Gast
Total Connectivity im Total-Media-Home-Network bei maximiertem Ease-of-Use und environment friendly power-saving and noise prevention features.

Genug Anglizismen?

Q

Warst du bei Huang und Vivoli zum Kaffe drinken?

[Demirug]

Was ich noch vergessen habe. Es gibt da eine Liste mit möglichen Geräten (PU = Processing Unit) die man anschliessen könnte. Darunter gibt es auch eine PPU. Dabei soll es es sich um eine Physik Processing Unit handeln. Diese soll Physikalische Berechnungen beschleunigen.

[Winter[Raven]]

wow ... klingt ja schon nicht schlecht. Die Frage ist und bleibt wie es dann umgesetzt wird. Aber um die Wahrheit zu sagen, trau ich NV alles zu.

Ahso, und mir soll einer Erzählen NVidia sei nicht Innovative.

[ethrandil]

Ehrm, seh ich das Richtig, dass dann erstmal "tcpip-kodierer" vor die IDE-Geräte geschaltet werden müssen, und nach und nach die Geräte nativ tcpip unterstützen werden?
Wär ja mal was um das immernoch recht statische Modell der "Karten" abzulösen
Auch für verteiltes Rechnen nicht übel.

Allerdings müsste das 'Bios' verglichen mit heutigen wesentlich flexibler sein, z.B. Treiber unterstützen. Oder wird das das Betriebssystem irgendwie übernehmen? ... hmmm hmm ...

recht interessant

Allerdings wird der Overhead auf den Datenleitungen steigen...

[Bokill]

Hängen diese Überlegungen nicht "zufällig" mit dem Hypertransportlink zusammen?

Jedenfalls klingt dieser Text fast so wie eine Produktbeschreibung eines weiteren HTr- Link tauglichen Chips.

Hypertransport ist ja schon derzeit über die Hammerplattform hinaus in anderen Bereichen vertreten.

NVIDIA, MIPS, Transmeta, SUN, Cisco, PMC- Sierra, Broadcom Corp., SGI und Apple waren ja schon die weiteren Gründungsmitglieder des Hypertransportkonsortiums.

[Quasar]

Zitat:

Original geschrieben von Demirug
Warst du bei Huang und Vivoli zum Kaffe drinken?

Nicht direkt, nur auf den letzten beiden CeBit-PKs und da dreht sich das meiste schon um das digital vernetzte Heim. War nur halt nie so berichtsträchtig, wie die neuesten Geforce-Spekulationen.

[mrdigital]

klingt spannend, aber ich weiss nicht, ob sich der aufwand lohnt, jedem Teil IP beizubringen, denn dass was die da beschreiben kann man auch anderst lösen, nur mit weniger Fehlerquellen Wenn jeder meiner Chips / Komponenten / was auch immer IP spricht, dann will ich nicht Firmwareprogrammierer sein. Zumal das IP Protokoll nicht unbedingt für niedrige Latenzzeiten spricht. Ich bin da ein wenig skeptisch, aber die Idee klingt interessant. Hast du mehr Details zu dieser Technik, Demirug?

[Bokill]

Das Hypertransportprotokoll ist Paketbasiert, jeder Chip hat lediglich eine Punkt zu Punkt Verbindung...

weswegen sollte da jede Komponente da eigene IP- Adressen haben?

Vermutlich wandelt dort ein "Netzwerkchip" das IP- Datenpaket in ein Datenpaket für HTr um.

Das HTr- System ermöglicht gleichsam das Zusammenstückeln wie ein legospiel.

[Crushinator]

Zitat:

Original geschrieben von Demirug
(...) Sobald an dem Switch selbst wieder ein Gerät hängt das Zugang zu einem externen IP-Netzwerk hat kann man auch über die Systemgrenze hinweg streamen. Also zum Beispiel den Sound direkt zur Steroanlage. Auch die geziehlte Remoteaktivierung einzelner Geräte ist möglich solange die Zugangspunkt laufen. Man kann also von der Set-Top Box (natürlich mit nForce Next Chipsatz) im Wohnzimmer die Festplatte (und nur die Festplatte und den IP-Switch) im PC einschalten um einen Film von dieser zu holen. (...)

Oh' toll, Du hast so eben IP-Streaming erfunden. Schade nur, daß man es mit entsprechender Software, Settop-Boxen mit Ethernet (sogar mit lange verfügbaren in Nordamerika gut verbreiteten ATI-Chipsätzen) oder notfalls Bridges, die aus fast allem Ethernet-Frames und IP-Pakete machen bereits heute haben kann. Der Rest hört sich ja nach ganz normalem P-t-P Switching innerhalb eines Chipsatzes an - was auf Hypertransport/Infiniband/V-Link und die sonstigen verfügbaren (propritären) Techniken schließen läßt - was um eine IMHO sinnlose (weil aufwendige) Protokollschicht in Form von IP ergänzt wurde.

Zitat:

PS: Ich habe mir das nicht aus den Fingern gesaugt das ist eine Idee die so wirklich von nVidia kommt.

Die Idee verfolgt auch eine andere - sich vom Purpurtentakel angesteckte - Firma, nämlich Microsoft und ist damit ziemlich weit gekommen, nämlich gar nicht. Allerdings würde ich nur zu gerne sehen, wie man 5+1 oder mehr Roh-Audio-Kanäle mit dem selben "IP-Switch" zur Stereoanlage transportiert, über den auch der sonstige externe IP-Verkehr wie z.B. in Form eines 3,7 MBit/s Videostreams läuft.

Diese PPU klingt interessant, allerdings sehe ich nicht so richtig eine Zielgruppe dafuer. Anyone else?

[Ailuros]

Zitat:

Ahso, und mir soll einer Erzählen NVidia sei nicht Innovative.

Ich koennte Dir viele interessante Geschichten ueber's nForce Team erzaehlen und welche Talente es genau durch die Jahre aufgesaugt hat

[zeckensack]

Zitat:

Original geschrieben von Demirug
Kern eines jeden Chips ist ein Switch an den alle Geräte mit einer Punkt zu Punkt Verbindung angeschlossen sind. Soweit noch nichts besonderes. Der Gag kommt jetzt. Es ist ein IP-Switch mit DHCP-Server und "Quality Of Service". Dadurch können sich die einzelnen Geräte ohne die CPU unter Verwendung des IP-Protocols miteinader unterhalten. So kann der Harddisk-Controller direkt zur VPU (Video Processing Unit) streamen und diese streamt dann nach dem dekodieren zur GPU weiter.

Braucht man dafür nicht ein vernünftiges OS? *hust* pipes *hust*

Oder kriegt Windows das auch irgendwie hin?

[Ailuros]

Es duerfte kein Zufall sein dass es (voruebergehend?) "Next" heisst.

[Demirug]

Zitat:

Original geschrieben von zeckensack
Braucht man dafür nicht ein vernünftiges OS? *hust* pipes *hust*

Oder kriegt Windows das auch irgendwie hin?

Windows hätte damit genauso Probleme oder eben keine wie jedes andere OS.

Im Prinzip würde ja nur alle Geräte (oder PUs wie nVidia das nennt) erst einmal als Hot-Plug fähig deklariert. Treiber wie bisher bräuchte man ja nicht mehr weil die Geräte dann ja genormte höhere Protokolle auf IP Basis beherschen müssten. Ich sehe das Problem eher auf der Seite der Anwendungsprogramme. Mach einmal deinem Player verständlich das er zwischen den Beteiligten Geräten die Streamverbindungen aufbauen soll und dann über ein Kommando an die Festplatte den Wiedergabe startet. Software die damit umgehen kann gibt es einfach noch nicht.

Da man sich bei nVidia ja aber nicht sein eigenes Grab schaufeln möchte (wegen inkompatibilitäten) gibt es da eine Interopschnittstelle in zwei Richtungen.

Zum einen kann man bei der Definition der virtuellen Systeme die PUs als "Clasic" Hardware auf die bekannten Resourcen (IO-Port, Memory-Mapped RAM, Interrupts) mappen. (geht wohl mit Plug and Play fast von aleine so wie ein Sendersuchlauf beim Fernseher) Der Chipssatz übernimmt dann das übersetzten zwischen den Clasic-Zugriffen und den IP-Protokollen. Auf der anderen Seite können PUs auch von der CPU zur Verfügung werden. In diesem Fall würden die IP-Packte zur CPU gehen und dort dekodiert werden. Dann könnte die CPU auf ein "altes" Gerät direkt zugreifen.

[zeckensack]

Zitat:

Original geschrieben von Demirug
Windows hätte damit genauso Probleme oder eben keine wie jedes andere OS.

Im Prinzip würde ja nur alle Geräte (oder PUs wie nVidia das nennt) erst einmal als Hot-Plug fähig deklariert. Treiber wie bisher bräuchte man ja nicht mehr weil die Geräte dann ja genormte höhere Protokolle auf IP Basis beherschen müssten. Ich sehe das Problem eher auf der Seite der Anwendungsprogramme. Mach einmal deinem Player verständlich das er zwischen den Beteiligten Geräten die Streamverbindungen aufbauen soll und dann über ein Kommando an die Festplatte den Wiedergabe startet. Software die damit umgehen kann gibt es einfach noch nicht.

Das ist klar. Ich spielte darauf an, daß auch der Kernel (bzw die API zum Kernel) das ganze unterstützen können muß, bevor man überhaupt Software darauf aufsetzen kann.

Und da hat Windows traditionell eben riesige Probleme. Man denke hier an ganz banale Dinge wie USB-"Support". Bei Unix schreibt man einfach ein Modul, das das ganze nach /dev/usb mappt und kann loslegen, zumindest die Lauffähigkeit ist erreicht. Hot Plug ist eine separate Angelegenheit, aber auch schon lange gelöst. Die ganze Grundarchitektur ist einfach viel flexibler, eben weil Unix ... Unix ist ("alles verhält sich wie eine Datei").

"named pipes" gibt's auf zB Linux schon seit Ewigkeiten, und diese bieten tatsächlich die nötige Semantik für Routing-Aufgaben. Man kann einen Daemon schreiben, der Traffic auf bestimmten pipe-Namen abhört und dann die Dinge ins Rollen bringt. Das gleiche Nutzungsmodell ist auch für 'alte' Hardware einsetzbar. Man braucht den Kernel nichtmal anzufassen ...

[Demirug]

Zitat:

Original geschrieben von zeckensack
Das ist klar. Ich spielte darauf an, daß auch der Kernel (bzw die API zum Kernel) das ganze unterstützen können muß, bevor man überhaupt Software darauf aufsetzen kann.

Und da hat Windows traditionell eben riesige Probleme. Man denke hier an ganz banale Dinge wie USB-"Support". Bei Unix schreibt man einfach ein Modul, das das ganze nach /dev/usb mappt und kann loslegen, zumindest die Lauffähigkeit ist erreicht. Hot Plug ist eine separate Angelegenheit, aber auch schon lange gelöst. Die ganze Grundarchitektur ist einfach viel flexibler, eben weil Unix ... Unix ist ("alles verhält sich wie eine Datei").

Wenn es nur um Lauffähigkeit geht kannst du das bei Windows genauso machen. Ich habe hier einen Treiber für ein USB-Gerät für Windows NT 4.0. Das Treibermodel von NT verhält sich genauso. Alles ist eine Datei.

Zitat:

"named pipes" gibt's auf zB Linux schon seit Ewigkeiten, und diese bieten tatsächlich die nötige Semantik für Routing-Aufgaben. Man kann einen Daemon schreiben, der Traffic auf bestimmten pipe-Namen abhört und dann die Dinge ins Rollen bringt. Das gleiche Nutzungsmodell ist auch für 'alte' Hardware einsetzbar. Man braucht den Kernel nichtmal anzufassen ...

Bei NT sind die auch schon immer drin. Neben einer ganzen Reihe von zusätzlichen Interprozess Kommunikations Verfahren.

Beim dritten OS-Kernel in Folge sollte jemand auch wissen wie man es macht.

[Crushinator]

Zitat:

Original geschrieben von Demirug
Wenn es nur um Lauffähigkeit geht kannst du das bei Windows genauso machen. Ich habe hier einen Treiber für ein USB-Gerät für Windows NT 4.0. Das Treibermodel von NT verhält sich genauso. Alles ist eine Datei.

Es ist aber immernoch kein Vergleich, da Dein USB-Gerät nur durch explizit an diesen Treiber "gelinkte" Software angesprochen werden kann. Ich wüßte nicht, daß man den NT-Kernel durch einen Treiber um eine allgemeine Geräteklasse für systemweiten Zugriff erweitern könnte, was dagegen durch mappen von "/dev/usb" unter den Unices eben möglich ist.