Message boards :
Number crunching :
What am I missing in order to get more GPU tasks?
Message board moderation
Author | Message |
---|---|
![]() ![]() Send message Joined: 9 Jul 08 Posts: 85 Credit: 44,842,651 RAC: 0 ![]() ![]() |
I had a chance to pick up a relatively cheap R9 280X GPU and thought, "Great, this thing will be fabulous for MW@H." After much frustration getting it working on a linux machine, I finally had it going. I spent several days trying to figure out why it wasn't getting sufficient work (only from MW@H) and have finally decided that no matter what, the scheduler will never send more than 25 tasks per update and never more than 40 tasks total on the machine. The problem is that's about 7-8 minutes of work depending on the exact mix of tasks sent. It's constantly doing work for lower priority projects and at best it actually spending 5-6% of it's time on MW@H. I can understand projects putting a restriction on number of tasks, though 40 seems awfully low. Is this purposeful, or am I doing something wrong? ![]() |
![]() Send message Joined: 17 Feb 16 Posts: 14 Credit: 11,121,737 RAC: 0 ![]() ![]() |
So you don't have more than 40 tasks in progress? I just looked and your fastest machine is showing 20 tasks in progress. My fastest machine has 64 right now. (and yours is faster) I wonder if you need to change a setting like under network usage under boinc computing preferences, the "Maintain enough tasks to keep busy for at least". I have it set for .5 days. I think default was .1 days. |
![]() ![]() Send message Joined: 9 Jul 08 Posts: 85 Credit: 44,842,651 RAC: 0 ![]() ![]() |
Yeah, I've tried increasing that, but it didn't have any effect. Well, I did see an increase in CPU tasks, but 40 still seems to be some sort of "hard limit" on GPU. ![]() |
![]() ![]() Send message Joined: 9 Jul 08 Posts: 85 Credit: 44,842,651 RAC: 0 ![]() ![]() |
Correction: I got a boatload of tasks for OTHER projects (including GPU tasks), but no more for MW@H. :-( ![]() |
![]() ![]() Send message Joined: 9 Jul 08 Posts: 85 Credit: 44,842,651 RAC: 0 ![]() ![]() |
Well, never mind (for now). Several hours after making that change, the computer finally started doing a work fetch every 4-5 minutes, so it's finally keeping itself fed without me having to hit a manual update every few minutes. I'm not entirely sure how this change brought about that behavior, but I'm going to let it do it's thing overnight and see what happens. :-) ![]() |
![]() Send message Joined: 11 Feb 11 Posts: 57 Credit: 69,475,644 RAC: 0 ![]() ![]() |
the amount of tasks received from milkyway@home is restricted by your cpu core count. i think it's something like 10 or 12 tasks/core |
Send message Joined: 21 Dec 12 Posts: 3 Credit: 207,504,988 RAC: 0 ![]() ![]() |
That's not right. When I'm crunching MW@H, every machine I have gets a maximum of 40 tasks. Most of my machines have 2 cores, but I have 3 with 4 cores and 1 with 8 cores. There is another restriction somewhere that limits the amount of "in progress" work this projects allows on a machine at any one time. If it's a setting in the various config files, I've yet to find it. |
![]() ![]() Send message Joined: 8 May 09 Posts: 3339 Credit: 524,010,781 RAC: 14 ![]() ![]() ![]() |
That's not right. When I'm crunching MW@H, every machine I have gets a maximum of 40 tasks. Most of my machines have 2 cores, but I have 3 with 4 cores and 1 with 8 cores. There is another restriction somewhere that limits the amount of "in progress" work this projects allows on a machine at any one time. If it's a setting in the various config files, I've yet to find it. And you won't because it's on the Server side!! Each Project can change it as they see fit, most keep it low to keep one or two people from setting their cache to the max of 10 days while having 64 or more cpu's or as many as 8 gpu's and sucking up all the available workunits. Giving everyone some is much better than giving a few people ALOT, at least as far as keeping lots of people crunching. It just means the Projects have to keep their work generators going to keep up with us. |
Send message Joined: 25 Feb 13 Posts: 580 Credit: 94,200,158 RAC: 0 ![]() ![]() ![]() |
Hey guys, With how fast GPU work units are now, I will look into bumping up the number of work units you can get. Jake W. [edit] I doubled the number of GPU work units that can be downloaded (to 80) and increased the total number of work units that can be downloaded to 150 from 100. If this still doesn't feel like enough, I can tweak it more. Happy Crunching. [/edit] |
![]() ![]() Send message Joined: 8 May 09 Posts: 3339 Credit: 524,010,781 RAC: 14 ![]() ![]() ![]() |
Hey guys, Thankyou very much!!! |
![]() ![]() Send message Joined: 9 Jul 08 Posts: 85 Credit: 44,842,651 RAC: 0 ![]() ![]() |
Thank you Jake. The weird behavior that I've been fighting on this machine is that it only seems willing to make a scheduler request about once an hour. Generally the server only seems able to send about 20-25 tasks at a time, so even though the max possible to have is 80 now, it's still only doing about 20-25 tasks per hour (that's roughly 4-6 minutes of work). For one brief shining moment I actually saw it doing scheduler requests on it's own about every 5 minutes, but that was literally for a period of about 1 hour in the month or so it's been running. I've tried increasing the work cache (at the moment it's set for .6 days and .6 additional), but that doesn't seem to change the behavior. (Not that I think it would, because the limit on tasks winds up being roughly .02 days) If anyone has a solution/suggestion, I'm still trying to figure it out. :-) ![]() |
![]() Send message Joined: 11 Apr 15 Posts: 58 Credit: 63,291,127 RAC: 0 ![]() ![]() |
Hello together, before the change my host was able to get 92 tasks, 40 tasks * 2 GPUs = 80, ergo 92 - 80 = 12 WUs for my 4 cores, meaning ONLY 3(!!) WUs per core. After the change the same host gets 172 tasks, 80 tasks * 2 GPUs = 160, ergo 172 - 160 = 12 WUs for 4(!!) cores, meaning STILL ONLY 3 WUs per core. This is waaay too low IMHO. :? Best regards, Uli Aloha, Uli |
![]() ![]() Send message Joined: 9 Jul 08 Posts: 85 Credit: 44,842,651 RAC: 0 ![]() ![]() |
I guess the short version of what I'm saying is; It doesn't change anything to increase the maximum WU's allowed to have on hand to 1 meeeeelion (said in my best Dr. Evil voice) if the server doesn't actually have work to send. Perhaps the issue is that work is being generated as fast as the project needs (or can handle). If that's the case, then just keep on plugging away. I'll crunch what I can, as I can get it. However, if the project could handle more work being done faster, then the solution is to increase the amount ready to send. ![]() |
Send message Joined: 25 Feb 13 Posts: 580 Credit: 94,200,158 RAC: 0 ![]() ![]() ![]() |
Hey guys, Okay. I made some more changes to the server configuration. You should be able to poll for new work units every half hour and still get 150 work units at a time. Hopefully, this will help. Jake W. |
![]() ![]() Send message Joined: 24 Jan 11 Posts: 712 Credit: 551,844,830 RAC: 44,554 ![]() ![]() ![]() ![]() |
Hey guys, +1 ![]() |
![]() ![]() Send message Joined: 24 Jan 11 Posts: 712 Credit: 551,844,830 RAC: 44,554 ![]() ![]() ![]() ![]() |
Hey guys, Very nice development IMHO. The latest change in polling interval I would think hammers the scheduling and download servers less and doesn't seem to affect how many GPU work units are on board my crunchers. Good job, Jake. ![]() |
![]() ![]() Send message Joined: 9 Jul 08 Posts: 85 Credit: 44,842,651 RAC: 0 ![]() ![]() |
It appears to be deferring communication for 1 hour after an update, not 30 minutes. (Admittedly this is just an anecdotal observation from one client machine) ![]() |
![]() Send message Joined: 11 Apr 15 Posts: 58 Credit: 63,291,127 RAC: 0 ![]() ![]() |
It appears to be deferring communication for 1 hour after an update, not 30 minutes. I can second that, the server defers communication for 1 hour. Aloha, Uli |
![]() ![]() Send message Joined: 9 Jul 08 Posts: 85 Credit: 44,842,651 RAC: 0 ![]() ![]() |
Well (again), I'm trying not to complain, but for me at least, this has actually made it much worse. (I'm thinking I should have just kept my big mouth shut about now.) ;-) I finally updated (after waiting an hour) and the server had 38 tasks available to send (for this machine, about 4-5 minutes of work). This is why a limit of 40, 80 or even 150 tasks is functionally irrelevant (if I can only get 5 minutes of work once per hour). In an hour, it might have 150 tasks to send (though highly doubtful). It might have 21. It might have 25. It might have 1 or even 0 (I've seen this many times). ![]() |
Send message Joined: 11 Oct 09 Posts: 19 Credit: 202,475,569 RAC: 0 ![]() ![]() ![]() |
A grand total of 7 units here. 3 minutes of processing and a 50-minute wait for the next batch. |
©2024 Astroinformatics Group