Hallo ihr alle.
Ich benutze für meinen tägliche Arbeit Linux - Manjaro Gnome und Ubuntu Gnome.
Manchmal bei der täglichen Arbeit fängt mein Rechner an - langsam Tastatureingaben anzunehmen. Das äußert sich so, dass ich tippe und die Eingabe in einer solchen Situation ein bis zwei Sekunden benötigt, bis der Rechner auf die Eingabe reagiert.
- Besonders häufig passiert das beim Hedgewars spielen aber auch - beim Text tippen im vim.
Jetzt zu meiner Frage: Wo könnte ich anfangen nach der Ursache zu suchen. Wenn ich das sudo journalctl durchsuche fällt mir kein Fehler (rot) auf.
Viele Grüße und einen schönen zweiten Advent, Frank.
Das könnte unbeabsichtigt an der verwendeten Hardware liegen: Bei mir hängen die Receiver von WLAN-Tastatur und -Maus an einem USB-Hub. Hängt an diesem USB-Hub zusätzlich ein USB-Stick, reagiert die Kiste sehr langsam auf Eingaben. Warum das so ist? Keine Ahnung.
Jakob
Am 08.12.19 um 17:55 schrieb dark-mlist@t-online.de:
Hallo ihr alle.
Ich benutze für meinen tägliche Arbeit Linux - Manjaro Gnome und Ubuntu Gnome.
Manchmal bei der täglichen Arbeit fängt mein Rechner an - langsam Tastatureingaben anzunehmen. Das äußert sich so, dass ich tippe und die Eingabe in einer solchen Situation ein bis zwei Sekunden benötigt, bis der Rechner auf die Eingabe reagiert.
- Besonders häufig passiert das beim Hedgewars spielen aber auch
- beim Text tippen im vim.
Jetzt zu meiner Frage: Wo könnte ich anfangen nach der Ursache zu suchen. Wenn ich das sudo journalctl durchsuche fällt mir kein Fehler (rot) auf.
Viele Grüße und einen schönen zweiten Advent, Frank.
On Monday, 9 December 2019 18:17:55 CET jm.2009@web.de wrote:
Das könnte unbeabsichtigt an der verwendeten Hardware liegen: Bei mir hängen die Receiver von WLAN-Tastatur und -Maus an einem USB-Hub.
Du meinst sicherlich Wireless-Tastatur/-Maus. Meines Wissens gibt es keine Eingabegeräte die direkt über LAN oder WLAN kommunizieren. ;-)
Hängt an diesem USB-Hub zusätzlich ein USB-Stick, reagiert die Kiste sehr langsam auf Eingaben. Warum das so ist? Keine Ahnung.
Ganz einfach: der Stick hat höhere Prio und mehr Daten zu transportieren.
Auf USB (1.x und 2.x) gibt es ein paar unterschiedliche Transfertypen - "control", "interrupt", "bulk", "isochronous".
Control benutzt USB um einfache Kommandos und Kurzinfos zu transportieren - z.B. "Identifiziere alle Geräte", "Führe Reset durch", "Gib mir Deine Typbeschreibung", ...
Interrupt wird für sehr kleine Datenmengen (wenige Bytes) benutzt, z.B. von Tastaturen und Mäusen um ihre Eingaben zu übermitteln.
Control und Interrupt werden auf dem Gerät in einen Puffer geladen und müssen dann warten bis der Host vorbeikommt und die Daten abholt. (Ja, der Name Interrupt is irreführend.) Die Transferrate ist unterirdisch, aber für einfache Geräte genug.
Bulk wird von Massenspeichern und anderen Geräten benutzt, die große Datenmengen ohne Verluste transportieren müssen. Dafür wird per Interrupt eine Zeitscheibe auf dem Bus angefordert, der Host gibt den Transfer frei und dann kann das Gerät eine Zeit lang den Bus blockieren.
Isochronous wird von Multimediageräten (Kamera, Microfon) benutzt. Es funktioniert wie Bulk, aber wenn der Host nicht genug Kapazität zur Verfügung stellt werden die Daten einfach verworfen weil sie sowieso zu alt sind.
Dein Massenspeicher fordert also exzessive Bulk-Transfers an und blockiert damit effektiv den Bus, während Deine Tastatur nicht rechtzeitig an ihre Interrupt-Transfers kommt.
Alternativ stört der Stick den Bus auf elektrischem Niveau oder der Hub bricht regelmäßig zusammen weil er nicht genug Strom für alle Geräte hat.
Maßnahmen:
Hub mit eigener Spannung versorgen (falls er ein Netzteil hat).
Tastatur und Stick tauschen - falls der Hub schlecht programmiert ist behandelt er bestimmte Ports mit höherer Prio als andere.
Tastatur nicht an den Hub, sondern in einen anderen (weit entfernten) Port direkt am Rechner stecken. Die USB-Chips im Rechner arbeiten unabhängig voneinander, aber jeder USB-Bus kann immer nur ein Gerät gleichzeitig bedienen. Meistens bedient ein Chip 1-4 Ports die direkt nebeneinander liegen, sind Ports physisch weit voneinander angelötet, dann sind sie vermutlich auch an unterschiedliche Chips angeschlossen und blockieren sich damit nicht gegenseitig. Umgekehrt sind Ports physisch am Rechner dicht beisammen (und vom selben Typ(*)) dann werden sie vermutlich auch vom selben Chip auf dem selben Bus bedient.
(*) USB 2.x Ports sind meistens schwarz, USB 3 Ports sind blau oder haben USB- C Stecker. Das sind in (fast) jedem Fall unterschiedliche Chips und unterschiedliche Busse.
viel Glück! Konrad
PS: versuch nicht die USB-Spec zu lesen! Die Schmerzen sind kaum zu ertragen... ;-)
Hallo Konrad,
Am 10.12.19 um 16:01 schrieb Konrad Rosenbaum:
On Monday, 9 December 2019 18:17:55 CET jm.2009@web.de wrote:
Das könnte unbeabsichtigt an der verwendeten Hardware liegen: Bei mir hängen die Receiver von WLAN-Tastatur und -Maus an einem USB-Hub.
Du meinst sicherlich Wireless-Tastatur/-Maus. Meines Wissens gibt es keine Eingabegeräte die direkt über LAN oder WLAN kommunizieren. ;-)
Da hast Du gewiß recht. Ich meinte "Funktastatur" und "Funkmaus" ... und (auch auf die Gefahr, mich zu blamieren) funken die nicht auch auf 2.4 GHz?
Hängt an diesem USB-Hub zusätzlich ein USB-Stick, reagiert die Kiste sehr langsam auf Eingaben. Warum das so ist? Keine Ahnung.
Ganz einfach: der Stick hat höhere Prio und mehr Daten zu transportieren.
Das klingt logisch. Allerdings reagiert die Kiste auch dann sehr langsam auf Eingaben per Funktastatur und -maus, wenn der USB-Stick einfach nur am USB-Hub hängt und keinerlei Daten von bzw. zu ihm transferiert werden – selbst dann, wenn der Stick schon länger ohne Datentransfers dort hängt. (Siehe auch unten bei meiner nächsten Frage.)
Auf USB (1.x und 2.x) gibt es ein paar unterschiedliche Transfertypen - "control", "interrupt", "bulk", "isochronous".
Control benutzt USB um einfache Kommandos und Kurzinfos zu transportieren - z.B. "Identifiziere alle Geräte", "Führe Reset durch", "Gib mir Deine Typbeschreibung", ...
Interrupt wird für sehr kleine Datenmengen (wenige Bytes) benutzt, z.B. von Tastaturen und Mäusen um ihre Eingaben zu übermitteln.
Control und Interrupt werden auf dem Gerät in einen Puffer geladen und müssen dann warten bis der Host vorbeikommt und die Daten abholt. (Ja, der Name Interrupt is irreführend.) Die Transferrate ist unterirdisch, aber für einfache Geräte genug.
Bulk wird von Massenspeichern und anderen Geräten benutzt, die große Datenmengen ohne Verluste transportieren müssen. Dafür wird per Interrupt eine Zeitscheibe auf dem Bus angefordert, der Host gibt den Transfer frei und dann kann das Gerät eine Zeit lang den Bus blockieren.
Das klingt, also ob "Bulk" auch ohne Datentransfer, also prophylaktisch angefordert wird. Ist das so?
Isochronous wird von Multimediageräten (Kamera, Microfon) benutzt. Es funktioniert wie Bulk, aber wenn der Host nicht genug Kapazität zur Verfügung stellt werden die Daten einfach verworfen weil sie sowieso zu alt sind.
Dein Massenspeicher fordert also exzessive Bulk-Transfers an und blockiert damit effektiv den Bus, während Deine Tastatur nicht rechtzeitig an ihre Interrupt-Transfers kommt.
Alternativ stört der Stick den Bus auf elektrischem Niveau oder der Hub bricht regelmäßig zusammen weil er nicht genug Strom für alle Geräte hat.
Maßnahmen:
Hub mit eigener Spannung versorgen (falls er ein Netzteil hat).
Tastatur und Stick tauschen - falls der Hub schlecht programmiert ist behandelt er bestimmte Ports mit höherer Prio als andere.
Tastatur nicht an den Hub, sondern in einen anderen (weit entfernten) Port direkt am Rechner stecken. Die USB-Chips im Rechner arbeiten unabhängig voneinander, aber jeder USB-Bus kann immer nur ein Gerät gleichzeitig bedienen. Meistens bedient ein Chip 1-4 Ports die direkt nebeneinander liegen, sind Ports physisch weit voneinander angelötet, dann sind sie vermutlich auch an unterschiedliche Chips angeschlossen und blockieren sich damit nicht gegenseitig. Umgekehrt sind Ports physisch am Rechner dicht beisammen (und vom selben Typ(*)) dann werden sie vermutlich auch vom selben Chip auf dem selben Bus bedient.
(*) USB 2.x Ports sind meistens schwarz, USB 3 Ports sind blau oder haben USB- C Stecker. Das sind in (fast) jedem Fall unterschiedliche Chips und unterschiedliche Busse.
viel Glück! Konrad
PS: versuch nicht die USB-Spec zu lesen! Die Schmerzen sind kaum zu ertragen... ;-)
Vielen Dank für Deine detaillierten Hinweise! Jakob
Hi,
On Tuesday, 10 December 2019 22:43:40 CET Dr. Jakob Mendel wrote:
Am 10.12.19 um 16:01 schrieb Konrad Rosenbaum:
Du meinst sicherlich Wireless-Tastatur/-Maus. Meines Wissens gibt es keine Eingabegeräte die direkt über LAN oder WLAN kommunizieren. ;-)
Da hast Du gewiß recht. Ich meinte "Funktastatur" und "Funkmaus" ... und (auch auf die Gefahr, mich zu blamieren) funken die nicht auch auf 2.4 GHz?
Im Bereich um 2.4GHz und 5GHz befinden sich Frequenzbänder, die weltweit "unreguliert" sind - d.h. jeder darf sie verwenden solange er sich an ein paar einfache Regeln hält (z.B. maximale Sendeleistung). Das Protokoll ist nicht vorgegeben.
Dort tummeln sich so unterschiedliche Gerätschaften wie WLAN, Bluetooth, ZigBee, proprietäre Mäuse/Tastaturen, Fernsteuerungen für komplexe Roboter oder Maschinen, Funkmikrofone, etc.pp. ...die moderneren Varianten haben immerhin eine Möglichkeit zu erkennen wenn jemand anderes den Kanal benutzt und dann auszuweichen.
[cut: USB Transfertypen]
Das klingt, also ob "Bulk" auch ohne Datentransfer, also prophylaktisch angefordert wird. Ist das so?
Nein. Zumindest nicht wenn das Gerät sich an die Standards hält. Ein Transfer hat im Allgemeinen einen Grund - entweder hat der Host Daten angefordert (Speichermedium) oder eine externe Quelle erzeugt live Daten, die übertragen werden müssen (z.B. Serial-Konverter).
Non-Standard erster Stufe ist es Prioritäten zu ignorieren und einfach die eigenen Transfers zu bevorzugen. Zweite Stufe ist es sinnlose Transfers zu erzeugen.
Konrad
Hallo Frank,
On Sun, Dec 08, 2019 at 17:55:32 +0100, dark-mlist@t-online.de wrote:
Ich benutze für meinen tägliche Arbeit Linux - Manjaro Gnome und Ubuntu Gnome.
Manchmal bei der täglichen Arbeit fängt mein Rechner an - langsam Tastatureingaben anzunehmen. Das äußert sich so, dass ich tippe und die Eingabe in einer solchen Situation ein bis zwei Sekunden benötigt, bis der Rechner auf die Eingabe reagiert.
- Besonders häufig passiert das beim Hedgewars spielen aber auch
- beim Text tippen im vim.
In der ersten Antwort wurde ja schon vermutet, dass die Eingabegeraete (Maus, Keyboard) gestoert werden koennten. Falls es ein Wireless Keyboard ist, ggf. mal ein kabelgebundenes Keyboard anschliessen. Aus Sicherheitssicht ist ein Wireless Keyboard ohnehin Mist.
Ansonsten waere im Fehlerfall die Ausgabe des Kommandos "dmesg" interessant. Auch ein Terminal mit "top" koennte man beobachten.
Gruss, Christian
Hallo ihr alle.
Danke für die vielen Antworten. Ich habe vergessen ein paar wichtige Informationen zu geben. Beide Linuxe sind auf einem Laptop installiert, Ubuntu auf einem HP zbook und Manjaro auf einem Lenovo X200. Das Phänomen tritt mit externer Tastatur im Dock, wie auch mit der im Laptop eingebauten Tastatur auf.
Wichtig ist auch noch: Das passiert nicht so häufig -- der sicherste Weg dahin ist aber Hedgewars zu spielen, ganz selten in vim an Code zu arbeiten.
Ich werde jetzt erst einmal die Ausgaben von dmesg ansehen und dann weiter fragen, wenn ich Hilfe brauche.
Viele Grüße und eine schöne Weihnachtszeit euch allen, Frank.
Hallo ihr alle.
Ich benutze für meinen tägliche Arbeit Linux - Manjaro Gnome und Ubuntu Gnome.
Manchmal bei der täglichen Arbeit fängt mein Rechner an - langsam Tastatureingaben anzunehmen. Das äußert sich so, dass ich tippe und die Eingabe in einer solchen Situation ein bis zwei Sekunden benötigt, bis der Rechner auf die Eingabe reagiert.
- Besonders häufig passiert das beim Hedgewars spielen aber auch
- beim Text tippen im vim.
Jetzt zu meiner Frage: Wo könnte ich anfangen nach der Ursache zu suchen. Wenn ich das sudo journalctl durchsuche fällt mir kein Fehler (rot) auf.
Viele Grüße und einen schönen zweiten Advent, Frank.
Hallo an euch alle.
Ich habe es heute noch einmal das Problem gehabt, dass mein Laptop sehr langsam auf Tastatureingaben reagiert hat.
Die Ausgabe von dmesg ist:
[10624.696316] wlo1: authenticate with 74:44:01:8d:9d:e4 [10624.702693] wlo1: send auth to 74:44:01:8d:9d:e4 (try 1/3) [10624.706781] wlo1: authenticated [10624.709594] wlo1: associate with 74:44:01:8d:9d:e4 (try 1/3) [10624.713582] wlo1: RX AssocResp from 74:44:01:8d:9d:e4 (capab=0x431 status=0 aid=7) [10624.718646] wlo1: associated [10624.738273] IPv6: ADDRCONF(NETDEV_CHANGE): wlo1: link becomes ready [10625.107909] e1000e: enp0s25 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx [10625.107949] IPv6: ADDRCONF(NETDEV_CHANGE): enp0s25: link becomes ready [10626.007026] rfkill: input handler disabled [10640.961260] radeon_dp_aux_transfer_native: 242 callbacks suppressed [11834.856800] perf: interrupt took too long (2535 > 2500), lowering kernel.perf_event_max_sample_rate to 78750 [13781.929262] radeon_dp_aux_transfer_native: 74 callbacks suppressed [13853.991279] perf: interrupt took too long (3303 > 3168), lowering kernel.perf_event_max_sample_rate to 60500 [15529.739025] perf: interrupt took too long (4183 > 4128), lowering kernel.perf_event_max_sample_rate to 47750 [16243.995219] usb 2-1.3.6: Weird data, len=5 20 c4 b2 46 18 00 ... [17023.671570] usb 2-1.3.6: Weird data, len=5 20 48 07 00 a7 00 ... [20393.959125] radeon_dp_aux_transfer_native: 32 callbacks suppressed [20416.729733] usb 2-1.3.6: Weird key 14 a0 30 00 [20835.921297] perf: interrupt took too long (5305 > 5228), lowering kernel.perf_event_max_sample_rate to 37500 [21254.144169] radeon_dp_aux_transfer_native: 32 callbacks suppressed
Kann mir jemand helfen?
Viele Grüße, Frank.
Ging nicht an die Liste bei der ersten Antwort, hast mal geschaut?
###########################
Hallo Frank,
würde spontan auf RAM-Engpässe tippen. Schau Dir mal "atop" an. Damit kannst Dir angucken, was die Kiste ressourcentechnisch denn gerade so treibt. Den kannst Dir auch als Daemon einrichten, der dann beispielsweise minütlich mitschneidet und Du rückwirkend forschen kannst.
Grüße,
Falk
On 12/11/19 8:23 PM, dark-mlist@t-online.de wrote:
Hallo an euch alle.
Ich habe es heute noch einmal das Problem gehabt, dass mein Laptop sehr langsam auf Tastatureingaben reagiert hat.
Die Ausgabe von dmesg ist:
[10624.696316] wlo1: authenticate with 74:44:01:8d:9d:e4 [10624.702693] wlo1: send auth to 74:44:01:8d:9d:e4 (try 1/3) [10624.706781] wlo1: authenticated [10624.709594] wlo1: associate with 74:44:01:8d:9d:e4 (try 1/3) [10624.713582] wlo1: RX AssocResp from 74:44:01:8d:9d:e4 (capab=0x431 status=0 aid=7) [10624.718646] wlo1: associated [10624.738273] IPv6: ADDRCONF(NETDEV_CHANGE): wlo1: link becomes ready [10625.107909] e1000e: enp0s25 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx [10625.107949] IPv6: ADDRCONF(NETDEV_CHANGE): enp0s25: link becomes ready [10626.007026] rfkill: input handler disabled [10640.961260] radeon_dp_aux_transfer_native: 242 callbacks suppressed [11834.856800] perf: interrupt took too long (2535 > 2500), lowering kernel.perf_event_max_sample_rate to 78750 [13781.929262] radeon_dp_aux_transfer_native: 74 callbacks suppressed [13853.991279] perf: interrupt took too long (3303 > 3168), lowering kernel.perf_event_max_sample_rate to 60500 [15529.739025] perf: interrupt took too long (4183 > 4128), lowering kernel.perf_event_max_sample_rate to 47750 [16243.995219] usb 2-1.3.6: Weird data, len=5 20 c4 b2 46 18 00 ... [17023.671570] usb 2-1.3.6: Weird data, len=5 20 48 07 00 a7 00 ... [20393.959125] radeon_dp_aux_transfer_native: 32 callbacks suppressed [20416.729733] usb 2-1.3.6: Weird key 14 a0 30 00 [20835.921297] perf: interrupt took too long (5305 > 5228), lowering kernel.perf_event_max_sample_rate to 37500 [21254.144169] radeon_dp_aux_transfer_native: 32 callbacks suppressed
Kann mir jemand helfen?
Viele Grüße, Frank.
Hi,
On Wednesday, 11 December 2019 20:23:48 CET dark-mlist@t-online.de wrote:
[16243.995219] usb 2-1.3.6: Weird data, len=5 20 c4 b2 46 18 00 ... [17023.671570] usb 2-1.3.6: Weird data, len=5 20 48 07 00 a7 00 ...
[20416.729733] usb 2-1.3.6: Weird key 14 a0 30 00
Wenn der Kernel schon etwas "weird" findet, dann hast Du da kaputte Hardware dran. Welches Gerät ist denn "usb 2-1.3.6"(*)? Wird es besser wenn Du dieses Gerät rausnimmst?
(*)lsusb ist Dein Freund
Ich lehne mich mal aus dem Fenster und tippe dass ab und zu auch ein "USB Bus Reset" auftaucht - das wäre dann das Zeichen dass der USB-Bus so durcheinander ist dass er sich neu initialisieren muss (alle Geräte abhängen, neu aushandeln -> dauert ein paar Sekunden).
Konrad
Hallo Konrad.
Ich habe alle Geräte ausgehangen (USB Geräte abgezogen von der Docking Station) und habe jetzt keine weird key Warnungen mehr.
Die Verzögerung wird schlimmer und besser spontan. Auch wenn ich die beiden Laptops nicht im Dock sondern normal mit Netzteil versorge bleibt das Problem erhalten.
Ich denke: es liegt nicht am USB.
Am schlimmsten ist es, wenn youtube im Browser läuft und dann noch etwas anderes daneben. - In vim lässt es sich dann bei fullHD Videos deutlich spüren und - bei Hedgewars neben Youtube wird es extrem bis zu 3 Sekunden Verzögerung.
Kann mir einer einen Tipp geben, worauf ich bei atop achten muss?
Viele Grüße und schönen Abend, Frank.
On Fri, 13 Dec 2019 13:53:51 +0100 Konrad Rosenbaum konrad@silmor.de wrote:
Hi,
On Wednesday, 11 December 2019 20:23:48 CET dark-mlist@t-online.de wrote:
[16243.995219] usb 2-1.3.6: Weird data, len=5 20 c4 b2 46 18 00 ... [17023.671570] usb 2-1.3.6: Weird data, len=5 20 48 07 00 a7 00 ...
[20416.729733] usb 2-1.3.6: Weird key 14 a0 30 00
Wenn der Kernel schon etwas "weird" findet, dann hast Du da kaputte Hardware dran. Welches Gerät ist denn "usb 2-1.3.6"(*)? Wird es besser wenn Du dieses Gerät rausnimmst?
(*)lsusb ist Dein Freund
Ich lehne mich mal aus dem Fenster und tippe dass ab und zu auch ein "USB Bus Reset" auftaucht - das wäre dann das Zeichen dass der USB-Bus so durcheinander ist dass er sich neu initialisieren muss (alle Geräte abhängen, neu aushandeln -> dauert ein paar Sekunden).
Konrad
Moin,
man atop (-: Mach doch einfach mal ein Fenster mit z.B. "atop 3", starte Deine Spiele/Videos und gucke was so passiert, fängt da irgendwas an bunt zu leuchten? Wenn der RAM zuläuft und er anfängt im Swap zu rühren, erkennst Du das z.B. hier:
MEM | tot 7.5G | free 3.8G | cache 1.1G | dirty 2.2M | buff 93.4M | slab 146.1M | slrec 89.5M | shmem 266.0M | shrss 107.7M | vmbal 0.0M | hptot 0.0M | hpuse 0.0M | SWP | tot 4.0G | free 4.0G | | | | | | | | | vmcom 5.0G | vmlim 7.8G |
Taste m, dann p(zusammenfassen) --> Welche Prozesse verbrauchen welchen Speicher g CPU c Command Line usw....Manpage
Und fällt was auf, kommst so weiter? Kannst bei Unklarheiten auch gerne mal ne Ausgabe hier reinpasten.
Grüße, Falk
On 12/17/19 8:58 PM, dark-mlist@t-online.de wrote:
Hallo Konrad.
Ich habe alle Geräte ausgehangen (USB Geräte abgezogen von der Docking Station) und habe jetzt keine weird key Warnungen mehr.
Die Verzögerung wird schlimmer und besser spontan. Auch wenn ich die beiden Laptops nicht im Dock sondern normal mit Netzteil versorge bleibt das Problem erhalten.
Ich denke: es liegt nicht am USB.
Am schlimmsten ist es, wenn youtube im Browser läuft und dann noch etwas anderes daneben.
- In vim lässt es sich dann bei fullHD Videos deutlich spüren und
- bei Hedgewars neben Youtube wird es extrem bis zu 3 Sekunden Verzögerung.
Kann mir einer einen Tipp geben, worauf ich bei atop achten muss?
Viele Grüße und schönen Abend, Frank.
On Fri, 13 Dec 2019 13:53:51 +0100 Konrad Rosenbaum konrad@silmor.de wrote:
Hi,
On Wednesday, 11 December 2019 20:23:48 CET dark-mlist@t-online.de wrote:
[16243.995219] usb 2-1.3.6: Weird data, len=5 20 c4 b2 46 18 00 ... [17023.671570] usb 2-1.3.6: Weird data, len=5 20 48 07 00 a7 00 ...
[20416.729733] usb 2-1.3.6: Weird key 14 a0 30 00
Wenn der Kernel schon etwas "weird" findet, dann hast Du da kaputte Hardware dran. Welches Gerät ist denn "usb 2-1.3.6"(*)? Wird es besser wenn Du dieses Gerät rausnimmst?
(*)lsusb ist Dein Freund
Ich lehne mich mal aus dem Fenster und tippe dass ab und zu auch ein "USB Bus Reset" auftaucht - das wäre dann das Zeichen dass der USB-Bus so durcheinander ist dass er sich neu initialisieren muss (alle Geräte abhängen, neu aushandeln -> dauert ein paar Sekunden).
Konrad
Hallo,
On Wed, Dec 18, 2019 at 14:57:36 +0100, Falk Herzog wrote:
Wenn der RAM zuläuft und er anfängt im Swap zu rühren, erkennst Du das
Nach der letzten Beschreibung von Frank (Youtube im Browser mit fullHD) klingt es fuer mich eher danach, dass die CPU spontan den Takt senkt (Ueberhitzung?). Sind da evtl. Luefter defekt?
Wenigstens beim ThinkPad sollte man die Luefterdrehzahl ueber "cat /proc/acpi/ibm/fan" anzeigen koennen.
Gruss, Christian
Und ansonsten fuer alle: http://chris.silmor.de/ray/pix3/xmas-trio.jpg
Hallo Christian.
Danke für den Tipp. Die Idee hatte ich auch schon.
Auf beiden Laptops läuft der Lüfter einwandfrei. Selbst bei großem Stress (Simulationscode) läuft der Lüfter auf maximaler Leistung und beide Gehäuse werden nicht übermäßig heiß.
Ich verfolge mal den atop Ansatz weiter.
Viele Grüße und einen schönen vierten Advent, Frank.
On Wed, 18 Dec 2019 16:30:48 +0100 Christian Perle chris@linuxinfotag.de wrote:
Hallo,
On Wed, Dec 18, 2019 at 14:57:36 +0100, Falk Herzog wrote:
Wenn der RAM zuläuft und er anfängt im Swap zu rühren, erkennst Du das
Nach der letzten Beschreibung von Frank (Youtube im Browser mit fullHD) klingt es fuer mich eher danach, dass die CPU spontan den Takt senkt (Ueberhitzung?). Sind da evtl. Luefter defekt?
Wenigstens beim ThinkPad sollte man die Luefterdrehzahl ueber "cat /proc/acpi/ibm/fan" anzeigen koennen.
Gruss, Christian
Und ansonsten fuer alle: http://chris.silmor.de/ray/pix3/xmas-trio.jpg
Am 08.12.19 um 17:55 schrieb dark-mlist@t-online.de:
Hallo ihr alle.
Ich benutze für meinen tägliche Arbeit Linux - Manjaro Gnome und Ubuntu Gnome.
Manchmal bei der täglichen Arbeit fängt mein Rechner an - langsam Tastatureingaben anzunehmen. Das äußert sich so, dass ich tippe und die Eingabe in einer solchen Situation ein bis zwei Sekunden benötigt, bis der Rechner auf die Eingabe reagiert.
was bisher noch nicht gesagt wurde: THP.
Wir empfehlen im Umfeld von PostgreSQL generell, das abzuschalten. Aus unserer KB:
===
Issue
The system becomes totally unresponsive for a period of time. This may be caused by the operating system attempting to defragment huge memory pages. During this time the systems seems unresponsive and frozen, or the performance of the system (response times etc.) gets very erratic.
*Transparent Huge Pages* (THP) are enabled by default in Red Hat Enterprise Linux and CentOS 6 and 7 for all applications.
------------------------------------------------------------------------
Resolution
Disabling Transparent Huge Pages (THP)
The controls for THP are found in the sysfs (|/sys|) tree under |/sys/kernel/mm/transparent_hugepage| or |/sys/kernel/mm/redhat_transparent_hugepage|, depending on the distribution and version. In the following we describe the first of these.
The values for |/sys/kernel/mm/transparent_hugepage/enabled| can be one of the following:
* |always| - defragment every time huge pages are requested * |madvise| - defragment every time huge pages are requested with |madvise| * |never| - never defragment huge pages
To disable:
|echo never > /sys/kernel/mm/transparent_hugepage/enabled echo never > /sys/kernel/mm/transparent_hugepage/defrag # Depending on linux kernel version, you may need '0' instead of 'no' echo no > /sys/kernel/mm/transparent_hugepage/khugepaged/defrag |
Then, to prevent the changed values from being reset on server reboot you'll need to update the bootloader, typically grub:
On Red Hat based systems:
|grubby --update-kernel=ALL --args='transparent_hugepage=never' |
On Debian based systems (e.g. Ubuntu), edit |/etc/default/grub| by appending |transparent_hugepage=never| to the string set for |GRUB_CMDLINE_LINUX|. After saving the file, run |update-grub| to update the grub configuration.
Other Linux distributions (e.g. SUSE 11) have similar issues. They will need other means of making the changes permanent.
===
Das ist aus unserer KnowledgeBase, die eigentlich nur für zahlende Kunden zugänglich ist. Bitte nicht außerhalb dieser Liste weiter verbreiten.
lug-dd@mailman.schlittermann.de
-
Andreas Kretschmer -
Christian Perle -
dark-mlist＠t-online.de -
Dr. Jakob Mendel -
Falk Herzog -
jm.2009＠web.de
-
Konrad Rosenbaum -
Stefan Haselbrunn