Ubuntu Mate is Ubuntu's offering for the Pi2. It must be installed on a Pi2 - not backwards compatible with earlier models. Ubuntu's repository supplies boinc 7.2.42+dfsg. I am running Mate on two Pi2 now but I am not using them to crunch data.
There currently is an issue with the E@H app running on Ubuntu Mate on the Pi2. We hope to fix the in the foreseeable future tho.
I've changed the Pi from overclocking pi2 to normal and the only which is changing, is the time until the free memory is going down. So the Pi will longer stay up.
But are you even sure this is the cause of the problem? I haven't seen any evidence yet that memory is a problem. It is not uncommon for Linux systems to have close to zero "free" memory, because Linux tends to use otherwise unused memory for e.g. file caching. When processes request more memory, part of the cache memory is released and can be used again. Having memory totally unused is just a waste, especially on systems with rather slow disk (memory card) IO. If you use the 'free' command, it will give a more differentiated picture, e.g. output like this :
Meaning that even tho only ca 153 MB are technically 'free' = unused (first row), if you take into account what could be regained from cache memory (second row), a more realistic figure for still usable memory is 406MB (almost half the Pi2's total memory). BTW , you can see that this particular Pi2 uses a lot of swap space, most of it caused by firefox which has a tendency to allocate tons of memory).
It's the same info given in top, with just the added convenience of doing the math for you that I outline above. Logging the data (from free or top) in finer intervals would confirm or reject the hypothesis that the crashes are caused by running out of memory (which should only happen after even the swap file is exhausted). The last entry in the log before the crash would be the one to look at, no need to go thru the lengthy log manually (use tail).
Finished!
I will give up!
Yesterday the System won't make any cronjob for history_log after 12 AM but crunching E@H still running. This morning the System again was bloody low om Memory but still crunching. But, no login on system are possible. After entering the PW the System switched back to login or say's access denied. So I had to initiate a cold/hard reboot. It make no sense to take more time in this System (wheezy/jessie) and I will start from the Beginning with a fresh install on another SD Card with wheezy (without noob/noob-light).
Any chance to get an actual Boinc app for this Distribution (2015-05-05-raspbian-wheezy) or I have to wait for the next Distribution?
The only thing that is really wrong with the wheezy BOINC version on a Raspi2 is that it won't trigger the download of the NEON optimized app variant, so your options include :
a) live with the somewhat suboptimal BRP app, or
b) use wheezy BOINC, and install NEON optimized app as anonymous platform app (app_info.xml), or
c) compile your own BOINC (as discussed in this thread)
RE: Ubuntu Mate is
)
There currently is an issue with the E@H app running on Ubuntu Mate on the Pi2. We hope to fix the in the foreseeable future tho.
Cheers
HB
RE: I've changed the Pi
)
But are you even sure this is the cause of the problem? I haven't seen any evidence yet that memory is a problem. It is not uncommon for Linux systems to have close to zero "free" memory, because Linux tends to use otherwise unused memory for e.g. file caching. When processes request more memory, part of the cache memory is released and can be used again. Having memory totally unused is just a waste, especially on systems with rather slow disk (memory card) IO. If you use the 'free' command, it will give a more differentiated picture, e.g. output like this :
Meaning that even tho only ca 153 MB are technically 'free' = unused (first row), if you take into account what could be regained from cache memory (second row), a more realistic figure for still usable memory is 406MB (almost half the Pi2's total memory). BTW , you can see that this particular Pi2 uses a lot of swap space, most of it caused by firefox which has a tendency to allocate tons of memory).
HB
This is the output at
)
This is the output at 13:29PM. I will check in a few hours and report.
pi@RasPiSA-100 ~ $ sudo free
total used free shared buffers cached
Mem: 949408 609572 339836 14256 23136 100680
-/+ buffers/cache: 485756 463652
Swap: 1918972 0 1918972
THX
Greetings from the North
RE: This is the output at
)
It's the same info given in top, with just the added convenience of doing the math for you that I outline above. Logging the data (from free or top) in finer intervals would confirm or reject the hypothesis that the crashes are caused by running out of memory (which should only happen after even the swap file is exhausted). The last entry in the log before the crash would be the one to look at, no need to go thru the lengthy log manually (use tail).
HB
Finished! I will give
)
Finished!
I will give up!
Yesterday the System won't make any cronjob for history_log after 12 AM but crunching E@H still running. This morning the System again was bloody low om Memory but still crunching. But, no login on system are possible. After entering the PW the System switched back to login or say's access denied. So I had to initiate a cold/hard reboot. It make no sense to take more time in this System (wheezy/jessie) and I will start from the Beginning with a fresh install on another SD Card with wheezy (without noob/noob-light).
Any chance to get an actual Boinc app for this Distribution (2015-05-05-raspbian-wheezy) or I have to wait for the next Distribution?
THX
Greetings from the North
Yeah, sounds more like a SD
)
Yeah, sounds more like a SD card related problem.
The only thing that is really wrong with the wheezy BOINC version on a Raspi2 is that it won't trigger the download of the NEON optimized app variant, so your options include :
a) live with the somewhat suboptimal BRP app, or
b) use wheezy BOINC, and install NEON optimized app as anonymous platform app (app_info.xml), or
c) compile your own BOINC (as discussed in this thread)
HB