Buster etwas langsam - neue Erkenntnisse

[halo44]

Guten Tag miteinander. Ich mache hier mal ein weiteres Thema zu Buster teilweise etwas langsam auf, weil mir inzwischen eine weitere massive Verzögerung bei meinem Buster aufgefallen ist.

Gelegentlich zeichne ich mp4-Videos auf meinem NAS auf und transportiere diese in ein Windows auf meinem Notebook. Dort schneide ich das Video und konvertiere es ins wmv-Format, weil mein betagtes TV-Gerät nur dieses Format verarbeiten kann.

Anschließend übertrage ich das wmv-Video aus Windows via WinSCP zu meinem Desktoprechner in Buster. Dieser hat ja die Geschwindigkeitsprobleme.

Während mir bisher nur dieses aufgefallen ist

... wenn ich im Dateimanager Dolphin einen Ordner mit vielen Dateien im Ansichtsmodus "Details" öffne, werden die Zeilen der Dateieinträge langsam von oben nach unten aufgebaut. Je nach Anzahl der Dateien bleibt dieser Vorgang sogar für Sekunden "hängen", bis weiter aufgebaut wird. In diesem Fall sind die Dateinamen, das Änderungsdatum, der Eigentümer und die Benutzergruppe bereits sichtbar. Lediglich die Größenangabe wird verzögert aufgebaut.

Verzögerungen treten auch beim Chrome-Browser auf, wenn ich bei mehreren Tabs von einem zum anderen wechsele oder einen der Tabs schliesse.

Gelegentlich werden die eingetippten Buchstaben bei Office-Dokumenten verzögert abgebildet.

muß ich jetzt feststellen, daß die Übertragung der Videos mit WinSCP extrem lange dauert. Während die Übertragung von 1,3 GB auf die Stretch-Installation in 2 Minuten erledigt ist, dauert dies zur Busterinstallation gut 20 Minuten. Auch die Übertragung zum NAS, welches mit Debian-Stretch läuft, dauert nur knapp 4 Minuten.

Könnte dies ein Netzwerkproblem sein? Ich arbeite allerdings in beiden Installationen nicht mit dem Netzwerk-Manager sondern mit systemd-networkd.

Vielleicht kann jemand mit dieser neuen Information Ideen zur Problemlösung beisteuern?

Gruss H.

P.S. Ergänzen muß ich noch, daß die im ersten Beitrag (siehe Zitat oben) erwähnten Verzögerungen auch bei einer einfachen Grundinstallation ohne weitere Anpassungen von Buster auftraten. Dort war allerdings noch der NetworkManager Standard.

[MSfree]

Könnte dies ein Netzwerkproblem sein? Ich arbeite allerdings in beiden Installationen nicht mit dem Netzwerk-Manager sondern mit systemd-networkd.

Netzwerk-Manager, systemd-networkd oder /etc/network/interfaces sind nur verschiedene Methoden, um das Netzwerk zu konfigurieren. Die Konfiguration findet nur einmalig statt und wenn erstmal konfiguriert, hat das überhaupt keinen Einfluß mehr auf die Geschwindigkeit des Netzes.

...muß ich jetzt feststellen, daß die Übertragung der Videos mit WinSCP extrem lange dauert.

SCP ist eine verschlüsselte Datenübertragung. Moderne CPUs haben dafür in Hardware gegossene Verschlüsselungsrechenwerke, damit geht es sehr schnell. Falls die Hardware nicht verwendet wird, geschieht die Verschlüsselung in Software, was entsprechend lahm ist. Einen ersten Hinweis darauf, ob die Verschlüsslung bei dir in Software passiert, kannst du bekommen, wenn du während der Datenübertagung in einem Terminal auf dem Linuxrechner top laufen läßt und schaust, wie hoch die CPU-Last von sshd ist. Liegt diese bei fast 100%, wird wahscheinlich Softwareverschlüsselung verwendet, wobei Buster eigentlich Hardware verwenden sollte, wenn es die CPU unterstützt.

Ein weiteres Problem kann der Netzwerktreiber sein. Viele GBit-Schnittstellen laufen besser und zuverlässiger, wenn man sie mit Firmware versorgt. Ob dein System versucht, nicht vorhandene Firmware zu laden, findest du mit dem Befehl

Code: Alles auswählen

dmesg | grep -i firmware

heraus.

[halo44]

... Einen ersten Hinweis darauf, ob die Verschlüsslung bei dir in Software passiert, kannst du bekommen, wenn du während der Datenübertagung in einem Terminal auf dem Linuxrechner top laufen läßt und schaust, wie hoch die CPU-Last von sshd ist ...

Ich hatte während der Übertragung htop laufen und sortiert (F6) sowohl die CPU- als auch Memory-Last beobachtet. Keine Auffälligkeiten. Ich glaube die Spitzen-CPU-Last lag mal bei 8%, wobei das keine Prozesse waren, die mir mit der Übertragung beschäftigt schienen. sshd ist mir nicht aufgefallen.

... Ein weiteres Problem kann der Netzwerktreiber sein. Viele GBit-Schnittstellen laufen besser und zuverlässiger, wenn man sie mit Firmware versorgt. Ob dein System versucht, nicht vorhandene Firmware zu laden, findest du mit dem Befehl

