[Sammelthread] 10Gbit Homenetzwerk

Hab nur die Win11 Pro, hab das grundlegende Hyper-V Geraffel isntalliert (oben nur ein HAken, MAnagement-Werkzeuge beide Haken).
Dann unter Powershell im Admin Mode (mein olles Beispiel aus meinem Wiki für die X520 damals):
Bash:
Get-NetAdapter
New-VMSwitch -name vSwitch -NetAdapterName X520 -AllowManagementOS $true
Remove-VMNetworkAdapter -ManagementOS -Name vSwitch
Add-VMNetworkAdapter -ManagementOS -Name "VLAN10" -SwitchName "vSwitch" -Passthru | Set-VMNetworkAdapterVlan -Access -VlanId 10
Add-VMNetworkAdapter -ManagementOS -Name "VLAN30" -SwitchName "vSwitch" -Passthru | Set-VMNetworkAdapterVlan -Access -VlanId 30
Add-VMNetworkAdapter -ManagementOS -Name "VLAN32" -SwitchName "vSwitch" -Passthru | Set-VMNetworkAdapterVlan -Access -VlanId 32
Add-VMNetworkAdapter -ManagementOS -Name "VLAN64" -SwitchName "vSwitch" -Passthru | Set-VMNetworkAdapterVlan -Access -VlanId 64
Get-NetAdapter
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Heute frisch angekommen:


Kann folgende Verbrauchswerte laut einer Nous A1T mitteilen:

Code:
"Nackt": 2,3 W
1x 2.5: 3.1 W
1x 2.5+ 1x1.0: 3.6 W
2x 2.5+ 1x1.0: 4.4 W


Und so teilt einem der Switch die einzelnen Ports mit:

Port1: Mikrotik RB5009G + 10Gtek ASF-10G2-T
Port2: Realtek RTL8111H (wird demnächst ersetzt)
Port3: TP-Link Omada EAP723

1771882194101.png


Konnte zu dem Modell nirgends im Netz etwas finden, weswegen ich neugierig war.

Was könnte ich testen, um den Ding ein wenig auf den Zahn zu fühlen? :)

EDIT:

Folgendes bietet das Web-IF an:

1771885948793.png
 
Zuletzt bearbeitet:
Heute frisch angekommen:


Kann folgende Verbrauchswerte laut einer Nous A1T mitteilen:

"Nackt": 2,3 W
1x 2.5: 3.1 W
1x 2.5+ 1x1.0: 3.6 W
2x 2.5+ 1x1.0: 4.4 W
[...]
Was könnte ich testen, um den Ding ein wenig auf den Zahn zu fühlen? :)
Vielleicht mal einen 10Gb Port?
 
Dafür fehlen mir noch SFP Module, die ich bisher noch nicht besorgt habe :)
 
Ja du hast Recht. Ist nicht jedermanns mit LWL. Meistens wird dann doch nach RJ geguckt :drool: Schon ok.
Ich meinte jenes

Die RJ haben wohl alle überall (?) 2.5W. Wobei das nicht bedeuten muss, daß verschiedene Switche dabei ähnlich hochschalten. Da gibt es tatsächlich auch unterschiede was da an der steckdose los ist, wenn man ein RJ Modul einsteckt. Das wird nicht nur von den "2.5W" bestimmt.

@ all
Man findet auch RJ45-Module (ich rede natürlich durchgehend von 10Gb) die nicht 100m können sollen, sondern nur 30m. Was öfters schon ausreichen würde. Machen die an der Steckdose weniger Bambule?
 
Ja du hast Recht. Ist nicht jedermanns mit LWL. Meistens wird dann doch nach RJ geguckt :drool: Schon ok.
Ich meinte jenes

Die RJ haben wohl alle überall (?) 2.5W. Wobei das nicht bedeuten muss, daß verschiedene Switche dabei ähnlich hochschalten. Da gibt es tatsächlich auch unterschiede was da an der steckdose los ist, wenn man ein RJ Modul einsteckt. Das wird nicht nur von den "2.5W" bestimmt.

@ all
Man findet auch RJ45-Module (ich rede natürlich durchgehend von 10Gb) die nicht 100m können sollen, sondern nur 30m. Was öfters schon ausreichen würde. Machen die an der Steckdose weniger Bambule?
Hat im Fall des XikeStore einen nahezu vernachlässigbaren Unterschied gemacht
 
