Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) by gbr-app-1.alpinelinux.org (Postfix) with ESMTPS id 9B7B7225D34 for <~alpine/users@lists.alpinelinux.org>; Mon, 30 Sep 2024 20:27:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sdaoden.eu; s=citron; t=1727728049; x=1728394715; h=date:author:from:to:cc:subject: message-id:in-reply-to:references:mail-followup-to:openpgp:blahblahblah: author:from:subject:date:to:cc:resent-author:resent-date:resent-from: resent-sender:resent-to:resent-cc:resent-reply-to:resent-message-id: in-reply-to:references:mime-version:content-type: content-transfer-encoding:content-disposition:content-id: content-description:message-id:mail-followup-to:openpgp:blahblahblah; bh=e5Uau7zUDrzqLTlTwffBDntEenvX+hHSeOo4XQywQH4=; b=YRGqw6RY78PJ3+Sio8s/gV+QlUUVqrJDRxwpNkSxKqjDx2mudNmUEMG6P/j2Yb5zB/cbejEj sKploKzOmgPXDR3xvu5J/8f+SIJ4uzaBGAIm3YkvdF3MZ0K8/MLb2UPyonuJFRug95ho4kzJ1V h+LU2ysn/ygu2UyH/HkqwYmMzbS0rtiLg4CuS2i40maO+DBjFWm1s6dEiwpgmX05JgmoaAMf4g sKK+1ow9K02vkIMX3MC5ivY7VFj8/YM1DUUqYFc4juZ4IYFmxJL5GRbsgH4KY+YfAIBoONK14s slJyW9XbiwfDJrTkkXs1PhLmloRTuoYR6janWPH0immm79Dw== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=sdaoden.eu; s=orange; t=1727728049; x=1728394715; h=date:author:from:to:cc:subject: message-id:in-reply-to:references:mail-followup-to:openpgp:blahblahblah: author:from:subject:date:to:cc:resent-author:resent-date:resent-from: resent-sender:resent-to:resent-cc:resent-reply-to:resent-message-id: in-reply-to:references:mime-version:content-type: content-transfer-encoding:content-disposition:content-id: content-description:message-id:mail-followup-to:openpgp:blahblahblah; bh=e5Uau7zUDrzqLTlTwffBDntEenvX+hHSeOo4XQywQH4=; b=/wQk3mlnEzK4scf6q1s9tczlNKWY6eMwYz/PxeAsv9R29KGL9L4akq+K/n8ICuLtGcVCa5m0 /xzINFW5/XUZAQ== Date: Mon, 30 Sep 2024 22:27:28 +0200 Author: Steffen Nurpmeso From: Steffen Nurpmeso To: Jerome Marc Cc: ~alpine/users@lists.alpinelinux.org Subject: Re: freeze / connection delay after idling for a while ? Message-ID: <20240930202728._Cgmke2m@steffen%sdaoden.eu> In-Reply-To: References: Mail-Followup-To: Jerome Marc , ~alpine/users@lists.alpinelinux.org User-Agent: s-nail v14.9.25-608-ge479530e8d OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. Jerome Marc wrote in : |I just installed Alpine 3.20.3 on a RPI 2 in diskless mode.(headless, |minimal installation) | |I noticed that if I let the device idling, I have a few seconds latency |when I try to connect the machine with SSH for example. Even when connected |I can have my SSH session frozen for a few seconds if I do nothing in the |terminal. |I notice the same when using a nodejs app (HTTP) therefore this is a |general thing (not just about SSH) | |I don't see anything weird in logs. Any idea ? Is that a power saving |feature ? It *could* be that cpupower-openrc is indeed the tools/power/cpupower of the linux kernel sources, it seems to be widely available (architecture-wise, on Alpine). If that is so, then running it should output stuff like #?0|kent:~# bin/cpupower.sh analyzing CPU 0: driver: intel_pstate CPUs which run at the same hardware frequency: 0 CPUs which need to have their frequency coordinated by software: 0 maximum transition latency: Cannot determine or is not supported. hardware limits: 400 MHz - 3.40 GHz available cpufreq governors: performance powersave current policy: frequency should be within 400 MHz and 3.40 GHz. The governor "powersave" may decide which speed to use within this range. current CPU frequency: Unable to call hardware current CPU frequency: 800 MHz (asserted by call to kernel) boost state support: Supported: yes Active: yes On the reserve laptop however the EFI(BIOS) "always" sets back cpupower, and we start with "powersave" governor and low frequency, and so the initial decrypting of the hard disk takes seeeeconds. I btw drive it via #!/bin/sh - #@ /root/bin/cpupower.sh # cpupower is in Linux src, tools/power/cpupower : ${HOSTNAME:=$(uname -n)} if [ -f /root/hosts/${HOSTNAME}/cpupower ]; then . /root/hosts/${HOSTNAME}/cpupower else logger -s -t /root/bin/cpupower.sh "MISS /root/hosts/${HOSTNAME}/cpupower" exit 1 fi if command -v cpupower >/dev/null 2>&1; then :; else logger -s -t /root/bin/cpupower.sh 'no cpupower tool' exit 1 fi if [ $# -gt 0 ]; then x= case $1 in lo) x=$lo;; med) x=$med;; hi) x=$hi;; default) x=$default;; 75) x=$x75;; *) echo >&2 'Synopsis: cpupower [lo|med|hi|default[|75]]';; esac [ -n "$x" ] && cpupower frequency-set -u $x fi cpupower frequency-info and that /root/hosts/$HOSTNAME/cpupower is (here) #@ /root/hosts/self/cpupower lo='400M -g powersave' med='1600M -g powersave' hi='3400M -g performance' default='3400M -g powersave' x75='2500M -g performance' (i use "hi" only for kernel and port builds). It makes "a hell of a difference". Other than that i have seen similar things because (a) the kernel's crng came up slowly (up to 30 minutes at times), but this *should* be a thing of the past (dunno Alpine 3.20, i always use [edge]), or because of WiFi chip powersafe stuff, i usually do that though, i use "iw dev $dev set power_save on": # iw dev wlp1s0 get power_save Power save: on Other than that i am out of ideas. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)