Thank you Krzysztof,

New application works fine on my Raspberry Pi's (both model 3B).
Run times are 11-12 hours for the units completed so far.

Tom

JagDoc, do you think that it will be good try to use 32bit application on 64bit ARM systems? It will probably require to install 32bit libraries...

My Odroid-C2 run long time with the BHspin2_1 app (with "libstdc++6:armhf" installed).
With the new BHspin2_6 app the runtimes was much longer.

Some of the C2 got both BHspin2_6 and BHspin2_7 WUs.

The test outside Boinc same param.in:
BHspin2_7 WU finished after 4h27min.
BHspin2_6 WU is at 50% after 6h25min.

I think the 32bit app is much better for C2.

Just a note for owners of Pi3's.

You can compile your own 64bit kernel and update to 64bit as the Pi3 is 64bit hardware.

Here's my comment Github on how I updated the kernel on my Pi's building for Arm64.
https://github.com/bamarni/pi64/issues/75#issuecomment-397799090

Of course you will need to point your apt sources to the official Debian repos rather than the Raspbian repos as well.

---

https://gridcoin.ddns.net
Rx7Qvpvc7qEZbrHeJ8ukknJo4Gwrc3unBg
Bitshares: g-uk https://wallet.bitshares.org

I am getting "no work available" for my ARM Raspberry Pi's. The server status shows plenty of work.

---

same for windows
edit: finally pulled 1

I assume it's this unfixed problem again:

https://universeathome.pl/universe/forum_thread.php?id=375

All five of my U@H hosts have now run dry.

The boinc server runs simultaneously different daemons to properly work.

Here is a description of each server's daemon :



Hearing the recurrent problem encountered with this project , "No job available" whereas numerous tasks unsent are readable on the server status , it seems that the feeder daemon doesn't have enough time resources to execute its job correctly.When the number of unsent tasks grows up , he needs more time to read the tasks to send and fill up the shared memory.
So , maybe a way to solve this issue would be to increase a little bit the priority of the feeder daemon.
And recursively ,to avoid too much influence on the other daemons , to keep the server stability secure , it would be good to decrease the priority of the download server a little bit .
Modifying slowly the priority may solve the issue but be cautious , keep the default value in memory if the variation you make is too much important and upset the global balance of the server; in order to come back to the previous situation.

Hope it helps you.