Thread 'My Wish List'

Message boards : BOINC client : My Wish List
Message board moderation

To post messages, you must log in.

Previous · 1 . . . 4 · 5 · 6 · 7 · 8 · Next

AuthorMessage
ProfileJord
Volunteer tester
Help desk expert
Avatar

Send message
Joined: 29 Aug 05
Posts: 15569
Netherlands
Message 64154 - Posted: 9 Sep 2015, 21:43:49 UTC - in response to Message 64153.  
Last modified: 9 Sep 2015, 21:46:13 UTC

The projects that use VirtualBox don't all work correctly with the newest version of VirtualBox, hence why BOINC has an older but trusted version included.
ID: 64154 · Report as offensive
cristipurdel

Send message
Joined: 26 Oct 09
Posts: 67
Romania
Message 64384 - Posted: 20 Sep 2015, 9:36:46 UTC

When comparing the BOINC app with the NativeBOINC, there are some features that are missing:

1. Option for "Set up hostname", which is useful especially if using bam with a lot of android devices (in my case more than 10)

2. RAM management. In NativeBOINC I am running WCG FAAH which in theory needs 250 MB, but actually needs around 40 MB. The BOINC app checks if the mobile device has 250 MB available (in my case on an old Samsung Galaxy 1, with 370MB RAM, out of which 185MB is used for system), and if it does not comply, will not start the project app. I find the NativeBOINC implementation (or workaround) the best option for RAM constrained devices.
ID: 64384 · Report as offensive
SekeRob2

Send message
Joined: 6 Jul 10
Posts: 585
Italy
Message 64385 - Posted: 20 Sep 2015, 11:40:57 UTC - in response to Message 64384.  

The hostname change is a hack i.e. Google could break it anytime without notice [It has in a way since NativeBOINC was never ported to the PIE [Position Independent Executables] memory compliance model and thus does not run beyond Android 4.4]. You can change the host-name by rooting your devices [which results in loss of everything stored i.e. you have to rebuild the whole setup].

