Message boards :
Number crunching :
**UPDATE: ATI 58x issue resolved!
Message board moderation
Author | Message |
---|---|
Send message Joined: 13 Mar 08 Posts: 804 Credit: 26,380,161 RAC: 0 |
ATI 58x0 GPU fix released Link to Milkyway Version 0.23 |
Send message Joined: 1 Sep 08 Posts: 520 Credit: 302,525,188 RAC: 0 |
|
Send message Joined: 30 Aug 07 Posts: 2046 Credit: 26,480 RAC: 0 |
This is excellent news, but it appears that everyone returning at once overloaded the server - so the feeder is now not running. I suspect things will settle down on the morrow. Fixed it. The problems we're seeing now is just that because we're using validation this bumped the number of parameter files on the server for results up by 2-3x. So the server is just buckling under the strain when the file deleter runs. When we swap over to the new application, which doesn't generate these files, the server should be running much smoother. |
Send message Joined: 1 Sep 08 Posts: 520 Credit: 302,525,188 RAC: 0 |
Good news -- I just did a detatch/re-attach on a couple of 4850 workstations to insure the current application was in place. Thanks for the quick attention -- seems you do 'university hours' (ie late nights = good, morning = sleep) <smile>
|
Send message Joined: 24 Feb 09 Posts: 620 Credit: 100,587,625 RAC: 0 |
Maybe a throw back to the problems - I have 40+ in pendings but none showing awaiting on the server stats page. On the positive side, validations are happening very quickly again seem to have caught up as such. Regards Zy |
Send message Joined: 30 Jun 09 Posts: 17 Credit: 40,702,094 RAC: 0 |
Seems like it is working, I did have some errors and now new packets with opti app 0.22 yesterday. |
Send message Joined: 5 Mar 09 Posts: 6 Credit: 60,945,378 RAC: 0 |
I am running the "stock" GPU app on a 4770. With the new 0.23 app, processing time has increased by a factor of 3 - from 4 minutes or so to 11+ minutes. Anyone else seeing this?? |
Send message Joined: 5 Mar 09 Posts: 6 Credit: 60,945,378 RAC: 0 |
I am running the "stock" GPU app on a 4770. With the new 0.23 app, processing time has increased by a factor of 3 - from 4 minutes or so to 11+ minutes. Anyone else seeing this?? OK looks like processing times back to normal with some later WUs.. |
Send message Joined: 18 Nov 08 Posts: 291 Credit: 2,461,693,501 RAC: 0 |
I have a machine that I cannot easily access. Can I just wait out the problem? ie: will the new app show up eventually? If not, then I guess I can tell bam! to detach it and later on I can re-attach it. That assumes the defective code is not sticky. |
Send message Joined: 30 Aug 07 Posts: 2046 Credit: 26,480 RAC: 0 |
I have a machine that I cannot easily access. Can I just wait out the problem? ie: will the new app show up eventually? The new app is probably there, the problem is that it may not be downloading the brook32.dll or brook64.dll you need for it. If it hasn't updated then you're going to need to detach and reattach somehow so it gets the new dll. |
Send message Joined: 26 Oct 09 Posts: 55 Credit: 352,166,802 RAC: 0 |
On my only system that has an HD58xx card, it left the old brook32.dll in place and downloaded a new version called brook32a_ati.dll, is that what should happen? This was done automatically, ie. no app_info on that machine. -Dave |
Send message Joined: 26 Jul 08 Posts: 627 Credit: 94,940,203 RAC: 0 |
No, the downloaded file should have been renamed to brook32.dll. Maybe this didn't worked as the old one was still there. If you don't want to detach and reattach, you can delete the old brook32.dll and rename the brook32a_ati.dll to brook32.dll (you should quit BOINC before). That should work, too. I think there should be a possibility to configure the application on the server in such a way that this is done automatically. Exchanging a file on a host can't be a thing the BOINC developers havn't thought of, isn't it? |
Send message Joined: 30 Dec 07 Posts: 311 Credit: 149,490,184 RAC: 0 |
I could be wrong but I think the automatically downloaded Windows 32-bit 0.23 version will need the file to be called "brook32a_ati.dll" because the brook32a_ati.dll file is downloaded and copied and used as brook32.dll: <file_ref> <file_name>brook32a_ati.dll</file_name> <open_name>brook32.dll</open_name> <copy_file/> I don't have the automatically downloaded Windows 32-bit v0.23 currently installed but going by the previous version the above code or something like it will be found in the "sched_request_milkyway.cs.rpi.edu_milkyway.xml" file in the BOINC folder. I'm not certain why the _ati was added to the filename, but it was possibly to distinguish it from planned _amd versions of the brook file (for Cat 8.12 and Cat 9.1). The auto _amd versions ended up not being deployed at MilkyWay. Just a guess but the extra "a" in the auto downloaded brook file probably denotes the recently updated brook version that includes the Cypress fix. |
Send message Joined: 30 Aug 07 Posts: 2046 Credit: 26,480 RAC: 0 |
I could be wrong but I think the automatically downloaded Windows 32-bit 0.23 version will need the file to be called "brook32a_ati.dll" because the brook32a_ati.dll file is downloaded and copied and used as brook32.dll: You're exactly right. The boinc client should download brook32a_ati.dll from the server (which is at http://milkyway.cs.rpi.edu/milkyway/download/brook32a_ati.dll) and then rename it to brook32.dll I think I might email the dev lists to see if there's some bug that would make this not overwrite a previous brook32.dll |
Send message Joined: 1 Jul 09 Posts: 8 Credit: 1,734,500 RAC: 0 |
I could be wrong but I think the automatically downloaded Windows 32-bit 0.23 version will need the file to be called "brook32a_ati.dll" because the brook32a_ati.dll file is downloaded and copied and used as brook32.dll: Maybe this isn't a bug. If a MW WU was running during the download then the "old" DLL was in use and so it couldn't be replaced by the "new" one. |
Send message Joined: 30 Dec 07 Posts: 311 Credit: 149,490,184 RAC: 0 |
Yes the code in the "sched_request_milkyway.cs.rpi.edu_milkyway.xml" file automatically copies and opens the brook file with the correct name format when it is used. However it remains as "brook32a_ati.dll" in the BOINC\project\milkyway.cs.rpi.edu_milkyway folder. Just making sure that it is understood that if someone manually renames brook32a_ati.dll to brook32.dll in their MilkyWay projects folder then the auto downloaded v0.23 application will no longer work. |
Send message Joined: 26 Oct 09 Posts: 55 Credit: 352,166,802 RAC: 0 |
In my case, I ran out MW work and wasn't doing any for a while before it was updated, so no MW work was being processed. Also, I didn't rename the a_ati version, I removed the older version and copied this into it's place, so both files are there now. I noticed I'm still seeing some invalid work, more than I would expect. -Dave |
Send message Joined: 7 Jan 10 Posts: 2 Credit: 87,865,132 RAC: 0 |
I am not sure if the new version is causing me problems or not, so I am going to telll you guys what is happening and maybe someone can help me. I did detach and re-attached to the new version of Boinc. But after running it on a 5870 graphic card for about 3 hours, my pc would slow down to a halt. The system would tell me that I ran out of resource. Nothing would work. The mouse would not respond. I had to reboot my machine and then my windows 7 would start checking for my disk drive because I had to do a reset. I am running the latest version of Boinc and only use my graphic card to compute. Running on an MSI board with i 920 and 6 MB of memory. I knew it had to be thhe new version of Boinc. But I can not prove it. I then detached Milkyway, and attached to Collatz and it has been running for about 5 hours without any problems. So much for Boinc's problem. I do not understand what the real culprit is then. Please help. |
Send message Joined: 24 Feb 09 Posts: 620 Credit: 100,587,625 RAC: 0 |
I notice at Collatz you are on 850/1200 with that PC. Its a long shot, but its possible that 850 is a tad too high for you at MW with the new app, without a slight overvolt. Try resetting to default clocks then run MW,if it goes ok, you'll know, and in that case, probably brining it down to 800 or 825 would get it working. If it does, reduce the memory down to as low as you can get it - memory speed is irrelevant at MW (I am running a 5970 on 300 memory with no issues, others I have seen running 4xxx below 200 with no issues). A low memory setting will save you a bunch on power, run cooler and/or allow a higher gpu clocks without overvolting. If all that holds true ..... a check on PSU capacity/output/power draw maybe a further check once you get going. Regards Zy |
Send message Joined: 7 Jan 10 Posts: 2 Credit: 87,865,132 RAC: 0 |
Thanks Zy, but I did not overclock my 5870. That is stocked memory speed. Also, I have been running Collatz for 24 hours now without any problems. So it has to be Milky Way process. I was also running at 4.00 GHz on my i920. I am now running 3.8 Ghz and will try to run Milky Way again to see if it does mess up my system again. Only if I can get some work units... |
©2024 Astroinformatics Group