"und betreibt" siehst du hier ;)
Was ich zum Verbrauch des XikeStor SKS8300-8T sagen kann...
  • 10,3W mit leeren Ports
  • 12,4W mit 1 Port
  • 14,5W mit 2 Ports
  • 2,1W je Port
  • +0,1W @ load
load war @ 100% = 10G-Auslastung

Den EnGenius kann ich bei Gelegenheit irgendwann mal durchmessen. Die verbauten Controller im XikeStore kenne ich nicht (wurde nie geöffnet, weil versiegelt - der EnGenius hat keine Siegel am Case)
 
"und betreibt" siehst du hier ;)

load war @ 100% = 10G-Auslastung

Den EnGenius kann ich bei Gelegenheit irgendwann mal durchmessen. Die verbauten Controller im XikeStore kenne ich nicht (wurde nie geöffnet, weil versiegelt - der EnGenius hat keine Siegel am Case)

wohl...
Realtek RTL9303 SoC
8x REALTEK 8261BE 10GbE

Beitrag automatisch zusammengeführt:

... bevor ichs vergesse

Für die Engenius gibt's wohl ne neue "homecloud"

 
Zuletzt bearbeitet:
Wenn sich zwischen Link und Load kaum etwas ändert, ist das eigentlich ein schlechtes Zeichen bzw. eine dürftige HW.
 
Hab grad keinen Vergleich zu SPF+
Fakt ist, dass man mit einer leeren SFP-Buchse am Wenigsten verbraucht. Wie sieht es mit gestecktem SFP+ ohne angeschlossener Leitung bzw. mit gestecktem SFP+ mit zb angeschlossenem DAC @ idle und load aus?

Schade, dass es in 2026 immer noch nicht möglich ist, ungenutzte RJ45-Controller in den Tiefschlaf zu schicken
In meinem Fall ginge das wahrscheinlich nur in 4er-Blöcken (ein Controller für 4 Ports). K.A. wie das bei größeren Switches und bei Billig-8er-Switches aussieht (1 Controller für 8 Ports?)
 
Zuletzt bearbeitet:
@Zeitmangel:
Kannst du das irgendwie mit Maxwell belegen?
Die meiste Energie wird dazu verwendet, den Link aufrecht zu erhalten (siehe dazu IEEE_802.3(AN)).
Sobald der Link steht, arbeiten die PHYs mit 250 MHz und schieben sich gegenseitig FLPs zu, das verbrutzelt die meiste Energie.

Das bissi aufmodulieren von Nullen und Einsen fällt da kaum ins Gewicht.
 
... bevor ichs vergesse

Für die Engenius gibt's wohl ne neue "homecloud"

Hm, ok - läuft anscheinend nur unter WSL (Linux) - trotz Windows-Installer
Screenshot 2026-02-25 150947.png

Die EPC-App führt zur VM-Linux-Console - "ECP in Browser" nur über Web-GUI (http://localhost:8080/)
Für meine Zwecke reicht momentan die direkte Verbindung über IP und Cloud-App (iOS - wahlweise unter WIN11)

Was nach der 9-monatigen "Basic"-Lizenz passiert - k.A
Aber man braucht wohl min. eine kostenlose Lizenz (last Pic)
 

Anhänge

  • Screenshot 2026-02-25 144111.png
    Screenshot 2026-02-25 144111.png
    11,6 KB · Aufrufe: 23
  • Screenshot 2026-02-25 144440.png
    Screenshot 2026-02-25 144440.png
    11,1 KB · Aufrufe: 18
  • Screenshot 2026-02-25 145049.png
    Screenshot 2026-02-25 145049.png
    6,5 KB · Aufrufe: 21
  • Screenshot 2026-02-25 145209.png
    Screenshot 2026-02-25 145209.png
    166,7 KB · Aufrufe: 20
  • Screenshot 2026-02-25 145446.png
    Screenshot 2026-02-25 145446.png
    21,1 KB · Aufrufe: 20
  • Screenshot 2026-02-25 145826.png
    Screenshot 2026-02-25 145826.png
    26,3 KB · Aufrufe: 28
  • Screenshot 2026-02-25 150500.png
    Screenshot 2026-02-25 150500.png
    20,3 KB · Aufrufe: 28
Zuletzt bearbeitet:
@Zeitmangel:
Kannst du das irgendwie mit Maxwell belegen?
Ein super Text der es eigentlich 100% korrekt wiedergibt. Theoretisch. Praktisch möchte sich das aber nicht gleich generell bestätigen was man am entsprechenden 1Gbit wie auch teils schon 2.5Gbit Equipment feststellen kann. Vor allem, aber eben nicht nur, bei den Clients. Wofür imho nicht ausschließlich die Baugruppen (auf beiden Seiten) verantwortlich sind welche den Link elektrisch am Leben halten, sondern wohlauch die dahinter, die es bedienen.
Ob das jetzt am möglichst tiefen Runterschalten des Rests und nur dem allernötigsten life support für den Link zusammenhängt oder an mehr, möchte ich jetzt nicht rumoraceln, aber so manches Test und Review gibt das eigentlich schon her. Den spürbaren Unterschied zwischen idle und load. Auch mal zwischen "damsl" und "heute" für eigentlich das gleiche. Das ist für mich dann diese gute HW ;) Ja 10Gb - grad über Kupfer halt - hat hierbei irgendwie einen schwierigeren Stand. Das stimmt schon.
 
