Posts by Bryan

1) Message boards : Number crunching : Respect My Limits! (Message 3899) Posted 31 Jul 2016 by Bryan Post: Not a problem Laurence. Under commitment is an annoyance but over commitment is unacceptable :) You have to beat down the big problems 1st then you can worry about finessing the rest!
2) Message boards : Number crunching : Respect My Limits! (Message 3872) Posted 30 Jul 2016 by Bryan Post: Please post here any issues relating to the BOINC client assigning too much or too little work based on your preferences. I apologize for getting off topic Laurence. Your original post said "too much" or "too little" so I assumed you were interested in the later. I'll butt out :)
3) Message boards : Number crunching : Respect My Limits! (Message 3870) Posted 29 Jul 2016 by Bryan Post: Wow, all I can say is you guys are responsive :) As I stated earlier, I really am not wishing to be negative ... you asked for feedback of what some of us would like to see and that is what I'm stating. Nothing says that my requests are even feasible ... I can certainly accept that! BOINC, on a normal project, will support all 72 threads (Linux). VBox only supports 36 threads in a single VM. That really isn't a limitation however. VBox takes a huge, 30%, performance hit when working across multiple processors. For example, it is far better on a 24 thread machine to run 2 VM w/ 12 threads rather than a single VM w/ 24 threads. Windows on the other hand only supports 64 threads due to their NUMA implementation. BOINC will let you start 72 threads but the reality is NUMA is going to run those 72 WU using 64 threads. When it 1st came out I tried running the new MT WU. I don't have a problem with it only using 8 threads (although I do have 5 12 thread machines). What I objected to was the fact the project would allow me to chew on 1 WU at a time while there were 24 more downloaded and waiting to run. Now part of this is due to way I prefer to run my machines. I very seldom have multiple projects running on a single machine. When I move onto a project I prefer to hammer it with all the machine has and that way I'm not having to baby sit different projects and the BOINC scheduler. To give an example on the regular VLHC project. It downloads 2 WU with no spares. Assume I'm running a 2nd project on the remaining threads and that project doesn't checkpoint (ie prime search). When a VLHC WU finishes it must upload and then download the new WU. In the meantime the BOINC scheduler sees there is a free thread so it starts a new prime WU that can't be interrupted. So when the new VLHC WU downloads it sits there waiting until one of the threads crunching a prime becomes available. BTW, setting a high priority on VLHC vs the prime program buys nothing since BOINC sees an idle thread with only work available from the prime program. In order to solve this problem I'm required to go into the prime project's folder and create a app_config file that limits it to maximum of 70 WU. That way 2 threads are left free for VLHC to accommodate upload/download times. So all I'm trying to do is give you some perspective of what it is like on this side of the fence :) BTW, when I was still working ... quite a few years ago, I made multiple trips to your facility. I worked for HP Test & Measurement which became Agilent and now is called Keysight. Fantastic experience every time I visited. NOTE: I just started up the MT app and it is only running 1 WU. However, BOINC is showing it is using 64 cores (threads). So if the WU is actually only using 8 threads then that is why it won't start more WU. BOINC thinks there are no threads available.
4) Message boards : Number crunching : Respect My Limits! (Message 3862) Posted 29 Jul 2016 by Bryan Post: I have 9 boxes that are dedicated "crunching" machines. This is my hobby. I find it extremely frustrating to have 2 72 thread machines with 128G of memory and I can use a max of 8 threads. I have 3 other Xeon machines with 24 threads and 48G of memory and of course they have the same problem. The main project is even worse, it allows me 2 WU total. The BOINC scheduler is not the most brilliant piece of code ever written. If I am running VLHC I usually run another project so I don't have threads sitting idle. In order to keep things operating correctly and requesting work when needed it requires that I setup a app_config file on the 2nd project to make sure that it doesn't encroach on VLHC and work gets requested when needed. There is a lot of crunching power you have access to if you remove the current limits. Set up a check box in the "project preference section" where people can limit what gets sent to their machines. BTW, I do NOT run my 204 threads on the main VLHC project because it isn't worth my time and effort for 2 WU. This really applies here as well. I came back when I saw you had introduced MT tasks only to find the 8 thread limit. I'm not intending to be nasty, I just want to point out that there is potential for far more computing power if you give the flexibility to your volunteers so they can get the amount of work they desire - whether in small/large amounts.

Development for LHC@home