Update "4MB" target to "tiny", including 8/32 devices

[SvenRoederer]

The router target names have been updated to mirror the changes made upstream. All "4MB" targets are now "tiny" targets. Targets with only 32MB ram are also now "tiny" targets.

[booo]

Could you please provide some information about the affected software (daemons).

[SvenRoederer]

It's mostly the kernel OOM killer causing LuCI / lua, olsrd, hostapd to "die".
I also had seen situation, where extra treatment was needed, to start the firmware-upgrade. (After downloading the image, the device soon rebooted)

[pmelange]

I think the title of the PR and it's description don't really describe the changes.

The router target names have been updated to mirror the changes made upstream. All "4MB" targets are now "tiny" targets. Targets with only 32MB ram are also now "tiny" targets.

[SvenRoederer]

@pmelange feel free to change to a better subject

for 4/32 devices our current setup seems the best, but for 8/32 devices we should keep opkg, imho.
To do so, we need to create a 3rd set of packages ....

[pmelange]

If this isn't ready, then maybe we should wait for the full implementation. When the 8/32 devices should be taken care of at a later time, then they should not be put into the "tiny" images yet.

[pmelange]

@SvenRoederer I've updated the title and first comment of this PR. Can you make the commit messages clearer?

[SvenRoederer]

If this isn't ready, then maybe we should wait for the full implementation. When the 8/32 devices should be taken care of at a later time, then they should not be put into the "tiny" images yet.

The point is: do we want to handle the 8/32 devices like the 4/32 devices? The 8/32 have enough flash to hold the regular software and have still space left. This is a major difference to 4/32. But as of the low RAM we should handle them separately from recent 8+/64+ devices

[pmelange]

It isn't clear to me what we are doing differently with the 32MB devices. So far the only thing I know about is in the wizard, when deciding to configure statistics or not. Am I missing something?

Are the installed packages for 8/32 different from the 8+/64+ devices? How exactly is the low RAM handled?

[SvenRoederer]

diff -u default.txt default_4MB.txt
--- default.txt 2019-04-16 22:16:29.985320694 +0200
+++ default_4MB.txt     2019-04-16 22:16:29.985320694 +0200
@@ -1,7 +1,14 @@
+-kmod-usb-core
+-kmod-usb2
+-kmod-ledtrig-usbdev
+-kmod-usb-ohci
+-kmod-ppp
+-kmod-usb-serial
--wpad-mini
-wpad-basic
+-wpad
 # Common
-vnstat
-ethtool
 # OLSR
-olsrd-mod-txtinfo
-olsrd-mod-watchdog
-# BATMAN
-kmod-batman-adv
-alfred
-batctl-default

Beside the statistics the 4MB-packages exclude some daemons, some kernel-modules and use the smaller version of wpad. This should help to reduce the memory-pressure.

[pmelange]

Should we close this PR unmerged, forget about the 4MB devices, and move on with our lives?

Dealing with low-RAM devices could be handled separately. Perhaps by automatically disabling certain settings/services (RRD, OLSR6) in the wizard or uci-defaults?

[SvenRoederer]

That's the point: It's quiet clear, that nobody will take care for 4MB devices anymore. But the subject is about "do we handle 8/32 MB devices like 4/32 MB devices"? --> drop official support now?

[SvenRoederer]

for reference https://openwrt.org/supported_devices/432_warning.

Also the OpenWrt-team mentions:

32 MB can work for minimal router/AP functions, but may repeatedly “crash”, depending on your hardware and use case

[SvenRoederer]