Meine RTL8127 Karten sind in Budapest angekommen und somit noch gut 6h entfernt. Sobald sie da sind, jage ich mal 10GBit/s durch den Grandstream Switch :)
 
Auto natürlich :) Schauen wir mal ob es dieses Wochenende noch was wird.
 
So,


ist im Unraid-Server eingebaut und läuft. 2.5 Gbit/s zum Mikrotik RB5009 stehen schon einmal. Mal schauen, was der Idle-Verbrauch sagt.

EDIT:

Vorher laut ELV-Strommessgerät: ca. 28 W
Vorher laut Nous A1T: ca. 33 W
Nun mit 2,5 Gbit/s laut ELV-Strommessgerät: Schwankungen zwischen 33 und 36 W
Nun mit 2,5 Gbit/s laut Nous A1T: Schwakungen zwischen 38 und 41W

ASPM ist derzeit deaktiviert:

Code:
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8127 10GbE Controller (rev 07)
        LnkCap:    Port #0, Speed 16GT/s, Width x1, ASPM L0s L1, Exit Latency L0s unlimited, L1 <64us
        LnkCtl:    ASPM Disabled; RCB 64 bytes, LnkDisable- CommClk+

EDIT2:

Nun auch im Desktop unter Arch.
Code:
➜  ~ sudo lspci -nnvmm | egrep -A 6 -B 1 -i 'network|ethernet'
Slot:   04:00.0
Class:  Ethernet controller [0200]
Vendor: Realtek Semiconductor Co., Ltd. [10ec]
Device: RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet Controller [8168]
SVendor:        ASUSTeK Computer Inc. [1043]
SDevice:        Onboard RTL8111H Ethernet [8677]
Rev:    15
ProgIf: 00
IOMMUGroup:     15

Slot:   05:00.0
Class:  PCI bridge [0604]
--
Slot:   07:00.0
Class:  Ethernet controller [0200]
Vendor: Realtek Semiconductor Co., Ltd. [10ec]
Device: RTL8127 10GbE Controller [8127]
SVendor:        Realtek Semiconductor Co., Ltd. [10ec]
SDevice:        Device [0123]
Rev:    07
ProgIf: 00
 
Zuletzt bearbeitet:
Ein Script mit externen Dependencies das man regelmäßig ausführen muss? Hört sich gut an, wird gemacht :bigok:
 
Support kommt mit 26.04, was für April geplant ist. So lange kann ich warten. :)
 
automatisierte externe Dependencies? Noch besser :d
Ne ohne Spaß, denke das wird schon funktionieren aber ich will an meinem Produktivsystem keine Bastellösung, warte daher einfach noch bis die neue Version kommt.
 
Kenne mich mit scripten eh nicht aus :cautious:
Beitrag automatisch zusammengeführt:

1. Korrektur: SMB baut NICHT für jede Datei eine neue Verbindung auf​

