Message boards :
News :
ATI application updated again
Message board moderation
Author | Message |
---|---|
Send message Joined: 8 May 10 Posts: 576 Credit: 15,979,383 RAC: 0 |
I've updated the new ATI application to 0.59. This fixes the 100% CPU problem, and adds a command line flag -r I'm not exactly happy with how it decides to break the problem down to keep the screen responsive; I think how it's done now can still cause slowdowns on some GPUs (and is kind of fragile), and you shouldn't have to do anything to keep things responsive. I'm not really sure the best way to do it. If you feel you actually need to use this, complaints here with what GPU you have might be useful. |
Send message Joined: 9 Sep 08 Posts: 96 Credit: 336,443,946 RAC: 0 |
Are the old .57 WU's going to get credit or do we abort them... they show as 'Not in DB' under Application. |
Send message Joined: 8 May 10 Posts: 576 Credit: 15,979,383 RAC: 0 |
Are the old .57 WU's going to get credit or do we abort them... they show as 'Not in DB' under Application.Just the application changed. The workunits aren't actually associated with the version so it should work fine. |
Send message Joined: 14 Feb 09 Posts: 999 Credit: 74,932,619 RAC: 0 |
Will the command line options from 0.23 work with the new version? One can configure the app through some parameters in the supplied app_info.xml. |
Send message Joined: 24 Feb 09 Posts: 620 Credit: 100,587,625 RAC: 0 |
2x5970s (790/500) on a 1090T @3.7Ghz - first thoughts after a few. I am running some PRPNet on the CPUs - same as I was with 0.23 - so its a sort of level playing field, as such. The GPU utilisation appears to be way down - runs at about 50-60%. Heat is no issue, probably because of the low utilisation, but its the coolest I've ever seen with MW GPU WUs. I had no screen lag at all, and also loaded a couple of browsers with no noticeable effect re lag - so that seems fine, but bare in mind its against 2x5970s.... Overall speed compared to 0.23 seemed to be about 25 - 30% slower, I ran it at the same gpu/memory settings as I used for 0.23 so a comparison could be seen. It maybe the new app needs higher gpu/memory, dont know yet. Looks like its still cpu bound(ish) as useage is way higher than 0.23, at least with 5970s set with CPUs running PRPNet (PRPNet took a 30% hit slowing down while 0.57 was running). Regards Zy |
Send message Joined: 15 Jul 08 Posts: 383 Credit: 729,293,740 RAC: 0 |
I've updated the new ATI application to 0.59. This fixes the 100% CPU problem, and adds a command line flag -r <some number> or --responsiveness-factor <some number>. This number just multiplies the estimate for how long things are expected to take to decide how to break things into smaller pieces to allow the screen a chance to redraw. Numbers greater than 1 should make things more responsive. 0 ignores any need for responsiveness for maximum speed. 1) What's the default? 2) And would it be something like: <cmdline>-r0</cmdline> in an app_info.xml for maximum speed? And thanks! |
Send message Joined: 8 May 10 Posts: 576 Credit: 15,979,383 RAC: 0 |
Will the command line options from 0.23 work with the new version?This is a complete rewrite since we never had the source for that. I've never seen these options for the old one before, but I'll look into it. For right now there's only this quick little thing I just added. |
Send message Joined: 8 May 10 Posts: 576 Credit: 15,979,383 RAC: 0 |
1) What's the default?1 2) And would it be something like:Yes |
Send message Joined: 8 May 10 Posts: 576 Credit: 15,979,383 RAC: 0 |
Overall speed compared to 0.23 seemed to be about 25 - 30% slower, I ran it at the same gpu/memory settings as I used for 0.23 so a comparison could be seen. It maybe the new app needs higher gpu/memory, dont know yet.It's been about the same speed for me, but I just ran a few units myself in BOINC and noticed this slowdown on the same GPU. |
Send message Joined: 24 Feb 09 Posts: 620 Credit: 100,587,625 RAC: 0 |
..... It's been about the same speed for me, but I just ran a few units myself in BOINC and noticed this slowdown on the same GPU. Same 0.23? or roughly the speed I noticed? I'm just trying to guage what the "new" baseline is to setup the 5970s for 0.57 EDIT: uppps - sorry typo, meant 0.59 Regards Zy |
Send message Joined: 30 Dec 07 Posts: 311 Credit: 149,490,184 RAC: 0 |
0.59 still using one full CPU core per task on my computer. Xeon 3520, HD 5970, Win 7 64, Cat 11.4 |
Send message Joined: 24 Aug 10 Posts: 181 Credit: 83,101,286 RAC: 0 |
|
Send message Joined: 16 Nov 10 Posts: 17 Credit: 17,999,210 RAC: 0 |
The new app takes care of the CPU over utilization, thank you. It doesn't hammer the GPU as hard as 0.23 did resulting in a little longer run time, but a more responsive system and a cooler card. Fair trade off, I even think it's better for a non-dedicated cruncher. I'm still having the problem with the app bullying and beating its way to the top of the queue mentioned in post 47501. I enabled <coproc_debug> and following is a snip of the output. Any ideas? 4/10/2011 9:55:03 PM | SETI@home | [coproc] Assigning ATI instance 0 to 17fe11ac.25226.11519.15.10.5_0 4/10/2011 9:55:03 PM | SETI@home | Restarting task 17fe11ac.25226.11519.15.10.5_0 using setiathome_enhanced version 610 4/10/2011 9:55:06 PM | Milkyway@home | Sending scheduler request: To fetch work. 4/10/2011 9:55:06 PM | Milkyway@home | Reporting 1 completed tasks, requesting new tasks for ATI GPU 4/10/2011 9:55:07 PM | Milkyway@home | Scheduler request completed: got 1 new tasks 4/10/2011 9:55:09 PM | Milkyway@home | [coproc] Assigning ATI pending instance 0 to de_separation_10_3s_fix10_1_500170_1302486546_1 4/10/2011 9:55:09 PM | SETI@home | [coproc] ATI device 0 already assigned: task 17fe11ac.25226.11519.15.10.5_0 4/10/2011 9:55:10 PM | Milkyway@home | [coproc] Assigning ATI instance 0 to de_separation_10_3s_fix10_1_500170_1302486546_1 4/10/2011 9:55:10 PM | Milkyway@home | [coproc] Assigning ATI instance 0 to de_separation_10_3s_fix10_1_500170_1302486546_1 ... >> This line repeats several hundred times << ... 4/10/2011 9:55:10 PM | Milkyway@home | [coproc] Assigning ATI instance 0 to de_separation_10_3s_fix10_1_500170_1302486546_1 4/10/2011 9:55:10 PM | Milkyway@home | [coproc] Assigning ATI instance 0 to de_separation_10_3s_fix10_1_500170_1302486546_1 4/10/2011 9:55:10 PM | Milkyway@home | Starting de_separation_10_3s_fix10_1_500170_1302486546_1 4/10/2011 9:55:10 PM | Milkyway@home | Starting task de_separation_10_3s_fix10_1_500170_1302486546_1 using milkyway version 59 4/10/2011 9:55:38 PM | Milkyway@home | [coproc] ATI instance 0: confirming for de_separation_10_3s_fix10_1_500170_1302486546_1 4/10/2011 9:56:09 PM | Milkyway@home | [coproc] ATI instance 0: confirming for de_separation_10_3s_fix10_1_500170_1302486546_1 4/10/2011 9:56:25 PM | Milkyway@home | [coproc] ATI instance 0: confirming for de_separation_10_3s_fix10_1_500170_1302486546_1 4/10/2011 9:57:25 PM | Milkyway@home | [coproc] ATI instance 0: confirming for de_separation_10_3s_fix10_1_500170_1302486546_1 4/10/2011 9:57:38 PM | Milkyway@home | [coproc] ATI instance 0: confirming for de_separation_10_3s_fix10_1_500170_1302486546_1 4/10/2011 9:58:09 PM | Milkyway@home | [coproc] ATI instance 0: confirming for de_separation_10_3s_fix10_1_500170_1302486546_1 4/10/2011 9:58:25 PM | Milkyway@home | [coproc] ATI instance 0: confirming for de_separation_10_3s_fix10_1_500170_1302486546_1 4/10/2011 9:58:32 PM | Milkyway@home | [coproc] ATI instance 0: confirming for de_separation_10_3s_fix10_1_500170_1302486546_1 4/10/2011 9:58:55 PM | Milkyway@home | [coproc] ATI instance 0: confirming for de_separation_10_3s_fix10_1_500170_1302486546_1 4/10/2011 9:59:01 PM | Milkyway@home | Computation for task de_separation_10_3s_fix10_1_500170_1302486546_1 finished 4/10/2011 9:59:01 PM | SETI@home | [coproc] Assigning ATI instance 0 to 17fe11ac.25226.11519.15.10.5_0 4/10/2011 9:59:01 PM | SETI@home | Restarting task 17fe11ac.25226.11519.15.10.5_0 using setiathome_enhanced version 610 4/10/2011 9:59:03 PM | Milkyway@home | Sending scheduler request: To fetch work. 4/10/2011 9:59:03 PM | Milkyway@home | Reporting 1 completed tasks, requesting new tasks for ATI GPU 4/10/2011 9:59:04 PM | Milkyway@home | Scheduler request completed: got 1 new tasks 4/10/2011 9:59:07 PM | Milkyway@home | [coproc] Assigning ATI pending instance 0 to de_separation_13_3s_free_1_500595_1302486884_1 4/10/2011 9:59:07 PM | SETI@home | [coproc] ATI device 0 already assigned: task 17fe11ac.25226.11519.15.10.5_0 4/10/2011 9:59:07 PM | Milkyway@home | [coproc] Assigning ATI instance 0 to de_separation_13_3s_free_1_500595_1302486884_1 4/10/2011 9:59:07 PM | Milkyway@home | [coproc] Assigning ATI instance 0 to de_separation_13_3s_free_1_500595_1302486884_1 ... >> And the process repeats for every WU << |
Send message Joined: 24 Feb 09 Posts: 620 Credit: 100,587,625 RAC: 0 |
Ran a second batch 825/500 as opposed to 790/500. Speeded up as you would expect, still around 25% slower. CPU hit is still high, the PRPNet app took a 30% + hit. Screen started to shows initial signs of lag and faint juddering. Overall it looks stable, run real real cool, CPU is still too high, and its about 25% slower than 0.23 even running at 825/500. Feels stable enough to start working on parts of it one by one to improve performance now its stable, still long way to go to get back to old performance levels. Regards Zy |
Send message Joined: 1 Feb 11 Posts: 17 Credit: 16,245,184 RAC: 0 |
This is embarassing. I think the project would be better off if they just restored last week's version and our administrators backed off, took a few deep breaths and did some real software engineering and project planning. |
Send message Joined: 25 Jan 11 Posts: 271 Credit: 346,072,284 RAC: 0 |
everything is going fine for me w/ MW@H v0.59. of course i wasn't having any problems with v0.57 either. task run times are no slower with v0.59 than they were with v0.57. likewise, task run times were no slower with MW@H v0.57 than they were with v0.23, for me anyways. in fact, the only difference i noticed is that with MW@H versions 0.23 and 0.57, my GPU load would randomly walk between 85% and 100% during any given task, with an average of about 95% load. with the new MW@H v0.59, my GPU usage is down lightly, now randomly walking between 70% and 100%, with an average of about 80% load. but this is with just some tasks...other tasks casue the GPU load to walk like it did with MW@H v0.23 and v0.57. overall, i take this as a good thing considering my run times are no slower than before, and theoretically a lower GPU load on some tasks should mean generally lower GPU temps (though i haven't confirmed it with MSI Afterburner yet). i got one invalid result, but this was due to the task erroring out too many times on other clients. - i'm crunching on an HD 5870 2GB GPU - i'm using the Catalyst 11.3 drivers - i'm running BOINC v6.12.18 - my OS is WinXP Pro SP3 32-bit *EDIT* - i should clarify what i mean when i say that my run times haven't increased. what i mean to say is that my maximum run times for the various types of tasks (those that earn ~160, ~213, and ~267 points each) have not increased. however, i will say that, for the range it crunch times i would observe for each type of task in the past, it does seem like the run times of an increasing number of tasks running on the new MW@H v0.59 are near the higher end of the crunch-time ranges i've historically observed...so perhaps in the big picture, tasks are running slightly slower for me with MW@H v0.59. but it doesn't seem too significant. |
Send message Joined: 16 Nov 10 Posts: 17 Credit: 17,999,210 RAC: 0 |
This is embarassing. I think the project would be better off if they just restored last week's version and our administrators backed off, took a few deep breaths and did some real software engineering and project planning. If this were a release from a for-profit software company I would agree with you. Considering this is a volunteer science project run on a very tight budget I have to disagree. There was an initial unplanned oops which took the project down and was going to necessitate a few days to recover. What better time to throw in the upcoming changes that might mess things up and take the project down for a few days? It also saves a lot of time and money avoiding all that pesky beta testing, scheduled roll outs and downtime. People tend to be more productive when they're under the gun. ;-) |
Send message Joined: 25 Jan 11 Posts: 271 Credit: 346,072,284 RAC: 0 |
everything is going fine for me w/ MW@H v0.59. of course i wasn't having any problems with v0.57 either. task run times are no slower with v0.59 than they were with v0.57. likewise, task run times were no slower with MW@H v0.57 than they were with v0.23, for me anyways. in fact, the only difference i noticed is that with MW@H versions 0.23 and 0.57, my GPU load would randomly walk between 85% and 100% during any given task, with an average of about 95% load. with the new MW@H v0.59, my GPU usage is down lightly, now randomly walking between 70% and 100%, with an average of about 80% load. but this is with just some tasks...other tasks casue the GPU load to walk like it did with MW@H v0.23 and v0.57. overall, i take this as a good thing considering my run times are no slower than before, and theoretically a lower GPU load on some tasks should mean generally lower GPU temps (though i haven't confirmed it with MSI Afterburner yet). i got one invalid result, but this was due to the task erroring out too many times on other clients. i now believe this somehow has to do with my running E@H on all 6 CPU cores. when i set BOINC to use only 85% of the processors (forcing BOINC to use only 5 of my 6 CPU cores), or when i suspend E@H altogether (freeing up my CPU entirely), GPU load jumps back up to a constant and steady 98-99%. accordingly, run times approach the lower end of the crunch-time ranges i've historically observed. so my revised "big picture" is this: when i run E@H on all 6 CPU cores, MW@H GPU crunching efficiency suffers a bit in the form of slightly increased run times. when i leave a single CPU core free (or if i suspend E@H altogether and leave all 6 cores free), MW@H GPU crunching efficiency doesn't suffer at all, and run times are slightly decreased. |
Send message Joined: 8 May 10 Posts: 576 Credit: 15,979,383 RAC: 0 |
i now believe this somehow has to do with my running E@H on all 6 CPU cores. when i set BOINC to use only 85% of the processors (forcing BOINC to use only 5 of my 6 CPU cores), or when i suspend E@H altogether (freeing up my CPU entirely), GPU load jumps back up to a constant and steady 98-99%. accordingly, run times approach the lower end of the crunch-time ranges i've historically observed. so my revised "big picture" is this: when i run E@H on all 6 CPU cores, MW@H GPU crunching efficiency suffers a bit in the form of slightly increased run times. when i leave a single CPU core free (or if i suspend E@H altogether and leave all 6 cores free), MW@H GPU crunching efficiency doesn't suffer at all, and run times are slightly decreased.This seems to confirm what I've been finding. It seems that the slow happens with a high CPU load (at least in Windows. It seems to not happen for me in Linux). The time is about what it should be with a low CPU load, and quite a bit higher if the CPU load is light. This is still a problem to fix though. |
Send message Joined: 12 Aug 09 Posts: 262 Credit: 92,631,041 RAC: 0 |
I've updated the new ATI application to 0.59. This fixes the 100% CPU problem, and adds a command line flag -r <some number> or --responsiveness-factor <some number>. This number just multiplies the estimate for how long things are expected to take to decide how to break things into smaller pieces to allow the screen a chance to redraw. Numbers greater than 1 should make things more responsive. 0 ignores any need for responsiveness for maximum speed. Hi Matt, Well with this update (0.59) my pc (i7, Win7-64, 12GbRAM, 2HD5870 driver 11.3) is still using a full cpu load. I let run out all the cpu tasks (einstein@home) and then only MW. 8 Core 100% divided by 8 is 12.5 (12-13% use of one core) and that is what is happening. I see it also in teh results page, Runtime 130.09/CPUtime 128.22 I read other posts in this thread that more have this experience. So you have some more thinking. Good luck. Greetings from, TJ |
©2025 Astroinformatics Group