for 8/32 MB devices gluon seems to go to use zram to ease the low-ram issue by emulating additional RAM (freifunk-gluon/gluon#1692)
It seems to have positive effects on the stability of these board. We can implement such a setup by adding a "lowram"-package set

[SvenRoederer]

It isn't clear to me what we are doing differently with the 32MB devices. So far the only thing I know about is in the wizard, when deciding to configure statistics or not. Am I missing something?

Are the installed packages for 8/32 different from the 8+/64+ devices? How exactly is the low RAM handled?

I just installed a master-branch build (b255cf3) on a NSM5 (8/32 device). The board was nearly not operable, until I disabled collectd (local RRD was not enabled at all). The avail RAM also became lower, as the kernel has become >1MB larger from Hedy-1.0.4 to this master.

• hedy-1.0.4-ar71xx-generic-vmlinux.elf : 3727256 bytes
• freifunk-berlin-development-b255cf3-ar71xx-generic-vmlinux.elf: 4940768 bytes

So using the current 4MB package list will remove some RAM-pressure, as some smaller binaries are used the collectd package will not be installed anyways and so the wizard even do not need to think of enabling it or not.

[SvenRoederer]

The avail RAM also became lower, as the kernel has become >1MB larger from Hedy-1.0.4 to this master.

* `hedy-1.0.4-ar71xx-generic-vmlinux.elf `: 3727256 bytes
* `freifunk-berlin-development-b255cf3-ar71xx-generic-vmlinux.elf`: 4940768 bytes

• freifunk-berlin-development-b255cf3-ar71xx-generic-vmlinux.elf` (with CONFIG_KMOD_ALL disabled): 4732352 bytes

So there seems some room by disabling additional kernel-options

[SvenRoederer]

#806 seems also affected by the limited RAM of 32MB devices

[SvenRoederer]

I recently read the following comment in a non-public mailinglist

im kosmos-viertel sind noch erste-generation NanoStation-M2's in Benutzung. Die crashen regelmäßig weil die nur 32M RAM haben.

They are running with "Freifunk Berlin 1.1.0-rc2-Gonzo / c544521" (OpenWrt.18.06).

[pmelange]

I recently read the following comment in a non-public mailinglist

im kosmos-viertel sind noch erste-generation NanoStation-M2's in Benutzung. Die crashen regelmäßig weil die nur 32M RAM haben.

They are running with "Freifunk Berlin 1.1.0-rc2-Gonzo / c544521" (OpenWrt.18.06).

They were recently running hedy. They crashed regularly then too. The following services are also disabled (in hedy and gonzo) olsr6, rrd, uhhtpd and odhcpd. 32MB RAM just doesn't work for nodes on the backbone.

[Akira25]

I'm wondering, why this discussion starts again after nearly one year of inactivity. Didn't we agree on, that we won't support those devices droped by OpenWRT?!On the firmware wiki-page, we do not recommend those routers for a long time.

I think we should not invest even more time in handling deprecated devices, as there are some other major issues in our firmware. I'd be in favor of even stop building these images, as new Freifunkas might try to flash them against all warnings and will get very frustrated.

This is not an issue of software instability, but of far too less resources.

[booo]

I totally agree with @Akira25 s arguments!

[SvenRoederer]

Nice to see, that everybody agrees on phasing out the support of these "tiny" hardware capability devices.
During the years of this PRs life, is has become quite clear (OpenWrt-20.x will be branched probably soon), that we should not prolong 4MB-Flash devices or 32MB-RAM devices on the next release.
Based on this "agreement" this PR makes all 8/32MB devices to be treated like 4/32MB devices. In the next step, we can just simply deactivate them together, no matter to which SUBTarget they belong.

If the consensus is so clear, I wonder why there was never any approach to merge this PR and step forward.

@pmelange

They were recently running hedy. They crashed regularly then too. The following services are also disabled (in hedy and gonzo) olsr6, rrd, uhhtpd and odhcpd. 32MB RAM just doesn't work for nodes on the backbone.

I'm runnig a TLink-WR741 (4/32) on Hedy without problems having removed collectd and vnstat also (https://github.com/freifunk-berlin/firmware/blob/master/packagelists/mesh_4MB.txt) in a mesh linked via bbbvpn.

root@Ahof-frieden01:~# uptime 
 00:08:10 up 34 days,  3:48,  load average: 0.09, 0.08, 0.08
root@Ahof-frieden01:~# cat /proc/meminfo 
MemTotal:          28436 kB
MemFree:            6188 kB
MemAvailable:       8920 kB
Buffers:            1696 kB
Cached:             3244 kB
SwapCached:            0 kB
Active:             6140 kB
Inactive:           1236 kB
Active(anon):       2552 kB
Inactive(anon):       48 kB
Active(file):       3588 kB
Inactive(file):     1188 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:             0 kB
SwapFree:              0 kB
Dirty:                 0 kB
Writeback:             0 kB
AnonPages:          2444 kB
Mapped:             2172 kB
Shmem:               164 kB
Slab:               6784 kB
SReclaimable:       1540 kB
SUnreclaim:         5244 kB
KernelStack:         360 kB
PageTables:          240 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:       14216 kB
Committed_AS:       5308 kB
VmallocTotal:    1048372 kB
VmallocUsed:           0 kB
VmallocChunk:          0 kB

[SvenRoederer]

rebased the whole thing onto master and looking forward to get it merged within the 2 years period.

[SvenRoederer]

These PR should be merged as "rebase", as the individual commits are so much apart from each other.

[Akira25]

AFAICT, this looks good. I'd like to have this merged.

[SvenRoederer]

@Akira25 the repo is setup to require at least one reviewer with commit-permissions to allow merging. As you seem to have the right spirit I just sent you an invitation to the @freifunk-berlin/firmware-contributors team.