Posts by Slicker [TopGun]
|
1)
Message boards :
Number crunching :
Interesting Statistics
(Message 39375)
Posted 2 May 2010 by  Slicker [TopGun]
Post: Milkyway data as of 5/2/2010. Total GPUs: 30,321 Total Active GPUs: 12,402 Total Active Double Precision GPUs: 6,688 Total Hosts: 115,759 Total Active Hosts: 29,582 Active Hosts Percent: 25 Total CPUs: 294,156 Total Active CPUs: 82,899 Total GPU teraFlops: 22,007.63 Total Active GPU teraFlops: 10,175.51 Total Active Double Precision GPU teraFlops: 8,359.40 Total CPU teraFlops: 661.28 Total Active CPU teraFlops: 195.96 Total CPU teraIOps: 1,640.68 Total Active CPU teraIOps: 495.77 Note: Active means a workunit was returned within the last 7 days. |
|
2)
Message boards :
Number crunching :
Locking Up Moving From Milkyway to Collatz
(Message 37628)
Posted 21 Mar 2010 by Slicker [TopGun]
Post: Milkyway GPU tasks have to complete before I can suspend them, elsewise they reset to 0%. Collatz tasks don't have this bug. I'm not sure it is so much of a bug as a design decision. The MW tasks don't run long enough on fast GPUs to hit a checkpoint which only occurs every 3 minutes (or is it 5, I don't recall). Back when MW WUs took under a minute, there really wasn't any reason for checkpointing. Also, when the apps were first created, there were no other projects running ATI. As far as the slow response goes, that can be controlled via the command line parameters via the app_info. The options are all in the readme that CP includes with the opt apps. |
|
3)
Message boards :
Number crunching :
Down for maintenance?
(Message 37503)
Posted 18 Mar 2010 by Slicker [TopGun]
Post: "90% off my GPU time should be used for MW, so i often just stop Collatz to fetch new work (YES i know not the best way ;) ). So i waste yesterday about 2 hours of GPUtime. Idle sucks :/" If MW takes 1:40 and you have it limited to GPU crunching and a quad core, you can get 6 * 4 WUs @ 1.40 = ~40 minutes of work. So, set your additional network resources to only allow 0.03 days cache and it won't fill several days cache of Collatz when MW is down. Since BOINC processes GPU results in first in, first out order, it will only have to process about 7 Collatz WUs before it switches back to MW when MW comes back online. At least, in theory, that is how BOINC should work. ;-) |
|
4)
Message boards :
Number crunching :
Down for maintenance?
(Message 37502)
Posted 18 Mar 2010 by Slicker [TopGun]
Post: Collatz swamped? Yep. Normal is about 300 concurrent users. This a.m. there were over 700. It seems to have settled back down now but the feeder is still having trouble keeping up. Once everyone' caches are full, it should be able to handle it. The "return results immediately" setting that many have turned on in order to attempt to keep their MW cache full at 6 WUs per core on MW doesn't help any. Contacting the server when multiple WUs are completed verses after each one is done would reduce the Collatz server load considerable (70% or more!). If a machine has 4 GPUs and each can do a WU in 10 minutes, then it contacts the server every 2.5 minutes instead of once every couple hours (because of a cache size of over a hundred WUs on Collatz) if the results are returned immediately. While the user gets instant gratification, it really pounds on the server and eventually, the server gets overwhelmed. |
|
5)
Message boards :
Number crunching :
Testing ATI Application Availability
(Message 35618)
Posted 13 Jan 2010 by Slicker [TopGun]
Post: I suppose that we loose possibility to process 2 WU at a time without app_info.xml. Not necessarily, but it requires a change on the MW server. The same XML that you would have in the app_info.xml is also sent by the server when using standard apps. In order to get it to run 2 WUs at a time, the server needs to set <count>0.5</count> instead of <count>1.0</count> when it sends the response. I don't remember if that code is in the sched_customize.cpp or not, but that's the first place I'd look. To get the app_info.xml to work, you should be able to take a look at the response xml in the boinc data folder (not the project folder) without using the app_info. Then edit your app_info to look the same but with <count>0.5</count> instead of <count>1.0</count>. |
|
6)
Message boards :
Number crunching :
MW Preferences are Gone!
(Message 35095)
Posted 5 Jan 2010 by Slicker [TopGun]
Post: Mine work OK as well. I had to recreate the work, home, etc. but they are all working OK. |
|
7)
Message boards :
Number crunching :
MW Preferences are Gone!
(Message 35027)
Posted 2 Jan 2010 by Slicker [TopGun]
Post: Added home with GPU turned off and it didn't seem to work, or at least it doesn't show up. Also tried changing the default to disable gpu and enable cpu and that doesn't appear to have worked either. |
|
8)
Message boards :
Number crunching :
MW Preferences are Gone!
(Message 34916)
Posted 30 Dec 2009 by Slicker [TopGun]
Post: I changed some preferences two days ago. Went back today because it didn't seem like they were set. They were all gone. Attempting to change them does nothing. It appears that whatever was done to fix the DB problems yesterday introduced a new set of problems with the project preferences. Either they are still in the DB but the php pages can't access them, or the DB needs some updates to go along with the php changes, or they really did get wiped out. I don't think that is the case though since the resource share I had set for the default still shows up. |
|
9)
Message boards :
Number crunching :
Temporary Availability of the ATI application through BOINC
(Message 31006)
Posted 15 Sep 2009 by Slicker [TopGun]
Post: Don't feel bad that it didn't work or that the server was the reason. The Collatz project is running server 611 and it still doesn't work. Even in 611, the sched_customize.cpp didn't have ATI listed as using the gpu. I modified it as follows, but there are still a few other items missing as it still doesn't work.
bool app_plan_uses_gpu(const char* plan_class) {
if (!strcmp(plan_class, "cuda")) {
return true;
}
//the following test is missing in 611 code
if (!strcmp(plan_class, "ati")) {
return true;
}
return false;
}
|
|
10)
Message boards :
Number crunching :
ps_sgr_235_3s errors remain
(Message 24775)
Posted 10 Jun 2009 by Slicker [TopGun]
Post: running: FYI...Updating .NET from 2.0 to 3.5 took care of the problem. |
|
11)
Message boards :
Number crunching :
Work Availability v2 (June 9)
(Message 24769)
Posted 10 Jun 2009 by Slicker [TopGun]
Post: Happy happy joy joy! |
|
12)
Message boards :
Number crunching :
ps_sgr_235_3s errors remain
(Message 24764)
Posted 10 Jun 2009 by Slicker [TopGun]
Post: running: I should also note that it is running on an HD3870. The same software (drivers, ati app, catalyst version) runs fine on an HD4870 card so it isn't that it won't run on W2K3 x64. I also tried setting the card to the minimum speed and memory settings to no avail. |
|
13)
Message boards :
Number crunching :
ps_sgr_235_3s errors remain
(Message 24762)
Posted 10 Jun 2009 by Slicker [TopGun]
Post: running: ATI app version 0.19f Op Sys: Windows Server 2003 x64 Catalyst driver: v8.12 for wu: ps_sgr_208_2s_6_265084_1244600870_0 <core_client_version>6.5.0</core_client_version> <![CDATA[ <message> There are no child processes to wait for. (0x80) - exit code 128 (0x80) </message> ]]> I also get the same error for every WU in the 3s_5 range such as ps_sgr_235_3s_5_262944_1244600626_0 |
|
14)
Message boards :
Number crunching :
Work Availability?
(Message 24671)
Posted 9 Jun 2009 by Slicker [TopGun]
Post: Now that we've had a few days for the server changes to settle down, let's take a look at the stats to see what effect, if any, the changes have actually had... Total average daily production for the MW project: 5/13 thru 5/31: 13,896,075 credits 6/2 thru 6/8: 12,380,912 credits 6/1 was not included since that was the day the server setting was changed. In other words, the new server settings have resulted in an 11% average drop in credits per day. Less credit = less WUs completed = less science done. Right? I'm guessing that wasn't part of the desired effect. Stats taken from Free-DC |
|
15)
Message boards :
Number crunching :
Work Availability?
(Message 24141)
Posted 4 Jun 2009 by Slicker [TopGun]
Post: Anyone else notice that the WUs in process shown on the server status page has dropped from 36K to 30K ever since increasing the wait period from 7 to 60 seconds? Prior to the optimized apps (CPU and ATI), there were as many as 150,000 to 200,000 in process at a time if I remember right. If that's the case, it seems to me that UP is the direction to be headed and that the recent change made it go DOWN instead. |
|
16)
Message boards :
Number crunching :
Why is it so hard to get work?
(Message 23376)
Posted 26 May 2009 by Slicker [TopGun]
Post: Q: What do you get when you mix astrophysicists, computers, and crunchers? A: I'll let you know once the whining stops. I had a CEO once tell me "Morale is your own %$&* problem. If you don't like it, leave!" So, I left. I didn't leave because I was unhappy or because the guy was an idiot, but because I didn't think that he had any intention of trying to improve things to get the company back on track. That isn't the case with the MW team. While they may be going for a Guiness World Record for the longest running boinc project in alpha status, Travis and company are actively working on a resolution. They have been for several months. Sure, we wish it would happen ASAP, but I also wish I was sitting on a beach in the tropics sipping a rum-runner. The MW team tried a few quick solutions with mixed results but decided a long term solution was the proper choice - one that would not only have enough WUs for everyone, but also be able to take advantage of the gpu's capabilities and do even more science. In the mean time, I'll stick it out whether there are enough WUs to go around or not because they at least are trying to fix it, and not with some band aid. I'll live with boxes sitting idle or crunching other projects for now and hope for the best. Until then, I'll take what I can get. |
|
17)
Message boards :
Application Code Discussion :
CUDA Milkyway Application v0.05
(Message 23019)
Posted 22 May 2009 by Slicker [TopGun]
Post: To get the cuda lib and boinc libs to play nice, my solution has been to split the code into cuda and non-cuda sections and not include the boinc headers in any of the cuda code. Instead, introduce a middle tier in C which is nothing more than a pass-thru between the boinc C code and the cuda code. e.g. instead of Boinc-Code -> CUDA-Code you would do Boinc-Code -> non-Boinc-CUDA-wrapper w/o boinc headers -> CUDA-Code If you need to do IO in the cuda portion of the app, you can pass an MFILE pointer to the cuda code and include only the MFILE.H header and it will still "play nice" with the cuda code. So, you can still write buffered output within the cuda code. |
|
18)
Message boards :
Number crunching :
MilkyWay_GPU
(Message 21195)
Posted 3 May 2009 by Slicker [TopGun]
Post: Step 10. You chew off someones head one day since you were up until 3 am the night before figuring out why the results when using multidimensional streams are so screwed up until you realize that the gpu multi-dimensional arrays don't necessarily use J[x][y] but rather J[y][x] which really starts to matter when x and y are not equal. You did tell me and after I went back and re-read your message, it became obvious what the problem was. ;) You assistance helped a lot. I haven't given up on the yet un-named project. I have versions for cpu, cuda, and ati generating correct results, but none are optimized very well and I haven't started on the server daemons yet either, so it will be a while. |
|
19)
Message boards :
Number crunching :
MilkyWay_GPU
(Message 21105)
Posted 2 May 2009 by Slicker [TopGun]
Post: I wish the GPU team was a little more forecomig with the updates .... The History of MW GPU by Slicker Step 1. Download latest nVidia drivers. Step 2. Download CUDA toolkit and SDK. Step 3. Install VS C++ (hope the academic version works ok....) Step 4. Compile and run "Hello World" successfully. (yep it does.) Step 5. Announce you are almost ready to release the CUDA app. Step 6. Discover it takes longer for the CUDA version to run than the CPU version. Oops. Looks like some optimization is required. Step 7. RTFM. (Then again. And again. And again, but this time only the text since you finally figured out the diagrams are all marketing hype anyway written by some high priced consultant who is a master at powerpoint.) Step 8. Rewrite the code to use streams, async calls, adjust the thread and block sizes, decide when to use shared memory. Step 9. Recompile. App runs really fast now but gives wrong results. The code is now 10 times more complicated with all the optimization in place and just a bugger to debug. Plus, you can't afford to puchase an nVidia card since you spent all your money to buy kleenex to wipe off your brown nose. Step 10. You chew off someones head one day since you were up until 3 am the night before figuring out why the results when using multidimensional streams are so screwed up until you realize that the gpu multi-dimensional arrays don't necessarily use J[x][y] but rather J[y][x] which really starts to matter when x and y are not equal. Step 11. Frustrated, you give up for now. Determine whether you have enough in the budget to hire Gipsel, Crunch3r, etc. to fix it and then optimize it for you -- but you don't. Step 12. After finally getting the app working, you find out that the boinc server code is flawed but rather than just fix it, you ask for permission first. Hindsight being 20/20, you now realize that you have now learned that it is better to beg for forgiveness later than to ask for permissions first. Step 13. You decide to get a Ph.D. in communications instead of continuing your scientific endeavors and then just drop off the face of the earth. Step 14. People start making up stories with "16 steps" in one of several GPU announcement threads all of which are now totally off topic. Step 15. The undergrad developers who have really been doing all the work for minimum wage get the code working. They release it. It works really well. It gives 1000 credits per second. Step 16. DA shuts it down. The end. |
|
20)
Message boards :
Number crunching :
MilkyWay_GPU
(Message 20302)
Posted 24 Apr 2009 by Slicker [TopGun]
Post: Yeah, and when OpenCL is released for CUDA and Stream, my own work simulations as well. Yes, but only for the "chosen" ones, not the public. Per their site: NVIDIA will be Beta testing OpenCL with strategic developers this year. Please check back here for updates! |
Next 20
©2024 Astroinformatics Group