Posts by G_UK

1) Message boards : Number crunching : ARM 64 bit WU failures (Message 814)
Posted 19 Feb 2019 by G_UK
Post:
On my Pi3's running a 64bit kernel the project keeps downloading the 32 bit version of JRE (jre-1.8.0-arm32hf.zip) rather than a 64bit version.

I can get the project to run by enabling ArmHF multi-arch.
sudo dpkg --add-architecture armhf && sudo apt update


And then installing the ArmHF version of libc6.
sudo apt install libc6:armhf


Obviously it would be better if we could get it to run in 64bit rather than 32bit.
2) Message boards : Number crunching : Max Work Units, Project Preferences (Message 379)
Posted 21 Aug 2018 by G_UK
Post:
Thanks Henk, I'll give that a go. Hopefully the work scheduler is smart enough!!
3) Message boards : Number crunching : Arm64 (Message 371)
Posted 20 Aug 2018 by G_UK
Post:
OK, Thank You, I look forward to possible future Arm64 support in BOINC.

I need to run the project through BOINC as I am also hoping that the project will be Whitelisted with Gridcoin in the not to distant future.
4) Message boards : Number crunching : Max Work Units, Project Preferences (Message 370)
Posted 20 Aug 2018 by G_UK
Post:
Thank You for the response, my point was more to work around the limitations of the BOINC scheduler as I am aware that the DHEP work units are dummies for the actual process.

For example:
- The BOINC scheduler will see each work unit as requiring 1 core.
- On a 12 core machine that runs multiple BOINC projects, to get DHEP to always run I have to set the projects work share priority to maximum (99999).
- Unfortunately the BOINC scheduler then thinks it needs to download enough work for all 12 cores on the system.
- I can restrict the project to only run one concurrent task using the app_config.xml however BOINC still thinks that it has already downloaded enough work (as it has 12 cores worth of work units) and refuses to download work for the other cores from the other projects, leaving the remaining 11 cores idle.

My workaround currently is to suspend the excess work units and only resume them one by one as and when the running work unit ends. Suspending the work units frees up the scheduler to get work from other projects and it will not get any more DHEP work units whilst they are suspended. Ideally I would like to only fetch one work unit at a time so that the scheduler doesn't mess up.

It's not a big issue as it has no negative affect on the project as the suspended work units are just empty dummies and I can live with the manual intervention of suspending and resuming work units every so often. It's more just a minor quality of life update.

If anyone else knows another way of setting up BOINC to only download and run on one core all the time, this could you let me know please, it would be appreciated. (Running the standalone application isn't an option in this case)
5) Message boards : Number crunching : Arm64 (Message 365)
Posted 19 Aug 2018 by G_UK
Post:
Would it be possible to provide work units for Linux on Arm64?

As the tasks are Java based I wouldn't think it would be too difficult to read across from the Linux on x64 app.

Personally I have 12 RPi 3B's running a 64bit kernel and would be happy to dedicate a core on each to this project. Currently they are all running BOINC on between 2-4 cores depending on other workload they are doing.
6) Message boards : Number crunching : Max Work Units, Project Preferences (Message 364)
Posted 19 Aug 2018 by G_UK
Post:
Would it be possible to add an option to the project preferences to be able to limit the number of concurrent work units sent to hosts.

I would like to keep one core on each machine dedicated to DHEP whilst the rest do other BOINC work, today I can do this by doing the following work-around:

1) Set Project Resource Share to 99999
2) Set up an app_config.xml with project_max_concurrent set to 1

Unfortunately as the BOINC scheduler doesn't read the app_config.xml it downloads work for all cores and then only runs one at a time. So I then have to:

3) Suspend the "spare" tasks.

LHC@Home has a project preference that limits the number of CPU cores it sends work out to, similar on this project would be helpful.




©2019