Message boards :
Number crunching :
And if we DONT run a "FASTER" App.?
Message board moderation
Previous · 1 · 2 · 3
Author | Message |
---|---|
![]() ![]() Send message Joined: 24 Dec 07 Posts: 1947 Credit: 240,884,648 RAC: 0 ![]() ![]() |
We all joined because of the science in the first place right? My bold emphasis.... I currently have a 9600GT which gets about 3300 cs a day....cost me $180 Australian. I have been thinking of getting a GTX280 for around A$700 - which would get a RAC of around 15,000. Best bang for a buck going around - anywhere! |
Send message Joined: 10 Dec 07 Posts: 36 Credit: 5,152,242 RAC: 0 ![]() ![]() |
And what would the theoretical RAC be if you placed a GTX280 onto a Yorkfield Quad? (not that I am planning such) -ChinookFöhn |
Send message Joined: 20 Mar 08 Posts: 2 Credit: 111,498 RAC: 0 ![]() ![]() |
I'm happy with the new, optimized app (on my Windows and Linux machines). It makes sense to me to have one that isn't wasting lots of time in the middle of loops and such. The current credit arrangement for the faster/optimized app works well for me. Before the changes, I BOINCed both machines 24 hours every day. I still do, though the MilkyWay percentage has increased some. So, the amount of science being done on my computers has significantly increased (due both to the new MW app running many more WU per hour and to the changed apportionment of hours per machine). I still run all seven BOINC apps that I ran before: it's just that MilkyWay's time portion has increased somewhat. Well done, MilkyWay team and app optimizers! |
Send message Joined: 1 Sep 08 Posts: 520 Credit: 302,525,188 RAC: 1 ![]() ![]() ![]() |
Well, I'm pleased with the optimization, but these itty bitty work units with a 20 work unit per cpu cache combined with the difficulty the project has in keeping the available workunits to download in a reasonable range is something of a pain. I REALLY hope that they come up with an longer cycle work unit (say something that runs for 1 to 2 hours) while keeping up the work unit production volume and existing cache rules. That would reduce the amount of manual forcing to get work that I've found I need to engage in. I suppose one might be able to create a script which essentially continually hammers the server for downloads, but I don't think that's a particularly 'polite' solution. As it is, for me, the amount of work I'm doing for other projects simply because Milkyway workunits are not on the workstation for fair sized time periods is not a bad thing. I'm happy with the new, optimized app (on my Windows and Linux machines). It makes sense to me to have one that isn't wasting lots of time in the middle of loops and such. ![]() |
![]() ![]() Send message Joined: 24 Dec 07 Posts: 1947 Credit: 240,884,648 RAC: 0 ![]() ![]() |
And what would the theoretical RAC be if you placed a GTX280 onto a Yorkfield Quad? (not that I am planning such) Depends on the project and the optimisation used ;) For example my Q9450 will get 10,000 RAC on Milkyway (if it can get continuous work and I only do MW) plus the GTX280 would give a RAC of 25,000! :drool: |
Send message Joined: 20 Mar 08 Posts: 2 Credit: 111,498 RAC: 0 ![]() ![]() |
I REALLY hope that they come up with an longer cycle work unit (say something that runs for 1 to 2 hours) while keeping up the work unit production volume and existing cache rules. That would reduce the amount of manual forcing to get work that I've found I need to engage in. Good point, and I agree. Currently, I check my MW PC a few times per day (and sometimes have to do the manual forcing you mention) due to the 20 WU limit and the short nature of those units. It would be more convenient if the WUs were longer (at least for optimized machines) or if more were permitted for optimized machines. In my experience, the current arrangement isn't as bad (for me) as others have discussed, but it could be somewhat better as you describe, which would move it from "fine" to "great" for me. In my previous post, I just wanted to mention that things aren't as bad for all crunchers as some posts might indicate <g> and that things are really OK in some cases. But, as your suggestion shows, there's room to go from "OK" to "superior" in the future. |
Send message Joined: 1 Sep 08 Posts: 520 Credit: 302,525,188 RAC: 1 ![]() ![]() ![]() |
If I were running Pentium 2's or AMD 450's the current set up might be workable -- I'm not and its not. But my other projects are saying thank you. New work units which run 1 to 2 hours each on the optimized application are critically needed to maintain a steady work flow without manual intervention (which sometimes doesn't work either). Elsewise this project may go the way of other small projects overwhelmed by more CPU's than work. I REALLY hope that they come up with an longer cycle work unit (say something that runs for 1 to 2 hours) while keeping up the work unit production volume and existing cache rules. That would reduce the amount of manual forcing to get work that I've found I need to engage in. ![]() |
![]() ![]() Send message Joined: 22 Mar 08 Posts: 90 Credit: 501,728 RAC: 0 ![]() ![]() |
Question:,... I'm trying to get test wu's on a 3.0 Xeon Quad running the "stock" App. I'm also running the optimized app.on a OLD 266g p-4, Both running XP. The credits on the old box (31-per 15min per wu) per wu aren't going to be the same as the Quad are they? The Quad takes about 10hr's per wu! Will I still receive FULL credit (260) for the stock app.? A clear conscience is usually the sign of a bad memory ![]() |
©2024 Astroinformatics Group