News Intel Thunderbolt Share: Praktische Teilen-Funktion setzt keinen neuen Chip voraus
Ich meine nur die PCIe Anbindung war da limitiert, weil der CPU die Lanes ausgegangen sind damals. Aber der Controller war doch immer noch ein Dual Port Controller (also der Vollausbau. Nur mit nur der halben PCIe Geschwindigkeit angebunden. Die wäre dann auch nicht 20 GBit/s sondern 16 GBit/s inklusive dem großen Overhead). Displayport sollte an diesen Ports weiterhin uneingeschränkt gehen, genau wie TB3 40G Verbindungen.Trelor schrieb:
---
Die richtig spannende Frage mit dem TB Share ist eigentlich die Umsetzung. Nutzen die einfach nur die virtuelle LAN-Verbindung die es die ganze Zeit schon gab und für die man auch kein TB braucht, sondern die man auch mit Linux und USB4 allgemein hat?
Oder setzen sie eine Ebene unten drunter an? Denn die TB LAN Verbindung ist nur virtuell. Die wird schon immer auf TB Host2Host DMA Kommunikation umgesetzt. Das heißt theoretisch kann man das auch direkt verwenden um Daten mit niedrigeren, TB/USB4 bekannten Latenzen und ohne klassischen IP Overhead zu übertragen. Quasi direkt vom RAM des einen PCs in den des anderen. Aber selbst das ist meine ich ein reguläres USB4 Feature und wofür es eigentlich egal sein sollte von welchem Hersteller der USB4 Kontroller kommt.
Nur wenn sie es noch auf dem schon vorhandenen Netzwerk aufbauen ist es noch offensichtlicher, dass die Software eigentlich komplett Hersteller- und Schnittstellenabhängig sein kann und nur auf die niedrigere Latenz und höhere Bandbreite einer TB/USB4 Verbindung im Vergleich zu klassischen Netzwerkverbindungen ausgelegt sein kann.
Das man mehrere TB/USB4 Peripherien zwischen 2 Hosts haben kann, die virtuelle LAN Verbindung aber von Host zu Host geht gab es auch bisher schon. War nur teilweise etwas garstig ob die nun zu Stande kommt oder nicht. In jedem Fall diktiert welcher PC am upstream Port der Peripherie angeschlossen ist, welcher PC die Kontrolle über die TB Hierarchie und damit die Peripherien hat. Der andere Host kann nichts außer ein Client sein für die rDMA Verbindung.
Und so oder so gibt es da keine schwarze Magie mit der Bildschirmübertragung. Das ist vom Prinzip nichts grundsätzlich anderes als die vorhandenen Remotedesktop / Remotegaming Lösungen wie Steam Remote Play oder Parsec etc. Wie gesagt, alles eine Frage ob Intel hier mehr Performance herausholt, weil sie ganz speziell auf ihre Thunderbolt Chips optimieren können (wo sie die Latenzen und den Durchsatz kennen und TB/USB4 die Verbindungslatenz zwischen 2 Komponenten eh schon weiß. Dadurch das TB/USB4 die Bandbreiten explizit managed, weiß es genau wie viel Bandbreite garantiert ist und könnte so die Latenz evtl. niedriger halten (abgesehen davon, dass es eine direktere, Punk-zu-Punkt Verbindung ist). Klassische Netzwerkprotokolle sind auch wesentlich generischer und konservativer und müssen auch korrekt damit umgehen, dass andere Übertragungen überraschend Bandbreite verbrauchen (TCP) oder verlieren schlicht Teile der Daten falls die tatsächlich verfügbare Bandbreite plötzlich einbricht (UDP. Was dann entweder eine für den Nutzer spürbare Störung ist, oder von der Anwendung mit mehr Latenz durch erneute Übertragung kompensiert werden muss).
Renegade334
Lt. Commander
- Registriert
- Okt. 2016
- Beiträge
- 1.482
Das war auch mein erster Gedanke. Was ist jetzt das neue an dem Feature?JBG schrieb:
Sind da mehr als 20GBit/s möglich, oder gibt es keinen Overhead durch Netzwerkprotokolle? Ansonsten ist Thunderbolt Netzwerk, gerade mit Routingmöglichkeiten, flexibler.
10G - Das mag ja vielleicht einer der Gründe für dieses extra Tool sein ? Die 10G entstehen nach meinem Verständnis daraus das zwar die eigentlich deutlich schnellere 40..80G USB4/TB Hardware genutzt wird, aber der TCP/IP Netzwerkstack als schlecht parallelisierbare Software auf einem der "bis zu" 4GHz Cores des Prozessors läuft und dadurch alle Standard-Netzwerkverbindungen darüber auf "10G Niveau" (Intel Sprech in den alten TP3 Präsentationen) ausgebremst ist. **)Hancock schrieb:
Sprich das Tool könnte z.B. beim Dateitransfer dann die vollen 40..80G nutzen (oder eben die 32..64G die TB4/5 Zertifikate garantieren sollen) .. aber ebenso möglicherweise für einen "lebhaften" Remote Desktop (am Ende gar virtuelle DPout -> DPin Kanäle für den GPUs-Speicher?). Was dann mit dem Programmzugriff auf die SSDs im Nachbargerät ist wär die Frage - das bliebe sicher langsam wenn's weiter über den TCP/IP Stack läuft. Apps werden wohl genauso wie das OS für höhere Netzwerkgeschwindigkeit (neue Netzwerk-IF im OS) dazulernen müssen.
Aber nach und nach, wenn die Betriebssysteme selbst mal mit USB4 (aka TB4/5 und schnellere Nachfolger) umzugehen lernen und USB4 Networking dann das Ethernet-Kabel ersetzt, weil nach und nach auch bezahlbare beliebig lange optische USB4 Kabel den Markt erreichen, dürfte diese Lösung dann überflüssig werden.
Aber solange hat man schon mal einen durchaus nützlichen Vorgeschmack für Geräte die zufällig auf dem Schreibtisch dicht nebeneinanderstehen (kurze USB4 Kabel ..) auf die künftige
Netzwerktechnik. Selbst wenn man dann vielleicht aus Kostengründen erstmal preiswerte optischen USB4-20G Kabel als Netzwerkstrippen benutzt ..Das was ich mich noch frage ist - ob das wirklich auf 2 Computer begrenzt sein muß. An einen USB4-Hub, auch an solche die in Monitore integriert sind, mag man ja auch mal 3 oder 4 Computer anschließen können .. und eigentlich wenn man die kaskadiert *) vielleicht sogar mehr ? Wobei dann eigentlich irgendwelche möglichweise langsamen "Netzwerkbrücken" in Computern überflüssig sind da ja alle Computer miteinander P2P via USB4 kommunizieren könnten ?
*) Der USB4 Standard sagt zwar das USB4 Hubs USB-Networking aka Host2Host-Networking unterstützen müssen (!), so daß nicht nur direkte Computer-Computer sondern auch Computer-Hub-Computer Verbindungen, aber es gibt dort keine explizite Aussage das eine Computer-Hub-Hub-Computer Verbindung, also eine Kaskadierung von Hubs gehen muß .. ?
**) das der altehrwürdige TCP/IP Stack ne Geschwindigkeitsbremse für >~ 10G Netzwerk ist ist mir auch schon mal beim Schreiben von Anwendungen für Infiniband Karten begegnet - auch dort gehört ein TCP/IP Netzwerkstack zum Standard, und dieser Kontakt zwischen den Netzwerkkarten ist auch hilfreich bei Aufsetzen von Infinibandverbindungen weil es ad hoc erstmal den übliche TPC/IP Netzwerkverkehr zwischen den beteiligten Computern und Applikationen ermöglicht. Will man die Datenraten dann wirklich Nutzen benutzt man in den Apps nicht mehr TCP/IP sondern RDMA als Netzwerkprotokoll beim Schreiben von Applikationen. Und schon ist's kein Problem mehr die 40G,100G,.. auch bis zum Limit der Karte auszureizen.
Zuletzt bearbeitet:
Windows 11 und Linux können das doch schon längst. Nur der Support in Windows für externe Controller mit diesem USB4 Treiber ist neu und der ASM4242 bisher der erste Controller der das nutzt.senf.dazu schrieb:
Der größte Hub Chip bisher ist Intel's Goshen Ridge. Mit einem Upstream-Anschluss und 3 Downstream-Anschlüssen. Und wenn der in einem Dock oder Monitor ist, muss mindestens einer der Ausgänge für Bild genutzt werden. Und wir haben bisher noch keinen Monitor oder Dock gesehen das 2 davon verkettet für mehr TB Ports. Die meisten Displays mit TB4 haben wenn überhaupt 1 TB Ausgang (meistens wenn nicht nur eine sehr langsame DP Verbindung übrig bleibt). Die 2 möglichen TB-Ausgänge habe ich bisher noch nicht gesehen.senf.dazu schrieb:
Da der PC am Upstream Port der Host ist und der Rest sind Clients wüsste ich nicht was dagegen sprechen sollte das jeder Client mit dem Host kommunizieren kann und umgekehrt. Die Clients untereinander glaube ich hingegen weniger. Das erfordert so oder so, dass der Host aktiv hilft. Aktuell in Form einer Bridge.senf.dazu schrieb:
Geschrieben wird überall immer von 10G. Die virtuelle Netzwerkverbindung selbst taucht schon ewig mit 20G auf.senf.dazu schrieb:
Ich habe mir bisher aber nicht die Mühe gemacht das mit 2 Linux Hosts zu testen. Und Windows hat schon häufig Probleme auch nur die 10G auszulasten. Die alten TB Treiber limitieren auch die IP Paketgröße, während der Windows USB4 Treiber schon quasi Jumbo Frames nutzt (in die eine Richtung geht es dann trotz Windows Firewall schnell, in die andere nicht).
Ich habe mittlerweile die Presseveröffentlichungen von Intel gelesen. Die sprechen sogar davon, dass der PC durch die Windows Firewall geschützt bleibt. Klingt also als ob Intel das ganze nur on-top vom vorhandenen Netzwerk umsetzt.
Der aktuelle USB4 Standard schreibt wohl die Unterstützung von bis zu 64k (Jumbo) Paketen vor wenn ich mich recht entsinne.Ray519 schrieb:
Und TB3 Unterstützung (und was auch immer die Hardware so konnte - "alte TB Treiber" ?) ist für USB4 inzwischen "optional". (Denn USB4V2 liefert eigentlich das bessere TB3 Protokollmix, nicht nur DP,PCIe,Networking sondern USB,DP,Networking,PCIe wobei PCIe aber optional ist, Daten kann halt jetzt USB)
Ergänzung ()
Eine Möglichkeit mehr USB4 Anschlüsse zu erhalten wäre die Kaskadierung von Hubs. Bin mir aber unklar ob der USB4 Standard das für Host to Host Networking unterstützen muß.Ray519 schrieb:
Für reines USB4-Networking (im Unterschied zum USB,DP,PCIe Traffic in einem USB-Tree) wenn's denn irgendwann mal kommt wären natürlich auch jeder Prozessor mit 4+ USB4 Ports und etwas Hauptspeicher als schneller Netzwerkswitch denkbar ..
Ergänzung ()
Ich les den USB4 Standard nicht so das einer der Hosts am Upstream Port eine zwingende Notwendigkeit für das Host 2 Host Networking zwischen 2 PCs ist. Der gibt sich aber zugegeben an der Stelle sehr wortkarg und dadurch interpretierbar. Auch was das Kaskadieren von Hubs angeht.Ray519 schrieb:
Diese Host 2 Host Verbindung widerspricht eh der Baumstruktur im USB Baum - die Verbindung muß vom Hub erkannt werden und die Host2Host Netzwerkpakete nach eigenen Regeln weiterleiten aber keine USB Pakete drüber schicken oder entgegennehmen.
Sprich der Hub (bzw. eigentlich dann der Host des USB Netzwerks) muß bei einem Downstream Port feststellen das dort kein (USB) Device angeschlossen ist sondern ein Computer. Und im Hintergrund laufen in diesen Hubs eh PCIe Switches - aber dieser interne PCIe-Bus (der auch üblicherweise neben dem PCIe Verkehr Grundlage für die Implementierung der Host2Host Networking Funktion ist - ist eh ein Multi-Master-Bus der. freie Kommunikation der angeschlossenen Computer und Devices ermöglicht. Keine Tree-Architektur wie USB.
Zuletzt bearbeitet:
Ich denke, die Netzwerkverbindung ist gar kein Muss bei USB4, wie so vieles. Aber ich sehe keinen guten Grund warum das nicht klappen sollte. Es wird eh schon ein Treiber Connection Manager genutzt (bei offiziellem USB4. Bei Legacy TB Treibern der Firmware Connection Manager). Der versteht also die Topologie und richtet Verbindungen / Tunnel ein für jede Funktion für jedes Gerät. Wie gesagt, es gibt dabei nur einen Host. Und der muss den DMA-"Tunnel" wie ein DP Tunnel aufbauen von und und zu den TB Client Devices. Und dann muss der virtuelle Netzwerktreiber darüber gestülpt werden. Nichts davon sollte sich ändern wenn die Hierarchie tiefer wird. Die anderen Tunnel gehen ja auch. Wobei es da zumindest bei Intel ein Limit basierend auf Ausgängen zu geben scheint (die viel-zitierten 6 Geräte chained). Und mit Hubs scheints du das Limit wesentlich früher zu erreichen. Ich habe leider nur einen TB4 hub. Der Rest sind TB3 Docks mit jeweils nur einem Ausgang.senf.dazu schrieb:
Das liegt nur daran wie sie umgansprachlich genannt wird, nicht wie sie funktioniert. Das versuche ich zu erklären.senf.dazu schrieb:
Das hier ist mein TB4 Maple Ridge Host. Der obere PCIe Switch ist der Maple Ridge Controller selbst. Der seine eine PCIe Anbindung zum Host aufteilt in je eine für jeden TB Port, eine für seinen eigenen USB3 Controller und eine für DMA, wo dann auch die virtuellen Netzwerkadapter auftauchen.
Die Daten gehen zwar durch die PCIe Verbindung zwischen CPU und TB4 Controller. Aber nicht durch die PCIe Tunnel die durch den TB4 Hub gehen (der 2. PCIe Switch).
---
Das ist die Gegenseite. Die TypeC PCIe Ports ist wo PCIe Tunnel aus den USB4 Ports herkommen würden. Aber die sind nicht involviert. Stattdessen kommt die virtuelle Netzwerkverbindung vom USB4 Host Router, der in dem Fall die DMA Kommunikation handhabt. Der TB4 Hub oder was anderes taucht auch nicht auf in der USB4 Geräteübersicht von dem Gerät.
-> In dem Fall ist mein Maple Ridge Host der Host, der die USB4 Hierarchie aufsetzt. Und mein AlderLake-P Host ist nur ein Client in dieser Hierarchie.
Und hier der TB3 Titan Ridge Host der ebenfalls an einem Downstream Port vom TB4 Hub hängt:
Gleiches Bild -> Client. Nur in der alten TB Treiber Struktur statt der USB4 Standard/Treiber Struktur.
Nein. Der Connection Manager stellt fest es ist ein USB4 Controller dort. Er fragt ab was für Features der USB4 Controller hat und dann etabliert er einen DMA Tunnel bis dahin, weil das die einzige Funktion ist, die von beiden Unterstützt wird. Für den Hub ist das nichts anderes als normal. Und ein USB4 Hub kann Daten auch außerhalb von PCIe weiterleiten. Das ist sogar der einfachere und schnellere Fall. Weil die Route ist vorgeplant, während PCIe Switches nach den Adressen gehen müssen und für jede Adresse herausfinden müssen, in welchen Bereich die Adresse fällt, damit sie den richtigen Ausgangsport zum weiterleiten auswählen können.senf.dazu schrieb:
Zuletzt bearbeitet:
Muß nicht sein. AMD kann für seine CPUs ja TB4/5 von Intel zertifizieren lassen. Lizenzfrei einbauen dürfen sie USB4 wohl so oder so - Intel hat das TB3 PHY Protokoll (und ich vermute auch TB5) freigegeben.icetom schrieb:
Und für Intel ist's wichtiger das USB4 ein Erfolg wird und sie so viele viele eigene CPUs (für 100e oder 1000e €) verkauft kriegen statt je Port bei der Konkurrenz einen schlappen $ einzusammeln.
Ist also unwahrscheinlich das sie AMD behindern wenn die freiwillig die USB4 und TB4/5 Technik promoten wollen ..
martinallnet
Captain
- Registriert
- Aug. 2015
- Beiträge
- 3.659
Gibt es bereits Docks und TB LWL-Kabel, nix neues.Charminbaer schrieb:
Sie ist mandatory für Host und Hub. Und der von dir zitierte Connection Manager nutzt sie wohl um mit den Hubs und Devices zu reden und z.B. die Tunnel zu konfigurieren. Was glatt ein Grund für's mandatory sein könnte - neben der Tatsache das Intel (und vielleicht auch das USB-Forum) sicher auch (sehr sinnvolle) Netzwerkhintergedanken für die kommenden USB Versionen hat. (Die sich materialisieren sobald consumertaugliche Preise für optische Transceiver gibt und damit für beliebig lange optische Kabel)Ray519 schrieb:
Der Standard sagt dazu etwas wie: Typ wird man das Netzwerk von PCIe Switches für die Implementierung des USB Networking nutzen. Wenn man im Hub die PCIe Switches nicht implementiert muß es eine andere gleichwertige Lösung für's Networking bereitstellen.
Und technisch glaub ich eh das die USB4 Hubs schlicht aufgemotzte PCIe Switches sind - die eben nicht nur PCIe Pakete entgegenehmen und zu irgendwelchen der Ausgangsports weiterleiten und gelegentlich dabei auch mal Tunnelpakete auspacken, sondern eben auch USB, DP, Netzwerk, In Version 2,3,4, 1.2, 1.3, 1.4, 2.0, 2.1 und weitere und getunnelte Varianten. Wobei das was wohin weitergeleitet wird dann eben noch vom Connection Manager konfiguriert werden kann. Die hochkomplizierten Blockdiagramme im USB Standart dienen nur zum Rückbezug auf die älteren Standards wie USB3, DP, .. damit man die nicht alle im USB4 Standard wiedererzählen muß aber dürften mit der technischen Implementierung wenig zu tun haben.
Ich steh zwar mit den PHY Protokollen nicht auf du und du, aber ich denke das Infiniband, PCIe, superspeed USB (sprich USB3 und USB4 bzw. eher TB4 und TB5 aber auch TB3 PHY) und das verblichene Omnipath eh alles ähnliche Protokollsauce ist. Da hat überall Intel maßgeblich mitgespielt bzw. selbst gespielt. Im Extremfalle sind die Pakete alle (fast) identisch und es gibt wie so üblich eine 8 bit Protokollnummer ..
https://en.wikipedia.org/wiki/USB4#Data_transfer_modes
Die Tabelle zum "Transfer Mode Support" glaub ich erstmal (die engl. Seite scheint gepflegt zu werden) - auch da steht ein mandatory für's Networking von Hosts und Hubs.
Zuletzt bearbeitet:
Dann reden wir aneinander vorbei. Weil mit "Netzwerkverbindung" beziehe ich mich auf die virtuelle IP Netzwerkverbindung.senf.dazu schrieb:
Du vermischst hier viele verschiedene Dinge. Abstrakt gesehen, sind das alles ganz unterschiedliche Dinge. Und der Standard wird extrem klar, wie USB4 Pakete von einem USB4 Router geroutet werden. Und dass die im Falle von PCIe durch zu einem PCIe output-Adapter gehen, dahinter kommt dann die PCIe Bridge, die normale PCIe Dinge macht und das dann durch einen PCIe Input-Adapter wieder in die USB4 Verbindung einspeist. Genauso mit USB3 Paketen und einem USB3 Hub.senf.dazu schrieb:
Da das alles auf einem einzigen Chip stattfindet, ist es natürlich viel schwerer zu sagen, wie Intel das nun implementiert hat. Da könnten sie die verschiedenen Funktionen tief miteinander integrieren um die Performance zu erhöhen. Das weiß niemand. Noch habe ich keine Analyse des Dies gesehen. Und wenn man sich bewusst ist, das Goshen Ridge TB4 Controller ein hartes Limit auf 32 GBit/s PCIe Bandbreite bewirken, auch wenn der Host und die Gerät dahinter mehr Bandbreite können, klingt das eher als ob Intel sich da an einer klassischen PCIe Bridge orientiert, wie sie sie auch an anderen Stellen nutzen und deshalb klassische PCIe Limits erben, die USB4 eigentlich komplett egal sind, gerade wenn das alles nur virtuell stattfindet.
Und wenn du davon überzeugt bist, das USB3 und PCIe ähnlich sind, dann liegst du sehr falsch und ich brauche nicht weiter versuchen Dinge zu erklären.
Edit:
Übrigens wird das ganze in "USB4 Inter Domain Service Protocol" spezifiziert. Inklusive wie exakt das virtuelle Netzwerk funktioniert. Da scheinen mir Ethernet Pakete mit bis zu 64 KiB optional zu sein (der Empfänger kann angeben, dass das nicht gemacht werden soll). Und nachdem die Verbindung gefunden und eingerichtet wurde mithilfe von Control-Paketen, wird ein Tunnel verwendet, wie ich beschrieben habe. Und da Hubs die Tunnel selbst völlig egal sind kann ein USB4 Hub nichts tun um das zu unterbinden. Weil Tunnel muss er eh können.
Zuletzt bearbeitet:
Ich red nicht davon das USB3 und PCIe ähnlich sind, sondern das die Paketstruktur der PHY Pakete (und nichts sonst) vielleicht ähnlich ist und ähnliche elektrische Signalisierung und Kanalkodierungen verwendet. Und das ist im Prinzip das was ein Paket-hub/switch sieht.Ray519 schrieb:
Ergänzung ()
Voll einverstanden. Der Standard sagt genau was am Ende herauskommen muß an Paketübertragung. Aber aber sagt nichts oder sehr wenig drüber aus wie die Implementierung aussehen sollte.Ray519 schrieb:
Er sagt aber auch das Networking implementiert werden muß (soweit ich mich erinnere ..)
Ergänzung ()
Mag sein. Ich red jedenfalls vom USB4 Host to Host Networking. Das hat aber an sich nix spezifisch mit IP oder einem TCP/IP Protokoll zu tun sondern definiert nur eine Methode um Pakete von einem USB Host zu anderen im USB-Tree erreichbaren Stationen zu schicken. Und in diesen Paketen kann z.B. ein IP Paket eingepackt sein.Ray519 schrieb:
Einerseits kann der Host (Computer) das wohl nutzen um die verschiedenen Komponenten im diesem Host zugeordneten USB-Baum (wie die USB4-Hubs) zu konfigurieren, andererseits aber eben auch um IP Übertragung von Host zu Host zu realisieren und damit USB4 Ethernet bzw. USB4 Networking für die beteilligten Computer zu realisieren. Die Details kenn ich aber auch nicht - will ich auch nicht unbedingt wissen.
Aber ich denke das die USB4 Hosts (die Computer) dann diese dann Pakete, die die USB4 Hardware per DMA in den Hauptspeicher des Computers/Hosts schreibt, hernehmen und die als IP/netbios Pakete in einen Software TCP/IP Stack (außerhalb der USB4 Treiberei) stecken. Woraus dort der 10G..20G Datenratenlimit entsteht. Welchen Limitationen diese networking Infrastruktur selbst unterliegt bleibt offen - aber da ist wohl doch einiges an Pufferverwaltung und einzelne Puffer bis 64k vorgeschrieben was hoffen läßt - und was für reine USB-Tree interne Konfigurationszwecke wohl Overkill wär.
Zuletzt bearbeitet:
Wenn du findest wo der Standard das sagt, sag mir bescheid. Es ist möglich das das Pflicht ist. Aber zu finden wo explizit steht ob etwas verpflichtend ist, ist das schwerste daran.senf.dazu schrieb:
Denn die Test Spezifikationen listen Dateitransfer über USB4 Networking. Aber die Listen auch auch PCIe Traffic mit TB3 Geräten. Und wir wissen, dass TB3 und PCIe Support optional ist. Steht aber nicht direkt neben dem Test das der optional ist oder unter welcher Bedingung der steht.
Und Host2Host Communications wie auch dein Wiki-Artikel es nennt (offiziell wohl Inter Domain Communications) ist eben nicht USB4 Networking. Host2Host Communications ist erstmal wie man einen anderen Host findet und ihn Fragt ob er Networking kann. Und wenn er das kann, dann wird nach USB4Net Protokoll eine Verbindung aufgebaut für Ethernet (steht so im Inter Domain Service Protocol Standard). Das kann also sein, das der Wiki Artikel hier richtig liegt und trotzdem nicht meint das P2P Networking Pflicht ist.
Und Host2Host sind erstmal nur Control Pakete, die grundsätzlich gehen müssen, weil so die ganze Topologie eingerichtet werden muss.
Und "PHY Pakete" ist erstmal ein sehr seltsamer Begriff. Wenn du damit dann elektrische Spezifikationen meinst noch seltsamer. Und das spezifiziert USB4 auch gar nicht. Die elektrischen Spezifikationen von PCIe, DP, USB3 sind auf einer USB4 Verbindung völlig egal. Da gibt es erstmal nur die USB4 Verbindung, die übertragt USB4 Pakete die vllt den Inhalt von zB USB3 Paketen haben (ein ganzes Stück weit geschält, weil man die ganzen unteren Layer von USB3 nicht braucht, nur den eigentlichen Inhalt), so dass sie auf der anderen Seite wieder rekonstruiert werden können in ein vollständiges USB3 Signal nach dem USB3 Standard. Das hat nun gar nichts damit zu tun, wie Pakete innerhalb einer USB4 oder TB3 Topologie geroutet werden. Denn da drin ist DP, PCIe, USB3 nur virtuell.
Zuletzt bearbeitet:
Charminbaer
Ensign
- Registriert
- Dez. 2018
- Beiträge
- 164
Jo, hab ja auch nicht geschrieben das es was Neues wäre.martinallnet schrieb:
Nur das man jetzt quasi den gesamten Host PC spiegeln kann und dafür z.B. auch die optischen Kabel nutzen kann. KVM Funktionalität in dieser Form gabs bei TB3/4 bisher ja nicht.
crogge
Lt. Commander
- Registriert
- Okt. 2004
- Beiträge
- 1.517
Freut mich das kein Hardware-Upgrade erforderlich ist, durchaus praktisch um mal schnell große Dateien auf das Laptop zu laden. Ich erinnere mich noch an RS232 Nullmodemkabel, war auch damals schon bequemer als eine Diskette zu verwenden.
@crogge das gibt es schon die ganze Zeit. Netzwerk über TB ist völlig automatisch. Verbindest du 2 PCs mit USB4/TB mit einem TB/USB4-fahigen Kabel haben die eine Netzwerkverbindung.
Das lästige dabei ist, dass du manuell die Windows Dateifreigabe einschalten musst. Und dann musst du um die Windows Firewall drum herum arbeiten. Weil die behandelt den P2P Fall, ohne Router, Internetzugang und Accesspoint nicht automatisch korrekt. Und Windows macht die nicht öffentliche Netzwerkfreigabe von Dateien auch unmöglich mit den standard Passwort Einstellungen von Windows.
Die neue Software sollte es also nur einfacher machen das beim ersten Mal in Betrieb zu nehmen. Und bündelt sowas wie Parsec mit rein.
Und du brauchst immer noch die dämliche Lizenz, für die du wahrscheinlich neue Hardware kaufen musst, weil vermutlich nur sehr wenige Anbieter Intel nachträglich für eine Lizenz bezahlen werden, für Geräte die nicht noch aktiv produziert werden, wo man das zusätzliche Feature bewerben kann.
Und dann bindest du dich damit auch noch daran bei den Herstellern zu bleiben die so eine Lizenz haben.
Wenn die Software kostenpflichtig sein soll, dann sollte man Privatkunden auch eine Lizenz kaufen lassen. So wie zB Dolby Atmos in Windows. Die Lizenz kann mit Hardware mit kommen. Aber du kannst sie auch einfach so kaufen und dann nutzen mit was auch immer für Hardware du möchtest.
Das lästige dabei ist, dass du manuell die Windows Dateifreigabe einschalten musst. Und dann musst du um die Windows Firewall drum herum arbeiten. Weil die behandelt den P2P Fall, ohne Router, Internetzugang und Accesspoint nicht automatisch korrekt. Und Windows macht die nicht öffentliche Netzwerkfreigabe von Dateien auch unmöglich mit den standard Passwort Einstellungen von Windows.
Die neue Software sollte es also nur einfacher machen das beim ersten Mal in Betrieb zu nehmen. Und bündelt sowas wie Parsec mit rein.
Und du brauchst immer noch die dämliche Lizenz, für die du wahrscheinlich neue Hardware kaufen musst, weil vermutlich nur sehr wenige Anbieter Intel nachträglich für eine Lizenz bezahlen werden, für Geräte die nicht noch aktiv produziert werden, wo man das zusätzliche Feature bewerben kann.
Und dann bindest du dich damit auch noch daran bei den Herstellern zu bleiben die so eine Lizenz haben.
Wenn die Software kostenpflichtig sein soll, dann sollte man Privatkunden auch eine Lizenz kaufen lassen. So wie zB Dolby Atmos in Windows. Die Lizenz kann mit Hardware mit kommen. Aber du kannst sie auch einfach so kaufen und dann nutzen mit was auch immer für Hardware du möchtest.
Zuletzt bearbeitet:
