7
2 Rechner (1xWin+1xLinux) über Thunderbold verbunden. Extrem langsame Geschindigkeit
Hi,
hat einer schon 2 Rechner (Win+ubuntu) mit Thunderbold verbunden?
In Windows war es einfach. Netzwerkkarte hat sich erstellt. Diese dann noch entsprechend konfiguriert:
In Linux war es nicht ganz so trival.
Über "ip addr" erstmal die Schnittstelle rausbekommen und diese dann mittels "sudo ifconfig thunderbolt0 up" aktiviert.
Dann noch ein paar ifconfig-Befehle hinterher.
Jetzt sieht es so aus:
2 Probleme fallen mir auf:
1: Thunderbold 3. Ergo 20Gbits. In Windows passt das auch. Wird als 20Gbits angezeigt.
Schaut man sich aber nochmal das Bild an, schieb er durchweg nur 10Gbits.
2: Diese kommen aber nicht wirklich an. Ich hab mit dd mal eine 100GB Datei erstellt. Auch nach 10min war die noch nicht fertig.
Schaut man nun nochmal Linux die letze Ausgabe an hat er bereits 716GB gesendet (sollte aber nur um die 100GB sein)
Ich vermute mal das MTU nicht passt (?)
Da sehr große Datein verschoben werden äre JumboFrame vlt. garnicht so falsch. Da das ganze aber schon mit MTU1500 Probleme hat, brauch ich mit 9000 oder so garnicht erst testen.
Die Frage nun: Ist es wirklich der MTU Wert oder denkt ihr es liegt an was anderem ?
Falls MTU: wie bekomme ich den den optimalen Wert raus ?
hat einer schon 2 Rechner (Win+ubuntu) mit Thunderbold verbunden?
In Windows war es einfach. Netzwerkkarte hat sich erstellt. Diese dann noch entsprechend konfiguriert:
In Linux war es nicht ganz so trival.
Über "ip addr" erstmal die Schnittstelle rausbekommen und diese dann mittels "sudo ifconfig thunderbolt0 up" aktiviert.
Dann noch ein paar ifconfig-Befehle hinterher.
Jetzt sieht es so aus:
7: thunderbolt0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 12:7e:72:e4:27:c1 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.151/24 brd 192.168.1.255 scope global thunderbolt0
valid_lft forever preferred_lft forever
inet6 fe80::107e:72ff:fee4:27c1/64 scope link
valid_lft forever preferred_lft forever
bzw:
thunderbolt0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.151 netmask 255.255.255.0 broadcast 192.168.1.255
inet6 fe80::107e:72ff:fee4:27c1 prefixlen 64 scopeid 0x20<link>
ether 12:7e:72:e4:27:c1 txqueuelen 1000 (Ethernet)
RX packets 7222841 bytes 404801982 (404.8 MB)
RX errors 0 dropped 5 overruns 0 frame 0
TX packets 14905335 bytes 716545775059 (716.5 GB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 02 Probleme fallen mir auf:
1: Thunderbold 3. Ergo 20Gbits. In Windows passt das auch. Wird als 20Gbits angezeigt.
Schaut man sich aber nochmal das Bild an, schieb er durchweg nur 10Gbits.
2: Diese kommen aber nicht wirklich an. Ich hab mit dd mal eine 100GB Datei erstellt. Auch nach 10min war die noch nicht fertig.
Schaut man nun nochmal Linux die letze Ausgabe an hat er bereits 716GB gesendet (sollte aber nur um die 100GB sein)
Ich vermute mal das MTU nicht passt (?)
Da sehr große Datein verschoben werden äre JumboFrame vlt. garnicht so falsch. Da das ganze aber schon mit MTU1500 Probleme hat, brauch ich mit 9000 oder so garnicht erst testen.
Die Frage nun: Ist es wirklich der MTU Wert oder denkt ihr es liegt an was anderem ?
Falls MTU: wie bekomme ich den den optimalen Wert raus ?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 667370
Url: https://administrator.de/forum/2-rechner-1xwin-1xlinux-ueber-thunderbold-verbunden-extrem-langsame-geschindigkeit-667370.html
Ausgedruckt am: 31.12.2024 um 09:12 Uhr
7 Kommentare
Neuester Kommentar
Nachtrag:
In mesg zeigt sich folgendes:
gemountet hatte ich wie folgt:
In mesg zeigt sich folgendes:
[ 401.635814] IPv6: ADDRCONF(NETDEV_CHANGE): thunderbolt0: link becomes ready
[ 655.718036] FS-Cache: Loaded
[ 655.742859] FS-Cache: Netfs 'cifs' registered for caching
[ 655.745405] Key type cifs.spnego registered
[ 655.745410] Key type cifs.idmap registered
[ 655.745767] CIFS: Attempting to mount //192.168.1.150/test
[ 655.745785] No dialect specified on mount. Default has changed to a more secure dialect, SMB2.1 or later (e.g. SMB3), from CIFS (SMB1). To use the less secure SMB1 dialect to access old servers which do not support SMB3 (or SMB2.1) specify vers=1.0 on mount.
[ 655.759511] Status code returned 0xc000006d STATUS_LOGON_FAILURE
[ 655.759516] CIFS VFS: \\192.168.1.150 Send error in SessSetup = -13
[ 655.759525] CIFS VFS: cifs_mount failed w/return code = -13
[ 698.884628] CIFS: Attempting to mount //192.168.1.150/test
[ 698.884667] No dialect specified on mount. Default has changed to a more secure dialect, SMB2.1 or later (e.g. SMB3), from CIFS (SMB1). To use the less secure SMB1 dialect to access old servers which do not support SMB3 (or SMB2.1) specify vers=1.0 on mount.
[ 2039.504199] CIFS VFS: \\192.168.1.150 No task to wake, unknown frame received! NumMids 105
[ 2039.504211] 00000000: 424d53fe 00000040 00000000 00000012 .SMB@...........
[ 2039.504214] 00000010: 00000001 00000000 ffffffff ffffffff ................
[ 2039.504216] 00000020: 00000000 00000000 00000000 00000000 ................
[ 2039.504218] 00000030: 00000000 00000000 00000000 00000000 ................
[ 2135.308597] CIFS VFS: Close unmatched opengemountet hatte ich wie folgt:
sudo mount -t cifs -o username=<username>,domain=WORKGROUP,uid=1000 //192.168.1.150/test /mnt/Network
Nachtrag 2: Ich habe 2 Netze.
LAN = 192.168.0.0/24
Thunderbold = 192.168.1.0/24
Falls das noch von relevanz sein sollte.
LAN = 192.168.0.0/24
Thunderbold = 192.168.1.0/24
Falls das noch von relevanz sein sollte.
Moin,
das kann natürlich auch an was ganz anderem liegen: Kabellänge, Kabelqualität, irgendwelche Gerätschaften (wie den Hub aus Deinem anderem Thread) dazwischen usw.
Du könntest auch mal ein paar Details zu den verwendeten PCs/Laptops (Hersteller, Modell usw.) preisgeben, dann kann man eventuell besser helfen. Was für eine SSD-Technik (Anschluss) wird auf beiden Seiten verwendet? Ggf, ist SMB/CIFS auch nicht der ideale Testkandidat.
Gruß
cykes
das kann natürlich auch an was ganz anderem liegen: Kabellänge, Kabelqualität, irgendwelche Gerätschaften (wie den Hub aus Deinem anderem Thread) dazwischen usw.
Du könntest auch mal ein paar Details zu den verwendeten PCs/Laptops (Hersteller, Modell usw.) preisgeben, dann kann man eventuell besser helfen. Was für eine SSD-Technik (Anschluss) wird auf beiden Seiten verwendet? Ggf, ist SMB/CIFS auch nicht der ideale Testkandidat.
Gruß
cykes
Ggf, ist SMB/CIFS auch nicht der ideale Testkandidat.
Richtig. Weil es eins der schlechtesten und ineffizientesten Protokolle dafür ist wegen der kleinen Pakete.Sinnvoll misst man mit iPerf3 was einem dann wirklich verlässliche Nettwerte gibt pro Paketgröße statt diese sinnfreie Frickelei mit SMB/CIFS. Zudem kann man mit mehreren Streams messen.
https://www.computerweekly.com/de/tipp/Mit-iPerf3-Netzwerkbandbreite-Jit ...
usw.
Moin,
Das wesentliche wurde von den Kollegen ja schon gesagt:
Erstmal die beiden Kisten direkt mit Thunderbolt verbinden, ohne Ethernet! und dann mit iperf3 mal messen. Dann sieht man erstmal, wie die Performance ist. Danach kann man mit Ethernet udn Hub Komponenten dazunehmen udn schauen, ob iperf3 imerm ncoh die gleiche Performance bescheinigt.
Erst als letzten Schritt würde ich die Messung mit SMB/CIFS druchführen.
lks
Das wesentliche wurde von den Kollegen ja schon gesagt:
Erstmal die beiden Kisten direkt mit Thunderbolt verbinden, ohne Ethernet! und dann mit iperf3 mal messen. Dann sieht man erstmal, wie die Performance ist. Danach kann man mit Ethernet udn Hub Komponenten dazunehmen udn schauen, ob iperf3 imerm ncoh die gleiche Performance bescheinigt.
Erst als letzten Schritt würde ich die Messung mit SMB/CIFS druchführen.
lks
Oki. Dann will ich mal das geforderte umsetzen.
Also: 2 Intel NUC mit jeweils 2 x Thunderbolt 3
https://www.intel.de/content/www/de/de/products/sku/190109/intel-nuc-9-e ...
Rechner stehen ca. 20cm nebeneinander. Das Thunderbold3 Kabel ist direkt von ein Gerät, was für Thunderbold 3 vorgesehen ist. Somit gehe ich erstmal davon aus, dass das Kabelseitig ok ist und die Leistung auch bringt
https://www.owcdigital.com/products/thunderbolt-3-dock-14-port
Der "Server" ist ein Windows 10 System mit einer Seagate fire SSD Gen4 x4 512 GB
Der "Client" ist ein Ubunto 20.04 System mit einer PNY CS3040 SSD Gen4 x4 1TB
Beide schaffen hier um die 3GBSchreiben und 2,5GB Lesen
5 Durchläufe unmittelbar hintereinander
HW sollte somit nicht die Bremse sein.
Gestern ist mir noch der unterschiedliche MTU Wert auf beiden Seiten aufgefallen.
netsh interface ipv4 show interfaces => zeigte auf Windows Seite einen MTU von 65522
Mittels "netsh interface ipv4 set subinterface 46 mtu=1400 store=persistent" erstmal auf einen passenden Wert gebracht.
Linuxseitig natürlich auch: sudo ifconfig thunderbolt0 mtu 1400
Somit passt das beidseitig. Speedtest zeigten aber identisches Verhalten. Daran lag es wohl nicht.
Zum iperf3-Test:
Windowsseitig:
Linuxseitig:
Ich spiele nachher nochmal ein wenig rum. Das jetzt nur zur Beantwortung eurer Fragen.
P.s.
Also: 2 Intel NUC mit jeweils 2 x Thunderbolt 3
https://www.intel.de/content/www/de/de/products/sku/190109/intel-nuc-9-e ...
Rechner stehen ca. 20cm nebeneinander. Das Thunderbold3 Kabel ist direkt von ein Gerät, was für Thunderbold 3 vorgesehen ist. Somit gehe ich erstmal davon aus, dass das Kabelseitig ok ist und die Leistung auch bringt
https://www.owcdigital.com/products/thunderbolt-3-dock-14-port
Der "Server" ist ein Windows 10 System mit einer Seagate fire SSD Gen4 x4 512 GB
Der "Client" ist ein Ubunto 20.04 System mit einer PNY CS3040 SSD Gen4 x4 1TB
Beide schaffen hier um die 3GBSchreiben und 2,5GB Lesen
5 Durchläufe unmittelbar hintereinander
107374182400 bytes (107 GB, 100 GiB) copied, 37.3229 s, 2.9 GB/s 10737418240 bytes (11 GB, 10 GiB) copied, 4.2646 s, 2.5 GB/s
107374182400 bytes (107 GB, 100 GiB) copied, 33.4565 s, 3.2 GB/s 10737418240 bytes (11 GB, 10 GiB) copied, 4.28972 s, 2.5 GB/s
107374182400 bytes (107 GB, 100 GiB) copied, 33.4132 s, 3.2 GB/s 10737418240 bytes (11 GB, 10 GiB) copied, 4.34943 s, 2.5 GB/s
107374182400 bytes (107 GB, 100 GiB) copied, 33.5882 s, 3.2 GB/s 10737418240 bytes (11 GB, 10 GiB) copied, 4.3992 s, 2.4 GB/s
107374182400 bytes (107 GB, 100 GiB) copied, 33.5451 s, 3.2 GB/s 10737418240 bytes (11 GB, 10 GiB) copied, 4.32983 s, 2.5 GB/sHW sollte somit nicht die Bremse sein.
Gestern ist mir noch der unterschiedliche MTU Wert auf beiden Seiten aufgefallen.
netsh interface ipv4 show interfaces => zeigte auf Windows Seite einen MTU von 65522
Mittels "netsh interface ipv4 set subinterface 46 mtu=1400 store=persistent" erstmal auf einen passenden Wert gebracht.
Linuxseitig natürlich auch: sudo ifconfig thunderbolt0 mtu 1400
Somit passt das beidseitig. Speedtest zeigten aber identisches Verhalten. Daran lag es wohl nicht.
Zum iperf3-Test:
Windowsseitig:
PS C:\Users\test\Downloads\iperf-3.1.3-win64> .\iperf3.exe -s
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
Accepted connection from 192.168.1.152, port 46330
[ 5] local 192.168.1.150 port 5201 connected to 192.168.1.152 port 46332
[ ID] Interval Transfer Bandwidth
[ 5] 0.00-1.00 sec 679 MBytes 5.69 Gbits/sec
[ 5] 1.00-2.00 sec 455 MBytes 3.82 Gbits/sec
[ 5] 2.00-3.00 sec 541 MBytes 4.54 Gbits/sec
[ 5] 3.00-4.00 sec 632 MBytes 5.30 Gbits/sec
[ 5] 4.00-5.00 sec 456 MBytes 3.83 Gbits/sec
[ 5] 5.00-6.00 sec 524 MBytes 4.40 Gbits/sec
[ 5] 6.00-7.00 sec 642 MBytes 5.39 Gbits/sec
[ 5] 7.00-8.00 sec 635 MBytes 5.32 Gbits/sec
[ 5] 8.00-9.00 sec 457 MBytes 3.83 Gbits/sec
[ 5] 9.00-10.00 sec 442 MBytes 3.71 Gbits/sec
[ 5] 10.00-10.00 sec 250 KBytes 3.22 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth
[ 5] 0.00-10.00 sec 0.00 Bytes 0.00 bits/sec sender
[ 5] 0.00-10.00 sec 5.33 GBytes 4.58 Gbits/sec receiver
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------Linuxseitig:
sudo iperf3 -c 192.168.1.150
Connecting to host 192.168.1.150, port 5201
[ 5] local 192.168.1.152 port 46332 connected to 192.168.1.150 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 680 MBytes 5.70 Gbits/sec 0 211 KBytes
[ 5] 1.00-2.00 sec 455 MBytes 3.82 Gbits/sec 0 211 KBytes
[ 5] 2.00-3.00 sec 541 MBytes 4.54 Gbits/sec 0 211 KBytes
[ 5] 3.00-4.00 sec 632 MBytes 5.31 Gbits/sec 0 211 KBytes
[ 5] 4.00-5.00 sec 456 MBytes 3.83 Gbits/sec 0 211 KBytes
[ 5] 5.00-6.00 sec 524 MBytes 4.39 Gbits/sec 0 211 KBytes
[ 5] 6.00-7.00 sec 642 MBytes 5.39 Gbits/sec 0 211 KBytes
[ 5] 7.00-8.00 sec 634 MBytes 5.32 Gbits/sec 0 211 KBytes
[ 5] 8.00-9.00 sec 456 MBytes 3.83 Gbits/sec 0 211 KBytes
[ 5] 9.00-10.00 sec 442 MBytes 3.71 Gbits/sec 0 211 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 5.34 GBytes 4.58 Gbits/sec 0 sender
[ 5] 0.00-10.00 sec 5.33 GBytes 4.58 Gbits/sec receiver
iperf Done.Ich spiele nachher nochmal ein wenig rum. Das jetzt nur zur Beantwortung eurer Fragen.
P.s.
Ggf, ist SMB/CIFS auch nicht der ideale Testkandidat.
Welcher Typ wäre denn für 100GB Datein denn am idealsten ?
P.s. NFS v4 scheint wohl besser zu sein... aber Windows 10 hat NFS Server garnicht. Nur die Windows Server haben diesen wohl. Für die Clients habe ich hierzu bisher noch nichts gefunden