As for memory and how NB handles works-arounds (?), do not know [forgot since my Lollipop can't run it]. Minima by WCG are set for the possible maximum 'Just in case' work units. There's no 100% predicting how big or small any individual unit will be [non-deterministic computing]. If then having a set of 'harder to crunch', this could lead to serial failing and swamping the system with repairs which is a big problem for continuity [and lots of complaints for various reasons such as tasks failing].
Coelum Non Animum Mutant, Qui Trans Mare Currunt
ID: 64385 · Report as offensive
cristipurdel

Send message
Joined: 26 Oct 09
Posts: 67
Romania
Message 64430 - Posted: 22 Sep 2015, 19:28:41 UTC - in response to Message 64385.  
Last modified: 22 Sep 2015, 19:31:25 UTC

My feeling is that the 'Just in case' scenario of 250MB is a bit misleading. It can affect for example low RAM smartphones like: 1C 250MB, 2C 500MB, 4C 1GB, 8C 2GB. I also see on a SGS6 with 3 GB of RAM, the OS is taking around 1.5GB with apps installed, leaving 1.5GB of RAM for 8 Cores, so less than 250MB/Core. I would prefer to have the 'Just in case' scenario replaced with a warning message but still bypass this limitation and leave the app to crunch.
Plus based on this http://wuprop.boinc-af.org/results/ram.py?plateforme=android&tri=2&sort=desc the most demanding app does not use more than 125MB, so kind of pointless to have a 'Just in case' 250MB RAM with a low probability.
What really annoys me is that although I have 180 MB RAM free, I cannot crunch due to the smartphone being to old, but the WCG app is on averaging taking 37MB RAM. I really don't want to run collatz on it :)
ID: 64430 · Report as offensive
samos

Send message
Joined: 5 Sep 15
Posts: 6
Australia
Message 64640 - Posted: 3 Oct 2015, 0:42:01 UTC
Last modified: 3 Oct 2015, 0:42:48 UTC

I'd like to be able to set a 'backoff delay' for BOINC compared to system bootup (say delay in minutes from zero to 60 for example) so that BOINC won't load/startup until x-number of minutes from Windows startup.

I find that due to the heavy load-demands of BOINC and/or projects, it does slow system boot up, when it shouldn't need to. I often snooze it during boot up so that my normal boot up completes before allowing BOINC to resume. In my case, it is the disk usage that delays regular Windows startup, and snoozing BOINC during startup relieves it quite a lot.

Otherwise, a setting so that it will only do the 'heavy loading' once the screensaver activates for example?

[Edit: typo]
ID: 64640 · Report as offensive
Jim1348

Send message
Joined: 8 Nov 10
Posts: 310
United States
Message 64641 - Posted: 3 Oct 2015, 1:45:14 UTC - in response to Message 64640.  

I'd like to be able to set a 'backoff delay' for BOINC compared to system bootup (say delay in minutes from zero to 60 for example) so that BOINC won't load/startup until x-number of minutes from Windows startup.

You can use Startup Delayer for that.
http://www.r2.com.au/page/products/page/2/show/startup-delayer/
ID: 64641 · Report as offensive
Juha
Volunteer developer
Volunteer tester
Help desk expert

Send message
Joined: 20 Nov 12
Posts: 801
Finland
Message 64652 - Posted: 3 Oct 2015, 13:51:25 UTC - in response to Message 64640.  

<start_delay> should do it. BOINC will still start normally but it will wait before starting science apps.
ID: 64652 · Report as offensive
cristipurdel

Send message
Joined: 26 Oct 09
Posts: 67
Romania
Message 65531 - Posted: 21 Nov 2015, 9:08:26 UTC

I would like to see an option in BOINC for Android smth like:
Stop task after checkpoint when running on battery

I am running boinc on 7/8 cores on a mobile device, also while on batteries. While running for WCG, tasks are taking around 12 hours, with 1.5 hours per checkpoint. Since I have a limitation on the battery, around 50%, the phone will disregard the progress from the last checkpoint when it reaches 50%.
Worst case scenario is that all 7 cores are short by 1 minute before the next checkpoint, when the battery limitations kicks in, so around 10 hours of crunching is wasted.
IMO it will be a more efficient way to compute and conserve the battery.
ID: 65531 · Report as offensive
Jim1348

Send message
Joined: 8 Nov 10
Posts: 310
United States
Message 67790 - Posted: 16 Feb 2016, 15:57:02 UTC

When I suspend a GPU task for a given project (e.g., Einstein), it prevents the downloading of both new GPU tasks and new CPU tasks.

I suggest that this function be separated, and that suspending a GPU task prevents only the downloading of a new GPU task, but allows downloading CPU tasks. If you want to prevent the downloading of both, you can do that in the normal fashion of "No new tasks".
ID: 67790 · Report as offensive
ProfileJord
Volunteer tester
Help desk expert
Avatar

Send message
Joined: 29 Aug 05
Posts: 15569
Netherlands
Message 67791 - Posted: 16 Feb 2016, 16:04:14 UTC - in response to Message 67790.  

There are no separate GPU and CPU tasks. At the moment of downloading work to your computer, it's decided what it's appointed to, the CPU or the GPU. So these cannot be separated.
ID: 67791 · Report as offensive
Jesse Viviano

Send message
Joined: 14 Feb 11
Posts: 63
United States
Message 69578 - Posted: 13 May 2016, 14:02:24 UTC

Nvidia drivers between 364.47 through 365.19 have a buggy PTX to GPU machine code compiler which causes them to miscalculate in GPGPU loads including CUDA and OpenCL loads. See http://www.primegrid.com/forum_thread.php?id=6775&nowrap=true for evidence. Kepler and Fermi cards are not affected because they use different PTX to GPU machine code compilers tailored to their different internal machine codes. The math bug has been fixed in Nvidia's internal development driver, but the fix came in too late to be included in released driver 365.19. The next driver will fix the math bug.

I therefore think that the client should have a blacklist of known bad driver versions that when detected will cause the BOINC client to refuse to fetch GPU work units and abort any GPU work units that have not been finished.

Optionally, entries should be paired with a list of GPU architectures, compute capabilities, or GPU names of what are affected. For example, these drivers' entries could have a restriction that the CUDA compute capability must be 5.* in order to blacklist these drivers only for Maxwell-based GPUs because these drivers do not miscalculate when paired with GPUs based on the Kepler or Fermi architectures. Maxwell-based cards have CUDA compute capabilities 5.0, 5.2, and 5.3. Kepler-based cards have compute capabilities 3.0, 3.2, 3.5, and 3.7.
ID: 69578 · Report as offensive
SekeRob2

Send message
Joined: 6 Jul 10
Posts: 585
Italy
Message 69579 - Posted: 13 May 2016, 15:53:39 UTC - in response to Message 37251.  
Last modified: 13 May 2016, 15:58:00 UTC

-- (Is there a way to make a forum thread open at the last post in chronological order? [WCG forums do]! Open thread, replied, but it was to the last post on page 1 ).
Coelum Non Animum Mutant, Qui Trans Mare Currunt
ID: 69579 · Report as offensive
ProfileRichie

Send message
Joined: 2 Jul 14
Posts: 186
Finland
Message 74426 - Posted: 27 Nov 2016, 15:17:16 UTC

I don't know if this suits well in this thread, but...

I wish there would be more than four possible 'locations' available some day. I feel four is not much at all. There are interesting applications available, but at the same time there are a hosts with different types of hardware (AMD or Nvidia GPU, different amount of RAM etc). It could be much easier to make plans and try different kind of app combinations, if there was a possibility to save different settings for 6-8 'locations' per project.
ID: 74426 · Report as offensive
Jesse Viviano

Send message
Joined: 14 Feb 11
Posts: 63
United States
Message 76385 - Posted: 12 Mar 2017, 18:44:54 UTC

BOINC needs to be made NUMA aware especially now since AMD's Ryzen processors appear to act as if they are dual CPU socket systems according to https://www.pcper.com/reviews/Processors/AMD-Ryzen-and-Windows-10-Scheduler-No-Silver-Bullet. Basically, current Ryzen processors are structured into two core complexes, or CCXs for short, consisting of 4 cores per CCX. Tightly interlocked multithreaded workloads will suffer massive latencies if some of the threads are spread across the CCXs because . Loosely interlocked multithreaded workloads will benefit from multiple cores because they do not spend much time communicating between threads. This work will also benefit Intel Xeon processors that are set up to use cluster on die mode as seen in http://www.anandtech.com/show/8423/intel-xeon-e5-version-3-up-to-18-haswell-ep-cores-/4, any multi CPU socket system, and old Core 2 Quads (which have two dual core CPU dies in one package).
ID: 76385 · Report as offensive
boboviz
Help desk expert

Send message
Joined: 12 Feb 11
Posts: 419
Italy
Message 76464 - Posted: 15 Mar 2017, 11:30:02 UTC - in response to Message 76385.  

BOINC needs to be made NUMA aware especially now since AMD's Ryzen processors appear to act as if they.... This work will also benefit Intel Xeon processors that are set up to use cluster on die mode....


Seems that Numa is an old request:
https://github.com/BOINC/boinc/issues/1357
http://boinc.berkeley.edu/dev/forum_thread.php?id=10124#60953

I don't understand if Numa is now supported or not
ID: 76464 · Report as offensive
Toby Broom

Send message
Joined: 14 Apr 12
Posts: 51
Switzerland
Message 77249 - Posted: 9 Apr 2017, 17:32:23 UTC

Can the boinccmd --get_tasks report the number of CPU/GPU cores used by the task?
ID: 77249 · Report as offensive
ProfileJord
Volunteer tester
Help desk expert
Avatar

Send message
Joined: 29 Aug 05
Posts: 15569
Netherlands
Message 77250 - Posted: 9 Apr 2017, 19:25:35 UTC - in response to Message 77249.  

Amount of CPU cores is normally just one per task, unless the task is using a multithreaded application, and then it's all cores.
For GPUs it's always a minimum of one GPU per task, even when you run multiple tasks on a GPU, it's all the stream/CUDA cores that run each task.
ID: 77250 · Report as offensive
Toby Broom

Send message
Joined: 14 Apr 12
Posts: 51
Switzerland
Message 77263 - Posted: 10 Apr 2017, 6:48:57 UTC - in response to Message 77250.  

Some project are non cpu intensive and the multithreaded ones can be limited to a specificed number of cores so I would like to know how it's all working.
ID: 77263 · Report as offensive
HAL9000
Help desk expert
Avatar

Send message
Joined: 13 Jun 14
Posts: 81
United States
Message 77288 - Posted: 11 Apr 2017, 2:45:46 UTC - in response to Message 76464.  
Last modified: 11 Apr 2017, 3:11:50 UTC

BOINC needs to be made NUMA aware especially now since AMD's Ryzen processors appear to act as if they.... This work will also benefit Intel Xeon processors that are set up to use cluster on die mode....


Seems that Numa is an old request:
https://github.com/BOINC/boinc/issues/1357
http://boinc.berkeley.edu/dev/forum_thread.php?id=10124#60953

I don't understand if Numa is now supported or not

On my dual Xeon systems BOINC seems to run fine across both NUMA nodes.
I did try a few tests comparing NUMA enabled and disabled. I didn't see anything difference between the two configurations when processing project tasks.
ID: 77288 · Report as offensive
cristipurdel

Send message
Joined: 26 Oct 09
Posts: 67
Romania
Message 78568 - Posted: 3 Jun 2017, 20:55:39 UTC
Last modified: 3 Jun 2017, 21:06:44 UTC

I would like to have an option in the manager smth like:
After being idle for X min, set PState to the lowest level (basically set all cpu freq to idle) and run tasks on Y cores.
Although the freq will be around 800MHz, it is still better than nothing when having lots of threads.
Plus the power efficiency should be , ideal from point of view of efficiency :).
For example, on a Core i7-6820HQ
running on all 8 threads, TDP = 45W at 3.2GHz
running on all 8 threads, TDP = 15W at 0.8GHz
on idle, TDP = 13W at 0.8GHz
And also add an option to specify which frequency should be set for all cpus, like the new option in Windows Creators update: maximum processor frequency
ID: 78568 · Report as offensive
Previous · 1 . . . 4 · 5 · 6 · 7 · 8 · Next

Message boards : BOINC client : My Wish List

Copyright © 2024 University of California.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.