Omega2+ goes dead - under process load ?
Thanks a lot for taking time to check..
To me, the device goes down at random, not while compiling any specific unit..
It is dead now, at google/protobuf/descriptor.lo
One more thing, I have seen if we add "-mlxc1-sxc1" to CXXFLAGS, that would add more load..
It compiled with OpenWRT 18.06.8 ramips fw.
make: Leaving directory '/home/admin1/protobuf-3.13.0/src'
make: Leaving directory '/home/admin1/protobuf-3.13.0'
real 5h 24m 21s
user 4h 44m 42s
sys 14m 16.34s
Setup is the same. Required to install more modules:
fdisk block-mount e2fsprogs kmod-fs-ext4 kmod-usb-storage kmod-usb2
Could you try that ?
The O2+ with b233 FW holds more time after installing 2 small heat-sinks on the metal shield:
The left one is running OpenWRT 18.06.8(active); right one was running b233 (dead).
Your observation about VM was correct. Both OnionOS b233 and OpenWRT 18.06.8 crashes with 512MB swap.
With 1024MB swap and with a pedestal fan blowing air on the metal-shield, OpenWRT can compile. With heat-sink as in the above photograph, OpenWRT can compile.
OnionOS b233 was never able to complete the process.
I think we are looking at 2 issues to address:
- OnionOS stability
During compiling of "google/protobuf/descriptor.lo" processor load goes too high. We can feel it.. if we press <enter>, the response time it takes to get the new prompt is that of a heavily overloaded m/c.
Further, during that time:
13:39:14 up 1:20, load average: 5.73, 2.38, 1.43 and it died after a second or two.
OpenWRT never exceeds 2.0 load average, and most of the time it stays below 1.0.
- Thermal design
Needs a heat sink.
Do you know by any chance, that if the metal shield is removed, can a small heat sink be mounted without shorting other components?
I think the thermal part does have a role during field deployment.down..
And the good part is that, 7688 has built-in thermal shutdown. The OpenWRT processor(left) is the same one, that was running OnionOS earlier, and crashed at least 10 times by now..
- OnionOS stability
@tjoseph1 I think all you have done is discovered what we already know. IoT devices are not designed for heavy load, they are minimalist devices.
I also don't understand why anyone would use an IoT device as a development platform, this is not what it is designed for, it is designed as a deployment target. As you have discovered, you will spend too much time trying to fix issues when you use a device for something it is not designed for.
You can remove the protective shield, I ran an Omega2+ for a few months with no shield, alas it got caught in the rain and went poof! Maybe you could place a heatsink on the Mediatek chip, but I'm not sure that is where the issue is, I have a suspicion it is the DDR2.
Yes. You are right..IoT devices are minimalistic. Yet, I would think that the time is not wasted, it helped me to learn the behavior and the limits it can go..and how far it could be stretched..without breaking it.
There are so many IoT devices out there..each has it's own limits. In that sense, minimalistic is a generic term, to me.
My job is to build a reliable gadget..by looking from every corner. I am not at all constrained by time
@tjoseph1 If you are not constraint by time then you are a very lucky person. Most of us are building stuff and we have timelines and time is money.
Yes..what I said is true, for many years now.
But, that makes me veture into unchartered waters..spend time on otherwise unnecessary things, sort of defocussed.
When I look back, ppl who work under time constraints are lucky..
Grass is greener..the other side..
One other thing that was not quite right in this whole experiment was a "limited" raw swap patition?
Wouldn't it be better to be on a file on sda1(that spans the entire sda), that is recreated at each boot, so that different blocks would be used for rw every time? r-only blocks stays. rw block decays isn't it?
@tjoseph1 Decay is a whole separate discussion because it depends on your use case. For my devices decay is not an issue as the devices read/write ratio is around 1:4200.