Hier liegt der größte technische Irrtum in der Aussage:

  • Realität: SMB baut eine TCP-Sitzung zum Server auf (Standardport 445). Über diese eine Verbindung werden alle Befehle und Daten "gemultiplext". Es wäre für das Betriebssystem extrem ineffizient, für jede Datei einen neuen TCP-Handshake (SYN, SYN-ACK, ACK) durchzuführen.
  • Warum es sich so anfühlt: SMB ist ein Request-Response-Protokoll. Bei älteren SMB-Versionen oder schlechten Implementierungen wartet der Client oft auf eine Bestätigung ("Datei A erhalten"), bevor er den Befehl für "Datei B" schickt. Das erzeugt Pausen, die wie Verbindungsneuaufbaue wirken.

2. Der wahre Kern: "Stream" vs. "Chattiness"​

Deine Aussage trifft den Nagel auf den Kopf, wenn es um die Art der Kommunikation geht:

  • rsync (Der Streamer): rsync ist darauf optimiert, die Leitung wie einen Wasserschlauch zu nutzen. Sobald der TCP-Algorithmus (Congestion Control) das "Window" vergrößert hat, schiebt rsync die Daten am Stück durch. TCP CC kann hier perfekt arbeiten, weil der Datenstrom nicht abreißt.
  • SMB (Der Diskutierer): SMB muss für jede Datei Metadaten abfragen (Rechte, Zeitstempel, Größe). Bei vielen kleinen Dateien entstehen tausende winzige Pausen. Jedes Mal, wenn der Datenstrom kurz stockt, kann TCP CC nicht in den "High-Speed-Modus" schalten oder fällt sogar in den Slow Start zurück.
Gibts für Programme, die viele Index-Files übers Netzwerk lesen müssen, auch eine Lösung?
Hab noch nicht gemessen, aber im Vergleich zu lokalen Index-Files dauert das gefühlt 10 mal länger
 
Zuletzt bearbeitet:
Immer muss man alles selber machen....