Code: Alles auswählen

dmesg | grep -i firmware

heraus.

Hier finde ich nur

Code: Alles auswählen

dmesg | grep -i firmware
[    3.550475] r8169 0000:01:00.0: firmware: direct-loading firmware rtl_nic/rtl8168g-2.fw
[    3.779470] radeon 0000:00:01.0: firmware: direct-loading firmware radeon/ARUBA_pfp.bin
[    3.781126] radeon 0000:00:01.0: firmware: direct-loading firmware radeon/ARUBA_me.bin
[    3.781784] radeon 0000:00:01.0: firmware: direct-loading firmware radeon/ARUBA_rlc.bin
[    3.783982] radeon 0000:00:01.0: firmware: direct-loading firmware radeon/TAHITI_uvd.bin
[    3.785062] radeon 0000:00:01.0: firmware: direct-loading firmware radeon/TAHITI_vce.bin
[    3.786073] [drm] Found VCE firmware/feedback version 50.0.1 / 17!

Gruss H.

[MSfree]

Ich hatte während der Übertragung htop laufen...Ich glaube die Spitzen-CPU-Last lag mal bei 8%

OK, dann liegt es nicht an einer ausgelasteten CPU.

Hier finde ich nur

Code: Alles auswählen

dmesg | grep -i firmware
[    3.550475] r8169 0000:01:00.0: firmware: direct-loading firmware rtl_nic/rtl8168g-2.fw

Die Firmware für deinen Netzwerkschnittstelle wird also auch geladen.

Wie hoch ist die CPU-Last auf deinem Windowsrechern beim Übertragen?

Um ein defektes Kabel auszuschliessen, solltest du noch die Linkspeed deiner Netzwerkschnittstelle auf dem Linuxrechner abfragen:

Code: Alles auswählen

cat /sys/class/net/*/speed 

[halo44]

Was ich mir nun garnicht erklären kann: transportiere ich die wmv-Datei auf dem Notebook von Windows auf die Debian-Buster-Installation auf dem Notebook und hole mir die Datei dann vom Desktoprechner (also dem Zielrechner) aus per scp, dann dauert die Übertragung auch nur 2 Minuten.

Das sieht ja nun wieder aus, als ob Buster "unschuldig" ist. Allerdings überträgt WinSCP ja auch schnell zum Stretch-Zielrechner - nur nicht zum Buster-Zielrechner.

Gruss H.

[halo44]

... Wie hoch ist die CPU-Last auf deinem Windowsrechern beim Übertragen? ...

Wüsste ich auf Anhieb nicht, wie ich das messen kann. Werde ich mal googlen.

Um ein defektes Kabel auszuschliessen, solltest du noch die Linkspeed deiner Netzwerkschnittstelle auf dem Linuxrechner abfragen:

Code: Alles auswählen

cat /sys/class/net/*/speed 

Hier erhalte ich

Code: Alles auswählen

cat /sys/class/net/*/speed
1000
cat: /sys/class/net/lo/speed: Das Argument ist ungültig

Gruss H.

[MSfree]

Wüsste ich auf Anhieb nicht, wie ich das messen kann. Werde ich mal googlen.

Im Windows <Strg><Alt><Del> drücken und dann Taskmanager auswählen.
Dort gibt es dann einen Prozeß-Reiter und einen Netzwerk-Reiter.

[halo44]

Danke, habe das mal gemessen und nun leider das Problem, daß inzwischen die Übertragung wieder mit normaler Geschwindigkeit erfolgt. Dabei zeigte sich die CPU-Last auf Windows mit Werten zwischen 20 und 22%.

Das Problem mit dem "müden" Transfer trat vorgestern erstmalig auf. Danach habe ich die Übertragung mehrfach durchgeführt. Zum Desktoprechner Buster und Stretch, zum NAS Stretch und zum Rechner meiner Frau mit Buster. Dabei liefen alle Übertragungen bis auf die zum Desktoprechner Buster mit gewohnter Geschwindigkeit. Die Geschwindigkeit war dabei bei 4-5 Versuchen zum Desktop Buster miserabel.

Ich bin ratlos, was die deutliche Verbesserung angeht. Die einzige Erklärung wäre vielleicht (?), daß nachdem ich die Datei vom Desktoprechner aus mit scp erfolgreich geholt habe (siehe meinen Post von 13:18:50) sich was auch immer im Netz geändert hat.

Gruss H.

[MSfree]

Danke, habe das mal gemessen und nun leider das Problem, daß inzwischen die Übertragung wieder mit normaler Geschwindigkeit erfolgt.

Windows checkt regelmässig auf Softwareupdates und Patches. Das lastet einen Windowsrechner für Stunden übermässig aus. Auch die meisten Virenscanner sind so eingerichtet, daß sie mindestens einmal die Woche die komplette Platte durchsuchen, was dann die Plattenzugriffe für andere Programme extrem verlangsamt. Möglicherweise ist er jetzt einfach fertig mit seinen Updates und arbeitet wieder flüssig.

[halo44]

Danke für diesen Hinweis - klingt plausibel.

Gruss H.