Zero W Ssh Reaktionszeit

  • Hallo,

    ich habe zwei Öffnungssysteme in Betrieb. Das eine läuft schon seit Ewigkeiten auf einem Pi 2b, das neuere auf eine Pi Zero W.

    Beide Systeme kann ich mit der App "SSh-Button" ansprechen (Python Script starten).

    Wenn ich beim Pi 2b den Button "Tür auf" drücke reagiert der innerhalb einer Sekunde. Bei dem Pi Zero können schon mal 4 bis 5 Sekunden vergehen bevor die Aktion startet.

    Beide hängen im gleichen Wlan und stehen jetzt nicht wirklich weit von einander entfernt.

    Woran könnte das mit der längeren Reaktionszeit beim Zero liegen? Wie kann ich es überprüfen? Und vor allem: kann man das beschleunigen?

    Werden sonst noch Infos benötigt?

    Nachtrag: Ich vergaß zu erwähnen, dass ich bereits den IPQoS Wert in der ssh- und sshd-config auf 0x00 fesetzt habe. Dieses Problem meine ich nicht.

    Einmal editiert, zuletzt von tdl (12. Mai 2021 um 17:31)

  • Zur hilfreichsten Antwort springen
  • Nur so ein Gedanke... Kann es sein, dass der Zero (evtl. durch eine Dauerschleife o.ä.) einigermaßen ausgelastet ist und deshalb etwas länger braucht als der RPi 2? Fällt Dir mit htop dazu etwas auf?

    Jepp, da könnte was sein. Ich hab da so ein Script, das im Hintergrund in einer Schleife läuft.

    Ich kann mich jett auch erinnern, dass ich auch auf dem alten System so ein Problem hatte.

    Ich habe jetzt ein Sleep(1) ans Ende der Schleife gehängt, das scheint aber nicht richtig zu sein, da es keine Auswirkung auf die Auslastung hat. Kannst du mir bitte sagen wo ich das sleep oder time.sleep setzen muss?

  • Ich komme nicht weiter.

    hab es auch mit

    Python
    from time import sleep
    und
    time.sleep(10)

    versucht. 10, damit ich wenn es denn funktionieren würde auch einen Unterschied sehe. Wobei ich das time.sleep an den verschiedensten Stellen im Script ausprobiert habe. Mal mit Fehlermeldungen mal ohne, aber alles ohne Auswirkung auf die Auslastung.

    Meinen Verständnis nach war mein erster Versuch oben auch von der Logik falsch. Die Unterbrechung soll ja nicht erst nach dem Lesen einer Karte stattfinden, sondern mit jedem Zyklus in dem geprüft wird ob überhaupt eine Karte zum lesen da ist. Das Time.sleep müsste also nach meinem Verständnis irgendwo nach dem "try" und vor dem "if" stehen.

    Das scheint so aber nicht zu funktionieren. Mache ich da was grundlegendes falsch? Funktioniert das bei diesem Script überhaupt mit sleep oder gibt es da auch noch andere Möglichkeiten?

    • Offizieller Beitrag

    Ich drücke es mal so aus. Ein ausgeworfener oder nichtausgeworfener Fehler ist manchmal hilfreich. Das könnte Dir zeigen welche Zeile des Skripts bei welcher Gelegenheit erreicht wird (oder nicht). Das sleep() gehört in jedem Fall in diese Ebene in der es jetzt auch ist. Eigentlich spielt es keine Rolle an welcher Stelle der Schleife. Es macht nur keinen Sinn beim ersten Durchlauf erst zu warten, bevor der Code abgearbeitet wird, deshalb ans Ende der Schleife.

    subprocess.Popen("/PFAD zum Script")

    Was macht dieses Skript eigentlich? Ist es jenes, das die Tür öffnet?

  • Was macht dieses Skript eigentlich? Ist es jenes, das die Tür öffnet?

    Ja genau, den Pfad hätte ich eigentlich nicht unkenntlich machen müssen, bisschen übereifrig im Datenschutz :) .


    Ein ausgeworfener oder nichtausgeworfener Fehler ist manchmal hilfreich.

    Die Fehler waren wegen falscher Einrückungen bzw. Schreibweisen. Ich hab halt alles mal durchprobiert.

    Bin jetzt auch schon mal ein Stück weiter. Ich hab das sleep direkt unter das while true gesetzt. Mit 10 Sekunden. Und dann auch mal den Chip drangehalten. Es wurde tatsächlich nur alle 10 Sekunden gelesen. Aber leider hat das nichts an der Auslastung geändert. Bei htop wird die CPU Auslastung für dieses Script mit ~75% angegeben. Ich hab mal einen Screenshot angehängt, ist direkt der erste oben.

    .

    Nachtrag: Hab eine Diskussion auf Github gefunden, dass es wohl ein generelles Problem mit dem MFRC522 und der CPU Last gibt. Weiter wird zu einer speziellen PiRC522 zu der es auch schon hier im Forum einen Beitrag gab.hier

    Wenn ich das richtig verstehe, ist es gut möglich, dass es gar nicht an dem Script liegt sondern an dem reader den es importiert. Sehe ich das richtig?

    Einmal editiert, zuletzt von tdl (12. Mai 2021 um 21:08) aus folgendem Grund: weitere Infos gefunden

    • Hilfreichste Antwort
    • Offizieller Beitrag

    Wow 100%! =O

    Ah ja in SimpleMFRC522 rennen auch ungebremste Schleifen (u.a. diese vermutlich hier verantwortliche https://github.com/pimylifeup/MFR…eMFRC522.py#L16).

    Ich habe weder einen solchen Reader, noch das Modul installiert. Deshalb wirst Du das selber suchen und zum Test ein kleines time.sleep(0.1) einbauen müssen. ;)

  • Also: Habe jetzt in der Schleife ab Zeile 16 (die du mir freundlicherweise markiertest) vor dem return ein sleep(0.1) gesetzt. Das hat die Last auf knapp über 80% gesenkt. *freu* 0.2 und 0.3 bringen keine weitere Veränderung.

    Hab dann auch bei den anderen Schleifen sleeps gesetzt, die bringen aber leider keinen weiteren Erfolg.

    Ich mach dann heute auch erst mal Schluss. Muss mich da morgen erst mal überall reinlesen. Mal sehen ob ich weiterkomme.

    Soweit aber schon mal Danke.

  • Ich habe versuchsweise mal pi-rc522 installiert. Dafür muss dann am RC522 auch der Pin "IRC" angeschlossen werden. Es läuft, die Prozessorlast bleibt normal, aber ich kann damit leider nichts anfangen. Hab die Beispieldateien dazu installiert, aber Pi-rc522 ist komplett anders aufgebaut und liest den Chip auch anders aus. Also nicht mit Text. Da blicke ich überhaupt nicht durch was der Code macht.

    Mir ist aber noch eine andere Lösung für mein Problem eingefallen. Die ist zwar überhaupt nicht schön, müsste aber die Prozessorauslastung wieder nach unten bringen: Das Script (von oben) ohne Schleife immer nur einmal durchlaufen lassen und am ende soll es sich beenden und selbst wieder neustarten. Das Ganze möglichst im Halb-Sekunden-Takt. Ich hab schonmal danach gegoogelt bekomme aber nur Ergebnisse, die den ganzen Rechner neustarten wollen.

    Deshalb meine Frage vorab: Ist sowas überhaupt möglich?

    • Offizieller Beitrag

    Mir ist aber noch eine andere Lösung für mein Problem eingefallen.

    Das macht meiner Meinung nach keinen Sinn.

    Du kannst mal in Deinem Skript alles zwischen while True: und dem sleep auskommentieren und dafür ein print("test") dahin setzen um zu sehen was die Prozessorlast dann macht. Dann die Imports (außer time) auch auskommentieren und nochmals mit htop nachsehen was passiert.

    Ein Zero hat ja leider nicht besonders viel an Ressourcen. Der RAM ist bei Dir ja auch voll, so das der (langsame) Swap schon genutzt wird. Die grafische Umgebung zieht dann auch noch einiges an RAM.

  • Du kannst mal in Deinem Skript alles zwischen while True: und dem sleep auskommentieren und dafür ein print("test") dahin setzen um zu sehen was die Prozessorlast dann macht. Dann die Imports (außer time) auch auskommentieren und nochmals mit htop nachsehen was passiert.

    alles zwischen true und sleep auskommentiert: Prozessorlast geht gegen null. Allerdings macht das Script dann auch nichts weiter als immer wieder Test schreiben.

    importe von GPIO und mfrc522 auskommentieren erzeugt Fehlermeldungen wenn der Rest nicht auskommentiert wird.

    subprocess auskommentiert, sowohl den import als auch die Zeile unten: Das Script liest im 1Sekunden Takt, obwohl nur eine halbe Sekunde im sleep gesetzt ist. Was mir hier aber aufgefallen ist: Solange auf einen Chip gewartet wird ist der Prozessor ausgelastet. Lege ich den Chip auf das NFC-Board drauf, so dass er ständig ausgelesen wird, geschieht das w. o. beschrieben im Sekundentakt UND die Prozessorlast sinkt auf unter 50%. Solange der Chip drauf liegt. Nehme ich ihn weg schnellt sie sofort wieder nach oben.

    Ein Zero hat ja leider nicht besonders viel an Ressourcen. Der RAM ist bei Dir ja auch voll, so das der (langsame) Swap schon genutzt wird. Die grafische Umgebung zieht dann auch noch einiges an RAM.

    Das wollte ich wenn alles richtig läuft, wenn möglich, eh abschalten. Muss ich dann aber noch schauen wie das geht.

    • Offizieller Beitrag

    Ich fürchte, da kann man nicht mehr viel machen um die CPU-Last zu senken. Um nochmals nach dem eigentliche Problem zu fragen... Was ist jetzt mit SSH-Button? Ist die Reaktion jetzt besser als vorher?

    Muss ich dann aber noch schauen wie das geht.

    Geht ganz leicht unter sudo raspi-config > System Options > Boot / Auto Login ;)

  • "Wer nicht spielt gewinnt auch nicht" und ich hab hier mächtig rumgespielt.

    Erst mal vorweg ein Screenshot vom jetzigen Htop:

    Das SimpleMFRC522.py hat ja auch noch mal ein MFRC522 importiert. Zu dem hab ich auch noch was gefunden. Allerdings hat das mit dem sleep (time.sleep nimmt er nicht) an dieser Stelle nicht funktioniert. Ich habe es eine Zeile über dem break gesetzt.

    Jetzt liest er zwar schätzungsweise nur noch alle 1,5 - 2 Sekunden aus, Damit kann ich aber leben.

    Zusätzlich noch den grafischen Bildschirm wie von dir beschrieben deaktiviert. Das Ergebnis ist ausreichend.

    Was mich noch stört sind so Sachen die ich auf diesem Raspi gar nicht brauche die da aber standardmäßig zu laufen scheinen. Sowas wie Pulseaudio, CUPS usw. Aber das kann ich ja dann auch noch "im laufendn Betrieb" nach und nach abschalten. Wenn du Tipps hast nehme ich die gerne an.

    Um nochmals nach dem eigentliche Problem zu fragen... Was ist jetzt mit SSH-Button? Ist die Reaktion jetzt besser als vorher?

    Soo, nun zu meinem eigentlichen Problem, der zu langen Reaktionszeit bei SSH-Button. Die hat sich jetzt merklich verbessert. Lag also tatsächlich an der Auslastung.

    Und ich hab wieder jede Menge gelernt.

    Ich danke dir und setze das Thema dann mal auf erledigt.

    • Offizieller Beitrag

    Wenn du Tipps hast nehme ich die gerne an.

    Ich habe einen wichtigen Tipp und den gleich drei mal: Backup, Backup, Backup! ;) Vielleicht machst Du das ja eh, aber daran kann man nie genug erinnern. Beim purgen von Paketen kann einfach zu viel schief gehen. Da reicht manchmal schon ein Fipptehler.

  • Ja, das ist eine gute Idee. Ich hab zwar Backups von meinen Scripten, aber mal die ganze Karte zu sichern könnt durchaus hilfreich sein.

    Das heisst noch mal ein Gehäuse drucken und diesmal nicht den Schlitz für die SD Karte vergessen. Den für USB habe ich nachträglich reingeschnitten, der sieht aber auch so aus :)

  • ps915 29. Januar 2024 um 18:48

    Hat das Label Zero W hinzugefügt.

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!