Message boards :
News :
ATI application updated to 0.60
Message board moderation
Previous · 1 · 2 · 3 · 4 · 5 · 6 . . . 7 · Next
Author | Message |
---|---|
Send message Joined: 20 Sep 08 Posts: 1391 Credit: 203,563,566 RAC: 0 |
@Brian - EDIT: oppps ..... 0.50's are the cpu ones ..... ignore comment .... sorry, bad hair day :)Ummm I didn't know that .. @Arkayan - The apps I have on my site are just stock, just with the included app_info.xml file and Matt's configure options.Well I seem to be getting a bit better results using your app_info. I'll monitor it. |
Send message Joined: 15 Jul 08 Posts: 383 Credit: 729,293,740 RAC: 0 |
v.62 on my two 4850s still needed more than one core (on my two processor dual core Operton system) to reach 99% GPU utilization. Ed.T, your results on that machine show 10 seconds or less CPU/WU with v.62. |
Send message Joined: 15 Jul 08 Posts: 383 Credit: 729,293,740 RAC: 0 |
The apps I have on my site are just stock, just with the included app_info.xml file and Matt's configure options. arkayn thanks for hosting these. One small change in the app_info.xml: Change: <version_num>57</version_num> to <version_num>62</version_num> |
Send message Joined: 14 Feb 09 Posts: 999 Credit: 74,932,619 RAC: 0 |
I will change the version number once they get everything stabilized, but as the WU are the same no matter what it does not really matter at the moment. |
Send message Joined: 12 Nov 07 Posts: 2425 Credit: 524,164 RAC: 0 |
Cpu time looks to be 20+ hours on a P4 & XP. 8.5 hours @ 41.5% I guess the credit is ~250 still? Is/Will a opti ap be put out for cpu? Doesn't expecting the unexpected make the unexpected the expected? If it makes sense, DON'T do it. |
Send message Joined: 1 Feb 11 Posts: 17 Credit: 16,245,184 RAC: 0 |
v.62 on my two 4850s still needed more than one core (on my two processor dual core Operton system) to reach 99% GPU utilization. I've gotten the notion that if the CPU isn't available when GPU needs it that GPU utilization goes down. CPU time for the job wouldn't increase but PPD would still go down. Perhaps the combination of BOINC, task manager and MSI Afterburner (plus the WCG work units running) pushed the need for "some of one core" not running a WU to "some of 2 cores" not running a work unit... IIRC, there's a tweak for raising the priority of the CPU side of the app in the works. I'm going to wait and see if that fixes it. Some folks are saying everything is working fine. I'm saying not for everyone; we still need the additional releases. - Ed. Please: WCG - Help Cure Muscular Dystrophy |
Send message Joined: 18 Feb 09 Posts: 9 Credit: 20,005,162 RAC: 0 |
Great that there is an Linux ATI app but I am getting quite a few 'Completed, validation inconclusive' results for the v0.62 app under Linux. Some WUs have 2 or 3 other ATI hosts with the same problem and some hosts are under Windows. de_separation_13_3s_fix20_1_585272_1302651144 has 3 computing errors, my inconclusive and waiting on a CPU host 2820085 249670 12 Apr 2011 | 23:34:42 UTC 12 Apr 2011 | 23:36:23 UTC Error while computing 1.35 0.06 --- MilkyWay@Home v0.62 (ati14) 2822052 44821 12 Apr 2011 | 23:37:20 UTC 12 Apr 2011 | 23:43:59 UTC Error while computing 2.15 0.09 --- MilkyWay@Home v0.62 (ati14) 2828284 278207 12 Apr 2011 | 23:45:48 UTC 13 Apr 2011 | 0:15:22 UTC Completed, validation inconclusive 134.86 6.53 pending MilkyWay@Home v0.62 (ati14) 2851869 151825 13 Apr 2011 | 0:17:17 UTC 13 Apr 2011 | 0:19:07 UTC Error while computing 2.03 0.05 --- MilkyWay@Home v0.62 (ati14) 2855017 274444 13 Apr 2011 | 0:21:19 UTC 21 Apr 2011 | 0:21:19 UTC In progress --- --- --- MilkyWay@Home v0.50 (sse2) |
Send message Joined: 20 Mar 08 Posts: 108 Credit: 2,607,924,860 RAC: 0 |
I've gotten the notion that if the CPU isn't available when GPU needs it that GPU utilization goes down. CPU time for the job wouldn't increase but PPD would still go down. That's what I've been seeing as well. With all respect to Matt, I don't think Cluster Physik (who practically invented MW on ATI GPUs) wrote the following about CPU process priority for no reason: p1: normal priority in idle priority class (below normal), this is recommended for BOINC GPU applications, but apears to be not enough to enable millisecond polling of the GPU with Vista p2: normal priority in normal priority class, the default 0.60 and 0.62 work fine on Windows XP, but on Windows 7 they sometimes want CPU time they're denied by other CPU tasks, resulting in lower GPU use than is the case without other CPU tasks.. |
Send message Joined: 24 Dec 07 Posts: 1947 Credit: 240,884,648 RAC: 0 |
I've gotten the notion that if the CPU isn't available when GPU needs it that GPU utilization goes down. CPU time for the job wouldn't increase but PPD would still go down. On my Q9450 with Win7 64bit and a 5970 running 0.62, I'm pretty much seeing 98% GPU utilisation while running Aqua@home which is multithreaded. |
Send message Joined: 8 Feb 08 Posts: 261 Credit: 104,050,322 RAC: 0 |
v.62 on my two 4850s still needed more than one core (on my two processor dual core Operton system) to reach 99% GPU utilization. In task manager it shows as high cpu time used by system, that's what I am trying to explain since days. It looks like a blocking wait of the cpu waiting for the gpu to sent data back. Whatever is causing it, it seems to have its root in the communication between cpu and gpu. Even the old app (from Gipsel) had that problem and solved it with the different parameters and defaults that worked reasonable good for many people. The options of the new app (Matt) let you get that high cpu time by system down with a high polling number at the cost of gpu utilisation. Increasing target frequency reasonable allows to reduce the polling number again at the cost of the chunk size. To find the sweet spot for target frequency / polling is impossible. With the same parameters, the work packages seems to vary. Even within 1 WU I saw Dividing into 8 chunks Integration range: { nu_steps = 640, mu_steps = 1600, r_steps = 1400 } Using { 1, 8 } chunk(s) of size { 1400, 200 } Integration time = 104.070243 s, average per iteration = 162.609754 ms Dividing into 1 chunks Integration range: { nu_steps = 640, mu_steps = 400, r_steps = 1400 } Using { 1, 1 } chunk(s) of size { 1400, 400 } Integration time = 25.759259 s, average per iteration = 40.248843 ms For the first part it was working ok with low system cpu time but it jumped up for the second part before the final cpu calculations were done. This all leads to the conclusion that the packet sizes send to the gpu are different on the very same gpu. Or the calculations done are different and need different time. Both are bad for a fix sleep time of the cpu. The cpu needs to know for how long it has to wait in sleep mode. The optional parameters should only be needed to fine tune the app for a certain system. I thought target frequency and calculation speed of the gpu would lead to something like work packages per second (like frequency 30 = 30 work packages per second) but I don't see this. If it would work that way it would be easy to set frequency and polling. Different size WUs wouldn't be a problem too. With big chunks it is hard to find the right balance, either the cpu or the gpu will wait unreasonable long. Small chunks will increase the number of data transfers but reduce the wait times and makes it easier to find the right setting of the parameters for a system. Varying work packages sizes will need parameters set for the worst case and have an overhead of unnecessary wait times for many WUs. As long as the root problem can't be solved, a combination of high frequency and low polling number (still both far higher than the default) seems the only temporary solution. Sure this will cost some overhead for increased data transfer cpu <-> gpu. Trying to give examples of what we need: frequency 25 = 25 work packages per second and 38+polling sleep time of cpu frequency 30 = 30 work packages per second and 32+polling sleep time of cpu frequency 50 = 50 work packages per second and 19+polling sleep time of cpu Taking the 5% cpu setting, I used a calculating of 950/work packages. This calculated sleep time sure needs some tests. Positive polling here is the additional number of ms added to the calculated time. |
Send message Joined: 30 Aug 07 Posts: 2046 Credit: 26,480 RAC: 0 |
Great that there is an Linux ATI app but I am getting quite a few 'Completed, validation inconclusive' results for the v0.62 app under Linux. Some WUs have 2 or 3 other ATI hosts with the same problem and some hosts are under Windows. Validation inconclusive means you returned a result that we're going to use in our search population (which is used to generate new workunits), but before we actually use that result we send out another result to see if they verify against each other. Unlike other projects we don't validate every result that's returned to the server. |
Send message Joined: 8 May 10 Posts: 576 Credit: 15,979,383 RAC: 0 |
Great that there is an Linux ATI app but I am getting quite a few 'Completed, validation inconclusive' results for the v0.62 app under Linux. Some WUs have 2 or 3 other ATI hosts with the same problem and some hosts are under Windows.Those errors also look like what seems to happen with old / bad drivers. |
Send message Joined: 4 Feb 11 Posts: 86 Credit: 60,913,150 RAC: 0 |
I am getting this message: 4/13/2011 11:26:17 PM Milkyway@home Message from server: ATI GPU: Upgrade to the latest driver to process tasks using your computer's GPU I do not know why I am getting this message because I am using AMD's latest stable driver package, Catalyst 11.3. The driver itself is version 8.831.2.0 for Windows 7 64-bit. Did the administrator set this to accept Catalyst 11.4 and later only? That package is still a beta package. |
Send message Joined: 30 Dec 07 Posts: 311 Credit: 149,490,184 RAC: 0 |
I'm using 11.4 and getting the same message. |
Send message Joined: 8 May 10 Posts: 576 Credit: 15,979,383 RAC: 0 |
I am getting this message:Since there are driver issues and I don't know what version works, I'm working on setting it to require 11.3 (unless somebody has it reported working with something earlier). However it appears I've done it wrong and it's just not sending. |
Send message Joined: 24 Feb 09 Posts: 620 Credit: 100,587,625 RAC: 0 |
Its claiming no GPU WUs available, only CPU (I am running 11.3). EDIT: Its back, WUs flowing - ta muchly :) Regards Zy |
Send message Joined: 22 Mar 09 Posts: 99 Credit: 503,422,495 RAC: 0 |
I use the application since release. On my system (Q9550, Win 7 64 Bit, 2x 5850 (Catalyst 11.3), Boinc 6.12.18, high utilization with four CPU-projects) I noticed this. CPU-time is stable at 5 sec. CPU-usage 1 %, but higher at the end of WU for calculation likelihood (according to Matt) GPU-time is stable:
13s_3s_free: 90 s 10s_3s_fix20: 147 s
|
Send message Joined: 26 Jun 09 Posts: 47 Credit: 276,827,695 RAC: 0 |
Matt, I have 2 machines running 5970s using CAT 10.10. I have another machine running 2 5870s also under CAT 10.10. None of these 3 machines are having any trouble at all. OS Win7 64 I am getting this message:Since there are driver issues and I don't know what version works, I'm working on setting it to require 11.3 (unless somebody has it reported working with something earlier). However it appears I've done it wrong and it's just not sending. Bryan |
Send message Joined: 16 Nov 10 Posts: 17 Credit: 17,999,210 RAC: 0 |
I'm working on setting it to require 11.3 (unless somebody has it reported working with something earlier). Running 10.12 on AMD, Win7-64, 5850 with the app working and no invalids/errors. Haven't had any driver problems with any of the 57/59/60/62 versions. Tried 11.x before and found that on my system 10.12 is more stable than 11.x. My only problem seems to be an unrelated app/cc/bm scheduling thing that sometimes sends all MW work into immediate EDF mode. |
Send message Joined: 15 Jul 08 Posts: 383 Credit: 729,293,740 RAC: 0 |
I am getting this message: Using mostly 10.12 here on 64 bit Windows. It's a bit faster than 11.3 on many machines. 11.x has problems that they're trying to resolve in 11.4.. |
©2024 Astroinformatics Group