With the latest nightly build (139) the AREDN code should be able to be successfully loaded and run on any supported device of 32 MB of RAM or higher. Props to the AREDN guys, with yeoman help from Eric KG6WXC, for hacking and slashing at the code to get it trimmed down!
Downloads can be gotten from the AREDN web site (arednmesh.org) under Software / Nightly Builds
If you're installing it on a virgin Ubiquiti device, use the factory version, otherwise use the sysupgrade. Downgrading the AirOS version is NO LONGER necessary
One caveat: I've been told that none or one tunnel is all you should run on a 32 MB device
Known issues
- the Node Description field works, but not if you put an apostrophe in it (').
- Sometimes the Firmware Update screen doesn't show prior to the node rebooting to install new firmware
For a detailed list of items being worked (not many at this point), see the Issue Tracker, under Developers. (you need an account on github.com
Go Forth and test! Suspected bugs should be posted in the Forum, under Development / Possible Bugs .
You are here
32 MB Nightly Build now available
Wed, 08/08/2018 - 17:09
#1
w6bi
32 MB Nightly Build now available
Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer
However, for the adventurous types... feel free to test and report back your findings.
That patch is pending.
I've put the nightly build on an old Bullet, and it shows 4.6 MB of RAM available. I guess theoretically you could run several. Maybe the AREDN devs can provide better guidelines.
As the RAM demand increases to the limit, the kernel starts spending more and more time trying to manage and free up what it can. At some point it will pick a process with a high point score and kill it to survive. OLSR is high on the target list, which if killed is watchdog reset -- more instability. Then, at some point it becomes so sluggish that it's not functioning.
We are chipping away at things we don't need in RAM and reducing process size where able. We were able to take more IPV6 code out of processes than had been previously removed. We made snmp an optional install, and some other misc things. We hope this leaves sufficient RAM to function. If not, we'll look for more to chip out.
Joe AE6XE
that number is a JOB number (not a true BUILD number). We've been running other jobs for things. everytime we run a job, it increments the number.
The higher the JOB number, the newer the build (in the case of nightly builds)
ie. For the "nightly build" workflow, there are 6 jobs that run (if there are changes to build) and only 1 job runs if there is nothing new to build.
32MB Nanostation M2 is stable at 64+ hours on build 139 and AR-HP at 24+ hours on build 154 :)
Both around 5MB free memory. No tunnels. NSM2 is connected to 5 other live nodes via RF.
Other stuff ok on 139:
3 PowerBeam M5-400 (1 tunnel server+meshchat api, 1 tunnel client, 1 clean)
PowerBeam M5-300
Nanostation M2 XW (tunnel client+meshchat api)
NS M5 XW (No RF conn)
MikroTik BaseBox 2
Ian
Joe AE6XE
For whatever reason, when there are no mesh RF links, and the 32Mb RAM node is communicating via DtDlink to the mesh network, it would become unresponsive in the 3.17.1.0RC1. Can you change the channel on the AR or the NSM2 XM so no other nodes have a link, and see if these nodes remain stable for more than a ~day? These symptoms had usually occurred in ~hours. If we have chipped enough away at RAM usage, and get over this hurdle, it would be even greater news.
The last hurdle, I suspect a change may be needed for sysupgrade process to be stable. We don't yet have a change that was in 3.17.1.0RC1 to make sure /tmp, which is in RAM, has enough room to upload a ~6Mb image file and complete the process. However, the openwrt sysupgrade process has also had some changes to address limited RAM usage that may have compensated, which may also be related to why we sometimes don't see the "doing the upgrade screen".
Joe AE6XE
I am seeing the GUI slowness on the AR-HP under build 154 after 24 hours with only a DtD link to the live mesh. Is this addressed in 165? If so I'll bump it up.
flash = 1668 KB
/tmp = 13840 KB
memory = 3332 KB
I have had the upgrade not "take" a few times but on both 32 and 64MB devices. It will reboot but stay on the installed version. Not sure if it's related to the /tmp file issue above? It seems to be less common with the later builds.
Ian
3.16.1.1 on occasion will sometimes not take a sysupgrade if it hasn't been reboot recently. Many groups will always reboot a tower node before doing a sysupgrade. My view is we can get over the last hurdle if it will sysupgrade shortly after a reboot reliably.
Joe AE6XE
Joe AE6XE
1. boot it before performing the upgrade - less chance of extra "suff" hosing up the system
2. Use Google Chrome browser (you can watch the upload progress in the bottom left corner)
I too have had that "not take" when doing an upgrade. It seems to occur with all or most of the current Nightly Builds including aredn-165 but not all the time. Once the upgrade starts I see the usual warning about the upgrading happening and to not power off but when the node comes back up it still has the same old version. This has happened quite a few times on different nodes. I haven't yet tried to reboot right before doing the upgrade.
73 - Mike ab4yy
A commit to the nightly build was added today and new 'nightly build' images will be available tomorrow, Aug 23, 2018. This commit made several changes to mitigate the symptoms of 32Mb devices becoming sluggish. Early test results indicate the problem has been solved. However, we need more exposure and diverse environments to confirm. Please upgrade your 32Mb devices appropriate to run the nightly build and feedback results, e.g. still ticking after 'x' days. If you have a device with no RF link and communicate with a DTDlink or tunnel, please test. This was the scenario where the device would grind to a halt after hours or days, and expected to no longer be the case.
For all releases, it is best practice, particularly at tower sites, to reboot the node before doing a sysupgrade of new firmware and ensure clean-sufficient RAM is available. This is also a 2nd scenario to test is stable and early testing has not revealed any concerns.
Joe AE6XE