SMB-(Verständnis-)Problem

Vereinfacht: Je höher die SMB Version, desto mehr Last erzeugt das Ganze. Es sind mehr features enthalten welche je nach Umsetzung im OS und Anwendung für mehr Probleme / Weniger performance sorgen können.

Unser te36 hat das wirklich sehr ausführlich und sehr gut analysiert und auch ein paar Punkte herausgefunden wo man etwas optimieren kann. Kodi selbst ist im SMB Bereich leider auch scheinbar deutlich schlechter geworden.

Mit SMB2 bist du schon deutlich besser aufgestellt als SMB1. da habe ich keine Bedenken, nur Windows mag smb2 nicht mehr so richtig. Ohne SMB Signing fällst du auf die Nase, aber das betrifft nur "Server" die Windows haben, nicht clients.

schon mal probiert, die SMB mounts im windows machen, also auf laufwerksbuchstaben legen,und dann diese laufwerke in kodi einbinden. Und dann mal durchsatz ausprobieren.

Bei meinen Tests sah ich normalerweise keine signifikanten Unterschiede bei der Übertragungsrate zwischen SMB2 und SMB3, wenn sonst alles identisch war. SMB-Signing ist ja ein SMB2 Feature. Ob das genutzt wird oder nicht kann bei schwacher HW schon was ausmachen.

Hatte dein Windows-11 "vor ein paar Wochen" schon Update 24H2? Wenn ich mich recht entsinne, kamen damit die neuen Defaults zu SMB-Signing, was in manchen Konstellationen sehr auf die SMB-Performance schlug.

Auf der anderen Seite hatte mein Windows 11 Mini PC auch schon zuvor sehr schlecht SMB-Performance als Server und mit Windows SMB Servern, nicht aber mit Linux SMB-Servern (SMB3). War nie dahinter gekommen, woran es lag. Jedenfalls lag es nicht CPU-Ressourcen. Hatte das aber nicht ganz hartnäckig untersucht, da für meinen EInsatzzweck belanglos. MIt 24H2 war das überraschenderweise weg, nun bin ich bei den zu erwartenden ca. 110 MByte/s. Mein Mini-PC hat so ziemlich die schwächste HW, auf der Win11 läuft - N4000 CPU.

Mit Tiny11 kenne ich mich nicht aus. Hat aber doch sicherlich Resmon, Perfmon und Taskmanager? Hast du dir mal Auslastung angesehen, gerade im Vergleich wenn du SMB2 und SMB3 nutzt?

Falls es am SMB-Signing liegt - hier hatte eine Methode beschrieben, es auszuschalten: Fehler "Keine Ethernetverbindung" während Wiedergabe Nach meiner Erfahrung braucht es einen Reboot (gab aber hier im Forum auch schon widersprüchliche Aussage).

Auf meinem noch schwächeren 8 Jahre alten Linux Server bremst übrigens SMB-Signing gerade noch nicht signifikant, bringt aber hohe CPU-Auslastung.

Welche HW hast du?

Am Rande, ich empfehle keine Geschwindigkeitsangaben wie mb/s zu nutzen. Besser MByte/s oder Mbit/s - Abkürzungen (oft falsch verwendet ...) sind MB/s und Mb/s.

Ich habe hier auch noch was zu lesen bzgl. SMB Lese-/Schreibgeschwindigkeit unter Windows, vielleicht hilft es.

Windows 11 24H2: Lese-/Schreibgeschwindigkeit bei SMB extrem langsam?

[English]Ich stelle mal die Beobachtung eines Blog-Lesers zu Microsoft Windows 11 24H2 zur Diskussion. Diesem Leser ist aufgefallen, dass die Transferraten…

www.borncity.com

JoePeter1000 Die RPI Platte auf dem Windows System mappen. Dann unter Windows ausprobieren, wie schnell Du da einen Film auf eine lokale Platte am Windows PC kopieren kannst. Dann den Laufwerkbuchstaben dieser gemappten RPI Platte in Kodi unter windows einbinden, und nochmal das kopieren probieren aus dem kodi dateimanager.

Zitat von JoePeter1000

die hdd in windows ist in ntfs formatiert, die am rpi in ext4. ich denke mal, dass das umwandeln einiges an leistung nimmt.

Nein. So ist es schon sehr gut. SMB zeigt dem Client nicht die physikalische Formatierung der Festplatte, sondern halt ein SMB-API unabhängig davon. Der Client muss nicht etwa mehr arbeiten/wandeln, wenn sich das Format der Festplatte am Server ändert. Und für den Server ist das native Format des jeweiligen Server-Betriebssystems schon gut.

