Conversation
Update Memory Management
|
Results: |
|
Good news. I've just tried with v1..0.9 and to my untrained eye it looks as if it worked perfectly on my AX86S with low free RAM. It's now showing as the most recent version and everything seems to be okay up to now. I'll forward the logs on the existing SNB conversation. |
Thank you for testing and reporting your results @Yaff1e |
|
Added the minimum cushion we discussed. Will test it sometime this weekend. |
|
Lightly upped the cushion, just to be absolutely sure the steps following don't trigger swapping. |
Sounds good. Looking forward to hearing about your test results. |
OK, that's good. At this point, "better safe than sorry" would be the best approach. I really don't want our script to be blamed if a router is bricked after trying to flash the F/W image while in a "low memory" condition. As we get more data points, and hopefully a few users are willing to test the new code and report results, we can adjust accordingly. |
For this user above, the 35MB limit would still allow his update to start, it would just try to reclaim memory if it fell below 35MB going forwards. I think this may be the safe way forwards while letting as many routers through the gate as possible that can safely update. |
Fully agreed. I still wonder what's causing his router to get so low in "Available RAM" after the ZIP is downloaded and the image is stored in the HOME folder. During all my testing with the RT-AC86U, it has never reached the point where it was below the original "Required RAM" amount - not a single time. And I've been testing for a few months now, using different F/W versions. Most of the time, I have stopped short of the actual F/W flash, but it's already after the point where it has checked for the minimum required and has passed so I get the prompt asking me to type Y to continue to flash. I feel that knowing what's causing his router to get in such a "low memory" condition may give us some clues about what to do to either avoid it or take further steps to get more of the RAM back. Just a thought. |
|
Completed the BACKUPMON Toggle for the Advanced Options menu. So far this PR includes:
|
|
I know I suck, I upped the cushion from 32, to 33 to 35 to 40 lol. Can you tell im indecisive? No but I'm happy with 40. I thought about it overnight in my dreams. That gives our script double the steps the kernel gives itself. That should be enough headroom for the script to trigger a cleanup if it falls below between the checks. And also still allow this user with this data we have today to successfully flash. Looked at both his logs, first would of been flawless, second would of needed cleanup, which would given him over 20MB headroom to continue and he was only 1MB below. I personally would of been happier to see it try to cleanup before the flash in his last successful run, this change would of done that. We can re-assess if it becomes a problem again, but considering how close we are to the limits now. It's unlikely we see this issue again, and if we do I'd probably only consider lowering it down to 35 in the future due to safety concerns . |
|
Touched up some of the logging so we can get logging slightly earlier in the run, can get the version number in the log files. |
It's all looking very good. I do like the extra cushion upped to 40MB. As you said, it's safer to give us the extra headroom to prevent any issues when being too close to the kernel watermarks for "low memory" conditions. |
I don't see it as indecisiveness. You're just trying to come up with a better/safer value based on the limited number of data points we have so far, and given the fact that the built-in function that does the actual F/W Update is essentially a "black box" to us. We have a good idea of what is doing but it's only based on its external behavior; we don't really know its internal mechanism and how it requests RAM pages & manages memory, so we have to be very careful when getting too close to a possible OOM condition. |
Exactly. The 'black box' to us is the key point. |
3 participants
Update Memory Management