CliffB

If anyone is still following this then adding a command to rc.local isn't a complete fix. I left the unit running for 7 days without doing anything to it and power management has re-enabled itself again. This would explain why other distros have bodged in cron jobs to periodically disable power management. There must be some re-initialisation mechanism somewhere I presume.

Back at base now, I confirm that Igor's fix in rc.local works here also. armbianmonitor -u output without rc.local fix is at http://sprunge.us/TLVa

I did try this earlier on with the delay again without success and wondered if it was due to a delay in my network connection. However I will try again tomorrow when I'm back at base. Thanks for looking in any case and noted about a generic fix further down the line.

Tried that early on and no difference.

I stated the same early on in the thread and indeed I've already been doing that. The question is how to make the system default to power management off at start up.

Just for information I have tried all of the methods above including the service (in a slightly different form) apart from adding anything into modprobe.d. I was unable to determine the relevant module name and parameters. I am currently travelling but will post the output of armbianmonitor -u when I return on Tuesday,

Thanks for confirming this, not that it was really in much doubt. My pings swing more wildly up to a second or so probably due to the quality of my connection. Since I have a fix for the problem and along the line it will doubtless get properly sorted I'll focus on my application for the moment.

@zador.blood.stained I have tried many methods but the one with the reported results above was for pure vanilla NM configured using nmtui. For the record I have also tried disabling NM and setting up a traditional interfaces file with wireless-power off both with and without wireless-mode managed and it makes no difference, power management is always shown as enabled. I've tried adding various switches to /etc/NetworkManager/conf.d and a heap of other methods but whatever I try fails to disable power management at start up. Issuing iwconfig wlan0 power off from the command line fixes the problem instantly and iwconfig the reports that power management is off of course. @Bubba I don't believe this is about a noisy or occupied channel, the noise will and doubtless does affect the link of course but the AP is located 10 meters away and the OPi is running 32dBm which is over a Watt! Also after the iwconfig wlan0 power off has been run the ping response magically improves to sub 5ms and is steady and constant. The power management feature is simply disabling the device to save power. If I run a throughput test even with power management enabled I still achieve a reasonable rate (15Mbs) with speedtest-cli. It's just that the ping response becomes unusable for my application. Moving to a new channel may well be sensible with the increased number of WLANs in the area here but it's not the underlying cause. I would however be interested to see you test results for comparison to my OPi Zero H3 Plus 2 both with and without power management enabled. Thanks!

Hi Igor It was absolutely not my intention to put pressure on anyone, I appreciate all the effort you guys have made to get armbian where it is today. So my apologies if that was the impression given. Also I would not adopt DietPi for my purposes due to all the extra 'froth' involved with the distro. My comment was an observation that it did not default to power management being on. Understand that my purposes rely on a stable OS but naturally my thoughts are more trying to program my solution rather than spending time on the OS. None of this is in anyway your problem of course. I thank you graciously for your help and commentary above, all points are noted. It'll all come out in the wash I'm sure. My kids are all grown up, a disadvantage of age I suppose. Or then again maybe it's an advantage

Yup I did find that in the end. However running systool -a -v -m brcmfmac tells me 'Error opening module brcmfmac' On another note DietPi does appear to boot with power management off. Even after changing the setting in interfaces power management remains off. I have tried explicitly enabling it but I'm not after that anyway. I thought that DietPi was based on Armbian so maybe they are some steps behind with an older version? I'd rather use armbian but my time is becoming limited at this point.

I've no idea where to find the module name or parameters I'm afraid. lsmod doesn't yield sufficient information. Any pointers where to look?

Other than adding a cron job to periodically disable the power management I've not found any solution to disable power at boot. Adding a script containing iwconfig wlan0 power off to all the usual places including /etc/network/ifup.d /etc/NetworkManager/dispatcher.d and so on steadfastly does not disable the power management. I have even tried disabling power as the wpa-supplicant configs are processed. I presume that power management can be disabled either at the start of the process (if the driver disables it) or at the very end when the interface is configured, up and connected. What else should I be looking at at this point?

For the record setting 'wifi.powersave = 2' in '/etc/NetworkManager/conf.d/default-wifi-powersave-on.conf' doesn't work, power management is still enabled. Sigh. Just realised the other file zz-override-wifi-powersave-off.conf has the value set to 2 but in any case it still doesn't default to power save off.