te36, es scheint deine Empfehlungen passen auf anderes Szenario - RPI als Server für SMB und Windows als Kodi Client. Ist bei JoePeter1000 aber gerade anders herum. Unabhängig davon zu deiner Idee, direkt auf OS Ebenen zu mappen. Nach meiner Erfahrung und nach meinen Tests macht das bei Windows absolut keinen Unterschied. Kodi nutzt da nicht seinen internen SMB Code ("smbclient", der unter Linux/Android/MacOS genutzt wird), sondern nutzt das normale Windows File API. In Windows ist SMB-Filezugriff für Nutzer (Programmierer) transparent implementiert, und Filezugriff wie \\Servername\Freigabename\Pfad\zur\Datei.ext funktionieren praktisch exakt identisch wie z:\Pfad\zur\Datei.ext oder c:\Pfad\zur\Datei.ext. Messungen meiner eigenen Tools (für Lasttests) wie auch unter Kodi zeigen keine Unterschiede. Man sieht übrigens bei Kodi unter Windows auch, dass Lowlevel-Konfig-Parameter fehlen, wie Protokoll-Version. Das wird unter Windows immer alles durch das OS gemacht. (Authentifizierung fällt allerdings zum normalen lokalen Filezugriff zusätzlich an). Soll aber nicht heißen, dass JoePeter deinen Vorschlag nicht ausprobieren soll. Meine Erwartungshaltung habe ich beschrieben ...

Die Windows-Freigabe unter LibreElec mit OS-Mitteln zu mounten, scheint mir da der bessere Test zu sein. Kenne mich aber nicht mit LibreElec aus - scheint ja in manchen Dinge per Default sehr restriktiv zu sein. Wenn /etc/fstab nicht geht - mount Kommando sollte es schon mitbringen, auch für CIFS?

JoePeter1000, das SMB-Signing ist im Home-LAN dann sicherheitstechnisch relevant, wenn man schon kompromittierte/nicht vertrauenswürdige Geräte hat, oder aus irgend einem Grunde nicht allen Zugreifenden vertrauen kann. In der Regel wird man das nicht leicht ausschließen können. Bis vor ca. 1 Jahr war es allerdings praktisch überall deaktiviert.

Zu 100% gibt deine Beschreibung nicht Aufschluss über die Ursachen. Denn 1.: wenn du schon vorher 24H2 gehabt hast, sollte auch da schon SMB-Signing aktiviert gewesen sein. 2.: Da SMB-Signing kein SMB3 Feature ist, sondern schon SMB2 Feature, verstehe ich die Abhängigkeit von der Protokoll-Version nicht. Ich habe es jetzt nicht explizit getestet, aber ich kann keine Einschränkung des SMB-Signings auf SMB3 finden. Oft sehe ich was wie "Signing für alle [...] Verbindungen". 3. Wenn du Signing ausschaltest, ist alles wieder schnell.

Das passt nicht ganz zusammen. Auch deine Angaben zur CPU-Auslastung (bei SMB3 *geringere* Auslastung auf beiden beteiligten Systemen) passen meiner Ansicht nach nicht dazu.

Zitat von JoePeter1000

der rpi schwankt beim kopieren unter smb2 so zwischen 30-50% cpu-last, windows zwischen 3-4% (so kenne ich das auch, bevor ich zu tiny11 gewechselt bin)
beim kopieren mit smb3-einstellungen wirken die systeme etwas entspannter. win geht seltener auf über 3%, der rpi schwankt nur noch zwischen 25-30% last.

Es ist mir unklar, ob dabei das SMB-Signing ausgeschaltet war oder nicht. Powershell Get-SMBServerConfiguration und Get-SMBClientConfiguration zeigen den Status zu SMB-Signing. Wie bereits erwähnt, nach Änderung besser rebooten. Ich meine sonst kann auch die Statusanzeige falsch sein.

Ein kein bisschen habe ich Mal in Tiny11 reingelesen. Bisschen suspekt ist es mir. Brauchst du das wirklich? Mein Mini-PC läuft mit normaler Win11 Pro Installation mit einer leicht vorzunehmenden genügsamen Konfig für meine Nutzung vollkommen problemlos und ohne Speicherprobleme und mit sehr geringer Auslastung mit 8 GB RAM - und du hast 16 GB.

buers Jo, so wie Du das beschrieben hast denke ich das auch. Habe es aber mit Windows Client seit Ewigkeiten nicht mehr verifiziert. Vor allem nicht mit den neueren SMB Versionen. Wie Du am Ende gesagt hast; probieren geht ueber studieren. Und vor allem eben auch direkt im OS kopieren messen, damit man die Problemstelle eingrenzen kann. Isses Kodi, isses OS. Wenn man das Problem im OS reproduzieren kann, dann kann man weitermachen mit einem dritten Rechner um einzugrenzen obs am server oder client liegt. Etc. pp.