Posts by Michael H.W. Weber
|
21)
Message boards :
Number crunching :
AMD R9 290X does not receive any GPU work
(Message 63210)
Posted 9 Mar 2015 by  Michael H.W. Weber
Post: http://milkyway.cs.rpi.edu/milkyway/download/milkyway_separation__modified_fit_1.36_windows_x86_64__opencl_ati_101.exe Thank you very much. But I have NO IDEA whether they are the right files for your computer, or the right files for this project's current research (in particular, I see that v1.36 is current on the project Applications page, but I have no idea why the v1.20 'separation' files were recommended). Could someone of the project please leave us a comment on this? Michael. |
|
22)
Message boards :
Number crunching :
AMD R9 290X does not receive any GPU work
(Message 63189)
Posted 2 Mar 2015 by Michael H.W. Weber
Post: Well, it is all non-functional even after inserting the suggested line. No WUs are fetched, when app_info.xml is absent. When copied to the right place, the apps can't be found (same error reported as shown above after restarting BOINC): 02.03.2015 13:25:58 | Milkyway@Home | Sending scheduler request: To fetch work. Michael. |
|
23)
Message boards :
Number crunching :
AMD R9 290X does not receive any GPU work
(Message 63186)
Posted 2 Mar 2015 by Michael H.W. Weber
Post: Well, no WUs are delivered. Moreover some syntax error is reported in the BOINC manager's notification panel: Milkyway@Home: Notice from BOINC Michael. |
|
24)
Message boards :
Number crunching :
AMD R9 290X does not receive any GPU work
(Message 63183)
Posted 27 Feb 2015 by Michael H.W. Weber
Post: Thank you for the feedback. Michael. |
|
25)
Message boards :
Number crunching :
AMD R9 290X does not receive any GPU work
(Message 63180)
Posted 24 Feb 2015 by Michael H.W. Weber
Post: Thanks a lot. What exactly is NBODY? Why isn't it included? Where do I have to copy that app_info.xml file to? Can I modify the number of WUs being processed in parallel on my GPU (it has 4 GB of GDDR5 RAM onboard) and if so how/where? Michael. |
|
26)
Message boards :
Number crunching :
AMD R9 290X does not receive any GPU work
(Message 63174)
Posted 23 Feb 2015 by Michael H.W. Weber
Post: Older server software that thinks you have a 3800 series card. Why doesn't it get upgraded? I think it should be of prime priority for any project to aquire serious compute power, shouldn't it? You will have to use an app_info.xml to allow it to work. Well, I think the majority of possible project comtributers would not even take the time to visit the forum to find out about such details. What a pity for the project's progress... Well, is there a sample file available to get my R9 290X working for Milkyway@home? Michael. |
|
27)
Message boards :
Number crunching :
AMD R9 290X does not receive any GPU work
(Message 63168)
Posted 20 Feb 2015 by Michael H.W. Weber
Post: I have an AMD R9 290X (MSI Lightning) graphics board, capable of double-precision and OpenCL 1.2 in my machine. For unknown reasons, it does not get any work from this project. It works excellently with Folding@home and Einstein@home, so I was wondering what the problem could be? Michael. |
|
28)
Message boards :
Number crunching :
Results valid at all? Memory leaks everywhere?
(Message 1647)
Posted 5 Feb 2008 by Michael H.W. Weber
Post: Memory leaks are not an indication of valid or invalid it is just a symptom of an app that is not fully optmized to run on a given os. I have had memory leaks on other projects to no detriment and otherwise ran and validated with no problems. Ok. So, the scientific value is not affected by this issue. That is what I wanted to make sure - thanks for the information. ;-) As for the cache limit... because the work generator rapidly changes parameters to reflect what the results are telling... Ok. So, new work units are based on the results of previous ones. Then a cache limitation makes indeed sense. Thanks a lot for the input. I have yet to see a quad-core or 8 core burn through 20 results in 20 minutes with the current wu length we are running... I did not say that. However, my estimation is that four current WUs will be completed within approx. 20 minutes on a good Quad system, hence in less than two hours a non-networked machine will be out of work if it was not running a second project. And running a second project together with MilkyWay@home was (and is) connected with issues if the "keep application in memory" switch is not enabled (and this switch is in fact disabled after registering with MilkyWay@home even if it was enabled before). Projects are not set-up to necessarily have users to get constant work...they are set up for the science... Well, as a scientist that is crystal clear to me - however, it would sometimes be nice to place such important introductory information on application requirements fixed somewhere on the project main page rather than putting it at some place in a forum which most people (just willing to contribute their spare cycles) often just don't have the time to read. Just an idea... Of course I got the message this is an alpha project and for that it is quite good. So let's hope for a lot of cool results. ;-) Michael. |
|
29)
Message boards :
Number crunching :
Results valid at all? Memory leaks everywhere?
(Message 1645)
Posted 5 Feb 2008 by Michael H.W. Weber
Post: It seems that MilkyWay@home has a massive memory leak problem. I know, it has been stated before in another thread on this board: There are still some memory leaks left in the code (maybe 4kb or so), we're still trying to find these, but these should be fixed by the next application update. Here an example: AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ [x86 Family 15 Model 75 Stepping 2] Please also check this URL: http://milkyway.cs.rpi.edu/milkyway/result.php?resultid=3291913 Well, as you can see, the problem is that this problem does not occur in "some" cases. Above I have reported examples for 5 independent machines that all contain different CPU architectures. All WUs I have checked display this type of error. This error has also been reported by some people on our board to persist in all of the WUs checked - even though these WUs were all reported as "success". Now my question: This doesn't mean that the entire work performed for this project is wasted, right? We are currently putting quite some efforts in supporting this project, but we would decide to just withdraw from it until these issues have been resolved - if the results were invalid at all - and then come back for later support. ;-) The workunit limit (for the time being) is 20, there's not too much i can do about this at the moment, because of how things work server side. Any larger and most of the work people would be doing would be outdated and useless. Here we have another issue. A quick fix would be highly appreciated. On modern machines MilkyWay@home WUs are finished within a few minutes making it impossible to crunch this project full time (24/7) if you do not have a permanent internet connection (just imagine a quad core machine). This fact should at least be posted on the main page of the project if the number of WUs per machine cannot be increased (the reason for why it cannot I actually also do not understand, by the way). On windows machines, occasionally a workunit will break and this will display a popup message causing boinc to freeze. We're still not quite sure why this is happening yet. This is still happening - since weeks now. If you need assistance in nailing the bugs, please let us know such that we can save some log data or whatever you might need. All the best for this project, Michael. P.S.: Other relevant threads in this fourm concerning the memory leak: http://milkyway.cs.rpi.edu/milkyway/forum_thread.php?id=100 http://milkyway.cs.rpi.edu/milkyway/forum_thread.php?id=197#1644 |
Previous 20
©2024 Astroinformatics Group