High ping by ssh over wifi (opi zero plus 2)

[CliffB]

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
 

 

Edited August 7, 2017 by CliffB
Missed info

[chwe]

Your ping looks very similar to my findings with the opi 0 (see the dogafu experiment). I know that it have a different wlan module. Unfortunately, I don't have a board with an AP6212 wlan chip to test and compare it with your findings. It would be interesting to compare all these cheap SBCs in stability and performance. I don't give a fuck about Mb/s which should be possible since @tkaiser showed clearly that this numbers can change (even position of the board compared to the router can have a huge impact).

But a reliable ping is also a must for my projects. Since I lost one of my reliable powersources and the armbian was buggy after disconection without propper shutdown (forgot to have ttl available after ds18b20 board was attached on it). So the dogafu experiment is on hold at the moment, but will go 'on air' again. 

[tkaiser]

8 hours ago, CliffB said:

I should probably start a new thread for this

 

Yes, please can a moderator move your post and @chwe's and my answer to a new thread in an appropriate forum? To keep this thread a 'clean landing page' for BPi-M2 Zero. Then you should check powermanagement settings since with AP6212 this is important. Check/provide iwconfig and 'h3consumption -p' output please.

[CliffB]

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>

 

 

 

 

Edited August 8, 2017 by CliffB
Further information

[CliffB]

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.

[CliffB]

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?

 

[Igor]

By adding a parameter when wifi module is loading?

 

echo "options ap6212 pm=0" >/etc/modprobe.d/ap6212.conf 

 

Just check the parameter and module name. It's just an example which I made up.

[CliffB]

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?

[martinayotte]

the module is named "brcmfmac"

 

[CliffB]

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.

[Igor]

12 minutes ago, CliffB said:

but my time is becoming limited at this point.

You could not be more wrong to save your time. 

In the case of Allwinner boards, images are based on Armbian Debian, which base is by default inferior to Ubuntu Xenial (which we promote until Stretch is not fully tested and ready). Dietpi user space is further severely changed & crippled without any technical gain - for the sake of fun or just being/look different? This is probably the biggest security issue since it looks like nobody is revisioning those changes. Newbies do not understand, most people do not care, but it is there to strike. Deinstalled essentials to make the image smaller + installer for "everything" is probably the best tool to destroy SD cards faster and learn nothing on the way? Optimisation and advantages? Are newbies able to check them? Do they want to check them? Of course not. Reality: Dietpi is slower in most areas or runs at an equal speed at best. If you are ok with that and if you think you will save your time, why not.

We were optimising those Wireless power management settings for all chips and regressions and troubles are possible ... Since you are trying to put a pressure on us and since I just saved you weeks of your time, I'll rather tune out and enjoy life with my kids from flesh and blood

 

The problem will be solved eventually since this is what we do.

 

1 hour ago, martinayotte said:

the module is named "brcmfmac"

In mainline yes, but AFAIK he is using legacy kernel where it's dhd or ap62xx ... I don't have access to hardware to check which solution is best.

[CliffB]

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 

 

[zador.blood.stained]

On 08.08.2017 at 7:51 PM, CliffB said:

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.

Are you using NM, /etc/network/interfaces or some other method like providing a custom wpa_supplicant configuration file to set up your wireless network? For each different way there will be a different way to disable/override power saving mode.

[Bubba]

On 8/8/2017 at 10:04 AM, CliffB said:

Link Quality=4/5  Signal level=-65 dBm  Noise level=-91 dBm

Not a very good signal, alot of noise, switch channels

I will post some test from a Zero Plus H3 later, but I do not see this from my zero's (but my wifi signal is MUCH cleaner)

[CliffB]

@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!

 

 

[Bubba]

OK I moved the zero plus H3 to about 10 meters with two walls in the path

I ran Ping with and without PM.

I see the same thing you see high ping times with pw enabled, PM is enabled on reboot

ping_from_0plusH3_PM_off.txt

ping_from_0plusH3_PM_on.txt

[CliffB]

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.

[tkaiser]

16 hours ago, zador.blood.stained said:

For each different way there will be a different way to disable/override power saving mode.

 

Just for the record the methods DietPi collected over time here and there (they're not using Network Manager since 'bloated' and replace configuration with their own menu driven tools).

 

At various places this here will be added on all their images:

echo -e "options 8192cu rtw_power_mgnt=0" > /etc/modprobe.d/8192cu.conf
echo -e "options 8188eu rtw_power_mgnt=0" > /etc/modprobe.d/8188eu.conf
echo -e "options 8189es rtw_power_mgnt=0" > /etc/modprobe.d/8189es.conf
echo -e "options 8723bs rtw_power_mgnt=0" > /etc/modprobe.d/8723bs.conf

Then this will be added to the wlan0 entry in /etc/network/interfaces

wireless-power off

And finally there's a service /etc/systemd/system/wifi_disable_powersave.service containing this (which is responsible for turning powermanagement off in case of AP6212[A]):

[Unit]
Description=Disable WiFi power management
After=network.target network-online.target
[Service]
Type=simple
RemainAfterExit=yes
ExecStart=/bin/bash -c 'sleep 20;iwconfig wlan$(sed -n 2p /DietPi/dietpi/.network) power off
[Install]
WantedBy=multi-user.target

So it's a whole load of attempts to disable powermanagement in any case (which is not what we want since there are use cases where activated powermanagement makes sense), on AP6212[A] equipped boards it's one single iwconfig call that does the job which is essentially what Armbian tries to do too: https://github.com/armbian/build/blob/master/packages/bsp/h3consumption#L255-L273

 

@CliffB can you please provide output of 'sudo armbianmonitor -u' so that we can get a clue what's going on?

[CliffB]

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,

[Igor]

I just checked and it's trivial:

iwconfig wlan0 power off

 

pm off

Spoiler

PING 172.16.100.1 (172.16.100.1) 56(84) bytes of data.
64 bytes from 172.16.100.1: icmp_seq=1 ttl=64 time=2.62 ms
64 bytes from 172.16.100.1: icmp_seq=2 ttl=64 time=2.20 ms
64 bytes from 172.16.100.1: icmp_seq=3 ttl=64 time=2.19 ms
64 bytes from 172.16.100.1: icmp_seq=4 ttl=64 time=74.3 ms
64 bytes from 172.16.100.1: icmp_seq=5 ttl=64 time=35.2 ms
64 bytes from 172.16.100.1: icmp_seq=6 ttl=64 time=2.10 ms
64 bytes from 172.16.100.1: icmp_seq=7 ttl=64 time=2.09 ms
64 bytes from 172.16.100.1: icmp_seq=8 ttl=64 time=2.19 ms
64 bytes from 172.16.100.1: icmp_seq=9 ttl=64 time=1.75 ms

 

 

pm back on

Spoiler

64 bytes from 172.16.100.1: icmp_seq=1 ttl=64 time=1871 ms
64 bytes from 172.16.100.1: icmp_seq=2 ttl=64 time=869 ms
64 bytes from 172.16.100.1: icmp_seq=3 ttl=64 time=3246 ms
64 bytes from 172.16.100.1: icmp_seq=4 ttl=64 time=2247 ms
64 bytes from 172.16.100.1: icmp_seq=5 ttl=64 time=1249 ms
64 bytes from 172.16.100.1: icmp_seq=6 ttl=64 time=250 ms

 

 

 

Module name is dhd and I am connected with Network manager.

[CliffB]

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.

 

[Igor]

2 hours ago, CliffB said:

The question is how to make the system default to power management off at start up.

I would say adding to  /etc/rc.local , right before exit 0 should be just fine.

[CliffB]

Tried that early on and no difference.

[Igor]

Then it must be the delay since it works when you log in. I will do more tests ...

 

[Igor]

/etc/rc.local

 

This works for me:

#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.
sleep 20; iwconfig wlan0 power off
exit 0

We will make some generic solution, but until then this should do.

[CliffB]

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.

 

[CliffB]

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

 

 

[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.