ATI 58x0 GPU fix released

A big round of thanks go to Cluster Physik for quickly updating the 58x0 ATI GPU application, which was causing the validation problems we've been experiencing lately.
If you're running MilkyWay@Home on a 58x0 ATI GPU, please upgrade your application. A link is to the application is below.
Please take the time to update to this, as not only are the bad ATI 58x0 GPU applications causing their own workunits to be often flagged invalid, they report results quick enough that they have been quoruming up against valid results and causing the valid ones to be flagged invalid.
Thanks, Travis 7 Apr 2010 1:39:17 UTC

Link to Milkyway Version 0.23

---

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.

---

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.

---

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>

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.

---

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

Seems like it is working, I did have some errors and now new packets with opti app 0.22 yesterday.

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??

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..

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.

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.

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.

---

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.

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

---

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.

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.

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?

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.

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:

brook32a_ati.dll
brook32.dll


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.

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

---

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.

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

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.

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.

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.

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

---

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.

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

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...