Code:
/build/rtl8127/r8127.ko
Skipping BTF generation for /build/rtl8127/r8127.ko due to unavailability of vmlinux
make: Leaving directory '/kernel-headers'
--------------------------------------------------
SUCCESS: Driver compiled at /tmp/r8127_build/rtl8127/r8127.ko
--------------------------------------------------
Module info (vermagic etc.):
filename:       /tmp/r8127_build/rtl8127/r8127.ko
version:        11.015.00-NAPI
description:    Realtek r8127 Ethernet controller driver
vermagic:       6.12.33-production+truenas SMP preempt mod_unload modversions
Loading new module...
Verifying module + interface binding...
Recent kernel messages containing 'r8127':
[13735.123325] r8127 Ethernet controller driver 11.015.00-NAPI loaded
[13735.136827] r8127: This product is covered by one or more of the following patents: US6,570,884, US6,115,776, and US6,327,625.
[13735.136924] r8127  Copyright (C) 2025 Realtek NIC soft
NOTE: Don't forget to copy /tmp/r8127_build/rtl8127/r8127.ko to your persistent storage, and to automate loading e.g. with a Post Init script in TrueNAS UI.
Code:
IPERF3 -P20 Win 10 ioT
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-10.01  sec   346 MBytes   290 Mbits/sec                  sender
[  5]   0.00-10.03  sec   346 MBytes   290 Mbits/sec                  receiver
[  7]   0.00-10.01  sec   755 MBytes   632 Mbits/sec                  sender
[  7]   0.00-10.03  sec   754 MBytes   631 Mbits/sec                  receiver
[  9]   0.00-10.01  sec   631 MBytes   529 Mbits/sec                  sender
[  9]   0.00-10.03  sec   630 MBytes   527 Mbits/sec                  receiver
[ 11]   0.00-10.01  sec   479 MBytes   402 Mbits/sec                  sender
[ 11]   0.00-10.03  sec   479 MBytes   401 Mbits/sec                  receiver
[ 13]   0.00-10.01  sec  1.43 GBytes  1.23 Gbits/sec                  sender
[ 13]   0.00-10.03  sec  1.43 GBytes  1.23 Gbits/sec                  receiver
[ 15]   0.00-10.01  sec   455 MBytes   381 Mbits/sec                  sender
[ 15]   0.00-10.03  sec   451 MBytes   377 Mbits/sec                  receiver
[ 17]   0.00-10.01  sec   456 MBytes   382 Mbits/sec                  sender
[ 17]   0.00-10.03  sec   456 MBytes   382 Mbits/sec                  receiver
[ 19]   0.00-10.01  sec   737 MBytes   618 Mbits/sec                  sender
[ 19]   0.00-10.03  sec   730 MBytes   610 Mbits/sec                  receiver
[ 21]   0.00-10.01  sec   582 MBytes   487 Mbits/sec                  sender
[ 21]   0.00-10.03  sec   582 MBytes   486 Mbits/sec                  receiver
[ 23]   0.00-10.01  sec   497 MBytes   417 Mbits/sec                  sender
[ 23]   0.00-10.03  sec   496 MBytes   415 Mbits/sec                  receiver
[ 25]   0.00-10.01  sec   423 MBytes   354 Mbits/sec                  sender
[ 25]   0.00-10.03  sec   423 MBytes   354 Mbits/sec                  receiver
[ 27]   0.00-10.01  sec   184 MBytes   154 Mbits/sec                  sender
[ 27]   0.00-10.03  sec   184 MBytes   154 Mbits/sec                  receiver
[ 29]   0.00-10.01  sec   341 MBytes   285 Mbits/sec                  sender
[ 29]   0.00-10.03  sec   340 MBytes   285 Mbits/sec                  receiver
[ 31]   0.00-10.01  sec   324 MBytes   271 Mbits/sec                  sender
[ 31]   0.00-10.03  sec   324 MBytes   271 Mbits/sec                  receiver
[ 33]   0.00-10.01  sec   612 MBytes   513 Mbits/sec                  sender
[ 33]   0.00-10.03  sec   609 MBytes   509 Mbits/sec                  receiver
[ 35]   0.00-10.01  sec   279 MBytes   234 Mbits/sec                  sender
[ 35]   0.00-10.03  sec   278 MBytes   233 Mbits/sec                  receiver
[ 37]   0.00-10.01  sec  1.03 GBytes   881 Mbits/sec                  sender
[ 37]   0.00-10.03  sec  1.02 GBytes   877 Mbits/sec                  receiver
[ 39]   0.00-10.01  sec   372 MBytes   312 Mbits/sec                  sender
[ 39]   0.00-10.03  sec   371 MBytes   310 Mbits/sec                  receiver
[ 41]   0.00-10.01  sec   291 MBytes   244 Mbits/sec                  sender
[ 41]   0.00-10.03  sec   291 MBytes   243 Mbits/sec                  receiver
[ 43]   0.00-10.01  sec  1.02 GBytes   872 Mbits/sec                  sender
[ 43]   0.00-10.03  sec  1.02 GBytes   870 Mbits/sec                  receiver
[SUM]   0.00-10.01  sec  11.1 GBytes  9.49 Gbits/sec                  sender
[SUM]   0.00-10.03  sec  11.0 GBytes  9.45 Gbits/sec                  receiver

iperf Done.



Und ich WÜRDE jetzt mal so sagen die Karte macht das System schon ein wenig effizienter....
1772376809942.png


Beinahe 0 Mehrverbrauch!
Hab mal alle Apps deaktiviert und auch Container/VM (HomeAssistant) das System braucht dann noch rund 36W
AMD 5600 +65GB Ram mit 2TB SSD, 256gb BootSSD und 3x6TB+1x20TB HDDs (Im Sleep/Spindown Leve 1)
Wo vorher noch rund 68W Normal waren, hab ich nach Ausbauen der Melanox Connect X3 und starten aller apps/services iwo um die 55W rum gehabt, mit PowerTop --Auto-Tune.
Jetzt nach einbauen der RTL8127 ist dieser Wert recht gleich geblieben.

Unter iPerf3 vollast steigt der Verbrauch auf 77W
 

Anhänge

  • IMG_20260301_102324.jpg
    IMG_20260301_102324.jpg
    1,5 MB · Aufrufe: 10
  • IMG_20260301_102357.jpg
    IMG_20260301_102357.jpg
    1,5 MB · Aufrufe: 11
  • IMG_20260301_112536.jpg
    IMG_20260301_112536.jpg
    982,8 KB · Aufrufe: 11
Zuletzt bearbeitet:
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh