Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CPE210 high cpu load bug still present #142

Closed
fnetX opened this issue Feb 22, 2021 · 17 comments · Fixed by #169
Closed

CPE210 high cpu load bug still present #142

fnetX opened this issue Feb 22, 2021 · 17 comments · Fixed by #169
Milestone

Comments

@fnetX
Copy link

fnetX commented Feb 22, 2021

Hey there,

just installed falter onto my CPE210v3 and noticed that this bug is apparently still present:
freifunk-berlin/firmware#769

Disabling rssi dropped cpu load from 0.66 to 0.02 immediately.

Thank you for your work on falter so far, using it feels very nice.

image

@Noki
Copy link
Member

Noki commented Feb 24, 2021

Thanks for bringing this up! I had the same issue on my CPE210v3 with cpu load of >1 and disabling rssi brought it down to idle. Disabling rssi by default would be great.

@PolynomialDivision
Copy link
Contributor

PolynomialDivision commented Feb 24, 2021

Could u put a bug report to Openwrt? This seems not to be falter related and should be fixed upstream. ;)

@Akira25
Copy link
Member

Akira25 commented Feb 27, 2021

@fnetX in the old issue at the other repo, there is a notice, that this behaviour does not happen on stock OpenWrt. Can you confirm this?

@fnetX
Copy link
Author

fnetX commented Feb 27, 2021

Okay, I'm resetting a CPE210v3 right now via tftp using the freifunk spalter firmware image. I'm then upgrading to the openwrt sysupgrade image via LuCI without checking the "keep config" box (So that you do know my current workflow in case it alters the result).

Well, after 6min uptime the load average is at 0.02 / 0.09 / 0.05
and top says 99 % idle with rssileds taking 2% RAM but 0% CPU. I didn't see any spikes yet.

I'll let it run for a moment, I will tell you if notice something else.

Update: Had it running for about two hours, load decreased to around 0.01. The monitoring of the freifunk router showed up high load much earlier, so I assume this is not an issue that shows up after some uptime.

@PolynomialDivision
Copy link
Contributor

Okay, I'm resetting a CPE210v3 right now via tftp using the freifunk spalter firmware image. I'm then upgrading to the openwrt sysupgrade image via LuCI without checking the "keep config" box (So that you do know my current workflow in case it alters the result).

Well, after 6min uptime the load average is at 0.02 / 0.09 / 0.05
and top says 99 % idle with rssileds taking 2% RAM but 0% CPU. I didn't see any spikes yet.

I'll let it run for a moment, I will tell you if notice something else.

Update: Had it running for about two hours, load decreased to around 0.01. The monitoring of the freifunk router showed up high load much earlier, so I assume this is not an issue that shows up after some uptime.

Could u give more information? Did u flashed OpenWrt 19.07 or Snapshot?

@pmelange
Copy link
Collaborator

I have tried this with vanilla openwrt 19.07.7 and have very similar results. So this is not a freifunk specific problem and should be sent upstream.

In my opinion, the init script for rssileds should check to see if the option dev 'NAME' for the rssid_wlanX section exists in wireless as option ifname 'NAME' before starting the binary.

@fnetX would you like to file a bug report upstream?

But we could also take the recommendation from freifunk-berlin/firmware#769 and change the option dev 'NAME' in rssid_wlanX to be either the "mesh" or the "dhcp" wireless interface. I don't really have a preference and would like to hear some opinions before implementing any changes.

@fnetX
Copy link
Author

fnetX commented Feb 28, 2021

