Message boards :
Number crunching :
3rd.in - optimized apps
Message board moderation
Previous · 1 . . . 34 · 35 · 36 · 37 · 38 · 39 · 40 · Next
Author | Message |
---|---|
Send message Joined: 19 May 09 Posts: 16 Credit: 20,273 RAC: 0 |
Nuadormrac, before I replaced the 0.19 stock version with the 0.20 version downloaded from zslip.com I looked for an app_info.xml file, but couldn't find one. So I put the 0.20 app_info file in the ...Boinc/projects/milkway.cs.rpi.edu/milkyway folder. When the first MW WU downloaded after I upgraded, BOINC Manager listed the application as milkyway 0.20. I doen't think the server has strictly 0.19 WUs that require the 0.19 app. I think the server downloads the same WUs regardless of which app you're using. It sounds like you have both apps in the ...Boinc/projects/milkway.cs.rpi.edu/milkyway folder. If so, I would at least move the 0.19 app to another folder. The server (or the Boinc client) may see it as the default. Like you, I used CPU-Z to learn the most advanced instruction set my CPU is capable of. when I went to parse together the 2 app_info.xml files to include entries for both one listing followed by the other; things seemed to not exactly go well together (the run times were suggestive of it going back to a stock client). Maybe that wasn't such a good idea. :) Cheers, Steve |
Send message Joined: 27 Aug 07 Posts: 915 Credit: 1,503,319 RAC: 0 |
Looking forward to v0.20 SSSE3. Any ETA? me@rescam.org |
Send message Joined: 26 Jul 08 Posts: 627 Credit: 94,940,203 RAC: 0 |
Looking forward to v0.20 SSSE3. Any ETA? Never ;) All the different SSE levels won't change the performance as for the vectorization SSE2 is basically enough. The 64bit variants are extracting more performance than any additional (S)SSEy.x version could do. |
Send message Joined: 19 May 09 Posts: 16 Credit: 20,273 RAC: 0 |
Looking forward to v0.20 SSSE3. Any ETA? But if you really want SSE3 for Win32 it's available at www.zslip.com. |
Send message Joined: 4 Oct 08 Posts: 1734 Credit: 64,228,409 RAC: 0 |
That's for CPUs only, not ATI GPUs. Go away, I was asleep |
Send message Joined: 12 Apr 08 Posts: 621 Credit: 161,934,067 RAC: 0 |
That's for CPUs only, not ATI GPUs. If you are running on a GPU, SSE of any flavor is not going to do much of anything to improve run times. In essence the GPU runs an instruction set that is similar in effect as to the SSE instructions. So, all the calculations that could take advantage of this instruction set are run on the GPU ... the remaining code on the CPU will get no benefit as this code is mostly moving data on and off the GPU itself. |
Send message Joined: 26 Jul 09 Posts: 6 Credit: 48,518 RAC: 0 |
Looking forward to v0.20 SSSE3. Any ETA? So 0.20 SSE3 should be faster than 0.19 SSSE3, right? |
Send message Joined: 11 Sep 08 Posts: 22 Credit: 10,838,567 RAC: 11,227 |
Actually, hitherto it's been using the 0.19 app; things got a little whonky, so did a reset project, then just put the 0.19 in as that's all that was there, after cleaning it out (it wasn't even processing WUs). Now that's a hmm, because with the seti optimized apps, when they transitioned from 1 science app version to another, having entries for both in the app_info file worked perfectly well, and on download it just told it which to use. Either way, as it gave 0.19 work from all indications that's what I put in. However, the project is out of results ready to send, so once it comes back up I'll see. Some indication should definitely come when they want us to switch, but I'm guessing there was a backlog of 0.19 work present or something for which it continued sending results. Perhaps this no work available now, could be replaced with only 0.20 coming up after? Or maybe it's just another in a long line of server problems (the website access timed out once or twice, and one access to the project gave 10/6/2009 8:41:16 PM Milkyway@home Sending scheduler request: To fetch work. I'll see after it shows more then 0 results ready to send on server status page. |
Send message Joined: 14 Feb 09 Posts: 999 Credit: 74,932,619 RAC: 0 |
|
Send message Joined: 6 Apr 08 Posts: 2018 Credit: 100,142,856 RAC: 0 |
I have my site updated with the newer 0.20b ATI apps now. 0.20b doesn't work, at least not for me. Since you've taken 0.20 off your site I take it that you think 0.20b will work for all? |
Send message Joined: 14 Feb 09 Posts: 999 Credit: 74,932,619 RAC: 0 |
They are not off the site, just put in the older folder. http://www.arkayn.us/milkyway/older/index.htm 0.20b has my card screaming right now. |
Send message Joined: 9 Feb 09 Posts: 166 Credit: 27,520,813 RAC: 0 |
I tried the new 0.20b on my 4850 and to my surprise all units failed And started crash ?!? when i put back the 0.20ATI it runs normal I have been testing many things since then but i am baffled why it fails Its new, its relative fast... my new bicycle |
Send message Joined: 15 Aug 09 Posts: 9 Credit: 318,640 RAC: 0 |
I have my site updated with the newer 0.20b ATI apps now. I just installed 20b and it seems to be working fine, at least, on the first few MilkyWay WUs. The previous v20 actually deleted itself (the app) when I first started Boinc. (see my previous post.) So I switched back to 19g which worked fine and ran 3 WUs at a time, just uning the GPU. Upon installing 20b and starting Boinc it instantly deleted all of the MilkyWay WUs I already had queued to run, about 20 of them. That was worrisome. I don't know if this is standard practice following an upgrade. But I would like to know if it is, as it seems to be a strange behavior, like the previous v20. So after those WUs disappeared, I waited a few minutes and another 10 were downloaded and started, but are running only one at a time. They are taking about 3-5 seconds a piece to finish. That is on an HD3870 with a dual-quadcore Xeon at 2.66GHz. So far, 20b looks good! n2n |
Send message Joined: 1 Mar 09 Posts: 56 Credit: 1,984,937,499 RAC: 0 |
I just installed 20b and it seems to be working fine, at least, on the first few MilkyWay WUs. Of course it works fine. It works fine for me as well and it would probably work fine for the vast majority if only they would really, really read the readme and not do anything until they fully covered and understood each point. It really is all there in the readme. The previous v20 actually deleted itself (the app) when I first started Boinc. (see my previous post.) So I switched back to 19g which worked fine and ran 3 WUs at a time, just uning the GPU. No it didn't delete itself. When you use AP (anonymous platform) you are telling BOINC precisely which application it has to use for specific tasks 'branded' with specific version numbers. V20b is described in the new app_info.xml and not V20. Therefore the AP mechanism will delete V20 because app_info.xml doesn't need it any more. This is exactly as intended to clean up old and no longer required versions of apps. I really don't understand why if V20b was working OK (as you say in your first statement), you got worried about V20 and then went back to a V19 variant??? Upon installing 20b and starting Boinc it instantly deleted all of the MilkyWay WUs I already had queued to run, about 20 of them. That was worrisome. I don't know if this is standard practice following an upgrade. But I would like to know if it is, as it seems to be a strange behavior, like the previous v20. I presume you are now talking about an upgrade from V19 back to V20b. What you describe above is exactly what AP is supposed to do if you haven't made arrangements within the app_info.xml file to properly handle the differently 'branded' tasks. There are no differences in the tasks themselves but they do become 'branded' with the version number of the app in existence at the time they were downloaded. This 'branding' is stored in your state file (client_state.xml). There is no difference in version 'branding' for V20 and V20b. Both are <version_num>20</version_num> under AP. There is a big difference between V19x and V20x however and all you needed to do to prevent trashing your V19 'branded' tasks was to duplicate the <app_version> clause in app_info.xml so that both 'brandings' were specified as being allowed to be crunched by the new V20b app. After all, computers are extremely literal - they do exactly what they are told :-). It's just we humans that write the instructions that always get it wrong - we're not very good at reading and writing precise instructions :-). So after those WUs disappeared, I waited a few minutes and another 10 were downloaded and started, but are running only one at a time. They are taking about 3-5 seconds a piece to finish. That is on an HD3870 with a dual-quadcore Xeon at 2.66GHz. I presume you mean "3-5 seconds less a piece to finish." So far, 20b looks good! Precisely!! :-). I think a lot of people reporting failures have got the _ati.exe and _amd.exe versions mixed up because they haven't properly read the readme. Using AP is not easy - particularly when you eventually want to bail out and go back to a fixed up stock app. You can research AP somewhere in the stuff on boinc.berkeley.edu. Stick 'anonymous platform boinc' into google and I'm sure you'll get lots of stuff to read and digest :-). Cheers, Gary. |
Send message Joined: 9 Feb 09 Posts: 166 Credit: 27,520,813 RAC: 0 |
After fiddling with the darn catalyst drivers and many tests with settings all run smooth with 0.20b now. I still wonder why once in certain timeframe the dual card system seems to be messed by unknown factor with the driver. While running 1 card does run super stable but if 2 .... ppffff they keep you busy all the time. Especially when a new release is done from the apps from collatz or MW xD I think CP has found a new way of keep us busy ;) Sidenote the new 0.20b version does make a significant impact on 4830/4770 cards if you are up to the trouble its worth it :D Its new, its relative fast... my new bicycle |
Send message Joined: 6 Apr 08 Posts: 2018 Credit: 100,142,856 RAC: 0 |
Version 0.20b for ATI optimized apps is now on brilliantsite.com All zip files in the downloads begin with ati_ to denote they are for ati GPU processing (not CPU). Some of the file names end with _amd.zip which denote that amdcal* drivers are required. See the readme.txt in each download. |
Send message Joined: 15 Aug 09 Posts: 9 Credit: 318,640 RAC: 0 |
"I presume you mean "3-5 seconds less a piece to finish." No, actually, it was 3-5 "minutes" to complete each WU. My mistake in using seconds instead of minutes. After running 20b for two days I have decided that I prefer the way 19g runs. It seems to be quite faster, going thru 3 WUs at a time. So I am going to switch back. "No it didn't delete itself." And I want to make THIS point perfectly clear. The v20 application code was instantly DELETED. You can hedge or quibble in your explanation all you want. Whether it was by design, programing, or program error, or the Man-In-The-Moon, I REALLY DON'T CARE. "DELETED" means that it was gone within seconds WITHOUT EXPLANATION or note in the Log. I saw this behavior with my own eyes. And I am NOT mistaken. Version 20 DELETED the application code immediately each of the 5 times I started BOINC with it installed. That's the way it worked (?) on my machine; others may have experienced something else. For ME, Version 20 was a waste of time. "if you haven't made arrangements within the app_info.xml file to properly handle the differently 'branded' tasks. " I don't do anything with the XML app_info file, let alone "make arrangements". I just copy it into the correct place and run. I ASSUMED that this application would be ready-to-go when posted. If not, then it defeats the entire plan of upgrading to using it. Although I don't miind turning my machinee over for use my a project, I personally, don't have the time to screw around with this stuff. I think there needs to be some/more QA (quality assurance) done on these applications prior to their release. All I tried to accomplish by posting was to provide a little feedback that might be useful and/or encouraging. I really HATE it when someone uses my post to make a speech and to preach to me. And I don't appreciate the tone of the response that I received. Sounds very arrogant. Just my opinion... n2n |
Send message Joined: 6 Apr 08 Posts: 2018 Credit: 100,142,856 RAC: 0 |
I ASSUMED that this application would be ready-to-go when posted. That is a good assumption, all the versions have worked 'out of the box' for me with options to tweak things. There will always be misunderstandings and explanations and detail that we have to struggle with at times. But then there always some who want to get the best for all of us ;) |
Send message Joined: 16 Feb 09 Posts: 109 Credit: 11,089,510 RAC: 0 |
I don't do anything with the XML app_info file, let alone "make arrangements". I just copy it into the correct place and run. I ASSUMED that this application would be ready-to-go when posted. You'd probably be better off sticking with the standard project applications. You made some pretty poor assumptions. |
Send message Joined: 9 Nov 08 Posts: 41 Credit: 92,786,635 RAC: 0 |
OK it it time... It is my first Radeon, and it is HD5870. I install BM 6.10.13, drivers 1.4.427, and astronomy_0.20b_ATI_x64_ati opt. OS is Windows 7 RC 64bit Everything works very well! Example: <core_client_version>6.10.13</core_client_version> <![CDATA[ <stderr_txt> Running Milkyway@home ATI GPU application version 0.20b (Win64, CAL 1.4) by Gipsel instructed by BOINC client to use device 0 CPU: Intel(R) Core(TM)2 Quad CPU Q8200 @ 2.33GHz (4 cores/threads) 2.8701 GHz (234ms) CAL Runtime: 1.4.427 Found 1 CAL device Device 0: ATI Radeon HD5800 series (Cypress) 1024 MB local RAM (remote 831 MB cached + 831 MB uncached) GPU core clock: 850 MHz, memory clock: 300 MHz 1600 shader units organized in 20 SIMDs with 16 VLIW units (5-issue), wavefront size 64 threads supporting double precision Starting WU on GPU 0 main integral, 320 iterations predicted runtime per iteration is 61 ms (33.3333 ms are allowed), dividing each iteration in 2 parts borders of the domains at 0 800 1600 Calculated about 8.22242e+012 floatingpoint ops on GPU, 1.23583e+008 on FPU. Approximate GPU time 20.6122 seconds. probability calculation (stars) Calculated about 3.34818e+009 floatingpoint ops on FPU. WU completed. CPU time: 2.51162 seconds, GPU time: 20.6122 seconds, wall clock time: 21.768 seconds, CPU frequency: 2.87016 GHz </stderr_txt> ]]> Default app info is in use: <app_info> <app> <name>milkyway</name> </app> <file_info> <name>astronomy_0.20b_ATI_x64_ati.exe</name> <executable/> </file_info> <file_info> <name>brook64.dll</name> <executable/> </file_info> <app_version> <app_name>milkyway</app_name> <version_num>20</version_num> <flops>1.0e11</flops> <avg_ncpus>0.05</avg_ncpus> <max_ncpus>1</max_ncpus> <coproc> <type>ATI</type> <count>1</count> </coproc> <cmdline></cmdline> <file_ref> <file_name>astronomy_0.20b_ATI_x64_ati.exe</file_name> <main_program/> </file_ref> <file_ref> <file_name>brook64.dll</file_name> </file_ref> </app_version> </app_info> But I see this in GPU-Z: As you see GPU Load is droping when WU is ending and new WU is starting. So I read ReadMe and there "are several options one can put in there" <cmdline></cmdline> I am just starting ATI crunching... so i ask experts for sugestion how to change the option in order to minimize drop of gpuload in counting... The best would be non stop 99% load :) Now Boinc is crunching one MW task, ends it, and start another... Now it looks like HD5870 is crunching 900 - 905 WU at 6 hours... so it is 192420 - 193489 c per 24 hours. A proud member of the Polish National Team COME VISIT US at Polish National Team FORUM |
©2025 Astroinformatics Group