Edit: I disabled power management with iwconfig wlan0 power off Pings are now consistent at <5ms with the odd sub 50ms ping. I need to disable power management all the time or understand and fix the issue when it's enabled. Here is the information requested before power management was disabled. I'm using a 3A USB PSU (5.2V), the same PSU supplied with an RPI 3 root@orangepizeroplus2:~# iwconfig lo no wireless extensions. wlan0 IEEE 802.11 ESSID:"NMIWIFI" Mode:Managed Frequency:2.462 GHz Access Point: C8:D3:A3:40:F6:80 Bit Rate=19.5 Mb/s Tx-Power:32 dBm Retry min limit:10 RTS thr:off Fragment thr:off Encryption key:off Power Managementmode:All packets received Link Quality=4/5 Signal level=-65 dBm Noise level=-91 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 root@orangepizeroplus2:~# root@orangepizeroplus2:~# h3consumption -p Active settings: cpu 1200 mhz allowed, 1200 mhz possible, 4 cores active dram 408 mhz hdmi/gpu active usb ports active wlan0 IEEE 802.11 ESSID:"NMIWIFI" Mode:Managed Frequency:2.462 GHz Access Point: C8:D3:A3:40:F6:80 Bit Rate=19.5 Mb/s Tx-Power:32 dBm Retry min limit:10 RTS thr:off Fragment thr:off Encryption key:off Power Managementmode:All packets received Link Quality=4/5 Signal level=-66 dBm Noise level=-91 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 root@orangepizeroplus2:~# I also ran speedtest-cli root@orangepizeroplus2:~# speedtest-cli Retrieving speedtest.net configuration... Retrieving speedtest.net server list... Testing from PlusNet (81.174.156.174)... Selecting best server based on latency... Hosted by Vorboss Limited (London) [2.56 km]: 28.395 ms Testing download speed........................................ Download: 29.36 Mbit/s Testing upload speed.................................................. Upload: 9.38 Mbit/s root@orangepizeroplus2:~# And here's the ping test from my Windows dev machine C:\Users\cliffb.UIT>ping 10.236.0.60 -t Pinging 10.236.0.60 with 32 bytes of data: Reply from 10.236.0.60: bytes=32 time=880ms TTL=64 Reply from 10.236.0.60: bytes=32 time=3ms TTL=64 Reply from 10.236.0.60: bytes=32 time=298ms TTL=64 Reply from 10.236.0.60: bytes=32 time=5ms TTL=64 Reply from 10.236.0.60: bytes=32 time=1486ms TTL=64 Reply from 10.236.0.60: bytes=32 time=2ms TTL=64 Reply from 10.236.0.60: bytes=32 time=1513ms TTL=64 Reply from 10.236.0.60: bytes=32 time=3ms TTL=64 Reply from 10.236.0.60: bytes=32 time=2054ms TTL=64 Reply from 10.236.0.60: bytes=32 time=3ms TTL=64 Reply from 10.236.0.60: bytes=32 time=946ms TTL=64 Reply from 10.236.0.60: bytes=32 time=6ms TTL=64 Request timed out. Reply from 10.236.0.60: bytes=32 time=229ms TTL=64 Ping statistics for 10.236.0.60: Packets: Sent = 14, Received = 13, Lost = 1 (7% loss), Approximate round trip times in milli-seconds: Minimum = 2ms, Maximum = 2054ms, Average = 571ms Control-C ^C C:\Users\cliffb.UIT>

I should probably start a new thread for this but it seemed appropriate to post here at this time of nght.. So the OPi Zero Plus 2 boards arrived and I duly set up the image on a 8GB SD card, connected the serial TTL to USB adapter and booted. Everything came up fine so I set up the wifi to my local network using nmtui. Again no problems. I did an apt-get update and upgrade and rebooted, all OK again. Having SSHed into the device I get very sluggish performance and pinging from another machine on the lan I see hugely variable pings ie variations from a few ms to over a second. I installed wavemon and it shows a very strong wifi signal (as expected). The pings are when the OPi is quiescent so no heavy loads to cause issues AFAICT. I read that the earlier wifi chip with the Pi Zero has issues but thought that the AP6212(A) was stable and reliable? Is there anything I have missed in the set up? By way of comparison a RaspPi Zero W yields very stable low ms pings. Forgot to say the installed version. uname -a output below Linux orangepizeroplus2 3.4.113-sun8i #18 SMP PREEMPT Thu Jun 15 02:16:06 CEST 2017 armv7l armv7l armv7l GNU/Linux