I flashed 19.07.7 (this table, https://openwrt.org/toh/tp-link/cpe210#installation third row, upgrade)

So I don't want to file a bug for something I cannot reproduce.

@pmelange did you just install or did the problem arise after some configuration?

@Noki
Copy link
Member

Noki commented Feb 28, 2021

@pmelange I would prefer having the leds associated with the mesh interface because they can help with adjusting and once the CPE is installed, I don't think anybody looks at them anymore. Deactivating them to reduce power consumption can also be a good option.

@pmelange
Copy link
Collaborator

I only have a CPE210 v1.

I installed vanilla openwrt without keeping the old settings, enabled wireless (via the web interface), and changed the ifname to "test". Then I rebooted the device. The sys % was quite high (ca 20%).

Then I went and changed the ifname back to nothing (taking the default value of wlan0) rebooted and the sys % was down to about 2%.

@pmelange
Copy link
Collaborator

@pmelange I would prefer having the leds associated with the mesh interface because they can help with adjusting and once the CPE is installed, I don't think anybody looks at them anymore. Deactivating them to reduce power consumption can also be a good option.

I think associating with the mesh interface is fine.

I would leave the power-saving to those who are interested in manually disabling the LEDs themselves.

@fnetX
Copy link
Author

fnetX commented Mar 7, 2021

My bad, I forgot about enabling the Wi-Fi on OpenWrt, just installed, booted and had a quick check.

I'm new to Freifunk and OpenWrt, I don't know how to change the interface name. With the default settings, OpenWrt works fine without high load.

@everloop2
Copy link
Contributor

My bad, I forgot about enabling the Wi-Fi on OpenWrt, just installed, booted and had a quick check.

I'm new to Freifunk and OpenWrt, I don't know how to change the interface name. With the default settings, OpenWrt works fine without high load.

  • direct connect to CPE & open a terminal: ssh [email protected]
  • vi /etc/config/system -> go to: config rssid 'rssid_wlan0'
  • press: [i] (insert mode)
  • change: option dev 'wlan0' to option dev 'wlan0-mesh-2'
  • press [ESC], [:], [w] (write), [q] (quit), [return]
  • reboot now

@everloop2
Copy link
Contributor

everloop2 commented Mar 24, 2021

I only have a CPE210 v1.

I installed vanilla openwrt without keeping the old settings, enabled wireless (via the web interface), and changed the ifname to "test". Then I rebooted the device. The sys % was quite high (ca 20%).

Then I went and changed the ifname back to nothing (taking the default value of wlan0) rebooted and the sys % was down to about 2%.

did some further testing - bug is reproducible, (for measurement did logout LuCI, ssh & top):

  • Freifunk images -> FFwizard+reboot -> CPU ~35%

    -> set rssi to wlan0-dhcp2 or wlan0-mesh-2 in /etc/config/system -> CPU ~5%

  • openwrt stock (19.07.7) firstboot:
    -> AP disabled (default setting) -> CPU ~2%
    -> AP enabled -> CPU ~4%
    !!! -> AP disabled again -> CPU ~20%
    -> AP enabled again -> CPU ~4%
    -> AP + WWAN + Mesh -> CPU ~5%
    !!! -> disabled everything (AP, WWAN, Mesh) -> CPU 15-25%
    -> enabled only one AP,WWAN or Mesh -> CPU ~5%

  • top always shows /usr/sbin/rssileds 2% CPU
    -> AP enabled -> 0% sys
    !!! -> AP disabled -> 14% sys

AP enabled:

CPU:   0% usr   0% sys   0% nic  98% idle   0% io   0% irq   0% sirq
  124     2 root     RW       0   0%   1% [kworker/0:1]
 1326     1 root     S     1440   2%   0% /usr/sbin/rssileds wlan0 200000 1 tp-link:green:link1 1 100 0 1 tp-l
 1675  1667 root     R     1208   2%   0% top
 3594     1 root     S     1776   3%   0% /usr/sbin/hostapd -s -P /var/run/wifi-phy0.pid -B /var/run/hostapd-p
 1666  1002 root     S     1144   2%   0% /usr/sbin/dropbear -F -P /var/run/dropbear.1.pid -p 22 -K 300 -T 3
  902     1 root     S     2168   4%   0% /sbin/rpcd -s /var/run/ubus.sock -t 30
 1058     1 root     S     1676   3%   0% /sbin/netifd
    1     0 root     S     1564   3%   0% /sbin/procd
 1092     1 root     S     1444   2%   0% /usr/sbin/odhcpd
 1150     1 root     S     1344   2%   0% /usr/sbin/uhttpd -f -h /www -r OpenWrt -x /cgi-bin -t 60 -T 30 -k 20
 1471     1 dnsmasq  S     1344   2%   0% /usr/sbin/dnsmasq -C /var/etc/dnsmasq.conf.cfg01411c -k -x /var/run/
  871     1 root     S     1244   2%   0% /sbin/logd -S 64
  519     1 root     S     1220   2%   0% /sbin/ubusd
 1667  1666 root     S     1216   2%   0% -ash
 1382     1 root     S<    1208   2%   0% /usr/sbin/ntpd -n -N -S /usr/sbin/ntpd-hotplug -p 0.openwrt.pool.ntp
 1002     1 root     S     1076   2%   0% /usr/sbin/dropbear -F -P /var/run/dropbear.1.pid -p 22 -K 300 -T 3
  537     1 root     S     1024   2%   0% /sbin/urngd
  520     1 root     S      920   2%   0% /sbin/askfirst /usr/libexec/login.sh

AP disabled:

CPU:   4% usr  14% sys   0% nic  81% idle   0% io   0% irq   0% sirq
  124     2 root     IW       0   0%   1% [kworker/0:1]
 4008  1667 root     R     1208   2%   0% top
 1666  1002 root     S     1144   2%   0% /usr/sbin/dropbear -F -P /var/run/dropbear.1.pid -p 22 -K 300 -T 3
    8     2 root     IW       0   0%   0% [kworker/u2:1]
  902     1 root     S     2168   4%   0% /sbin/rpcd -s /var/run/ubus.sock -t 30
 1058     1 root     S     1676   3%   0% /sbin/netifd
    1     0 root     S     1564   3%   0% /sbin/procd
 1092     1 root     S     1444   2%   0% /usr/sbin/odhcpd
 1326     1 root     S     1440   2%   0% /usr/sbin/rssileds wlan0 200000 1 tp-link:green:link1 1 100 0 1 tp-l
 1150     1 root     S     1352   2%   0% /usr/sbin/uhttpd -f -h /www -r OpenWrt -x /cgi-bin -t 60 -T 30 -k 20
 1471     1 dnsmasq  S     1344   2%   0% /usr/sbin/dnsmasq -C /var/etc/dnsmasq.conf.cfg01411c -k -x /var/run/
  871     1 root     S     1244   2%   0% /sbin/logd -S 64
  519     1 root     S     1220   2%   0% /sbin/ubusd
 1667  1666 root     S     1216   2%   0% -ash
 1382     1 root     S<    1208   2%   0% /usr/sbin/ntpd -n -N -S /usr/sbin/ntpd-hotplug -p 0.openwrt.pool.ntp
 1002     1 root     S     1076   2%   0% /usr/sbin/dropbear -F -P /var/run/dropbear.1.pid -p 22 -K 300 -T 3
  537     1 root     S     1024   2%   0% /sbin/urngd
  520     1 root     S      920   2%   0% /sbin/askfirst /usr/libexec/login.sh

@Akira25
Copy link
Member

Akira25 commented Mar 25, 2021

I have tried this with vanilla openwrt 19.07.7 and have very similar results. So this is not a freifunk specific problem and should be sent upstream.

In my opinion, the init script for rssileds should check to see if the option dev 'NAME' for the rssid_wlanX section exists in wireless as option ifname 'NAME' before starting the binary.

@fnetX would you like to file a bug report upstream?

But we could also take the recommendation from freifunk-berlin/firmware#769 and change the option dev 'NAME' in rssid_wlanX to be either the "mesh" or the "dhcp" wireless interface. I don't really have a preference and would like to hear some opinions before implementing any changes.

I would prefer the association with the mesh-interface too. In addition it sounds like a more quick fix for me than filing that upstream issue. @pmelange could you please implement that? I will merge this then.

@Akira25 Akira25 added this to the falter-1.1.x milestone Mar 25, 2021
@Noki
Copy link
Member

Noki commented Mar 25, 2021

The CPE510 is also affected by this issue.

@everloop2
Copy link
Contributor

Did file a bug:

https://bugs.openwrt.org/index.php?do=details&task_id=3708

everloop2 added a commit to everloop2/packages that referenced this issue Apr 3, 2021
Workaround for high cpu load bug till https://bugs.openwrt.org/index.php?do=details&task_id=3708 is fixed.

In /etc/config/system change rssid_wlan0 option dev 'wlan0' to 'wlan0-mesh-2'.

Fixes freifunk-berlin#142 .

Signed-off-by: everloop2 [email protected]
everloop2 added a commit to everloop2/packages that referenced this issue Apr 3, 2021
Workaround for high cpu load bug till https://bugs.openwrt.org/index.php?do=details&task_id=3708 is fixed.

In /etc/config/system change rssid_wlan0 option dev 'wlan0' to 'wlan0-mesh-2'.

Fixes freifunk-berlin#142.

Signed-off-by: everloop2 <[email protected]>
@pmelange
Copy link
Collaborator

pmelange commented Apr 8, 2021

@everloop2 Please take a look at #169

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
6 participants