Advanced search

Message boards : Number crunching : Re Toni_TAKE3

Author Message
TylerChris
Send message
Joined: 12 Feb 10
Posts: 11
Credit: 50,020,466
RAC: 0
Level
Thr
Scientific publications
watwatwatwatwatwatwatwat
Message 23475 - Posted: 16 Feb 2012 | 0:27:16 UTC

Just completed one of these WUs, took around 2 hours.
Received 5921 credits for it.
Have done just the one wu at donate at home in under half the time on the same GPU.
Received 6250 credits for it.
This speaks volumes regarding priorities, and the value of science over money.
Can no longer respect the aims of the team here.
Have withdrawn the card from the project.

Profile skgiven
Volunteer moderator
Volunteer tester
Avatar
Send message
Joined: 23 Apr 09
Posts: 3968
Credit: 1,995,359,260
RAC: 0
Level
His
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 23479 - Posted: 16 Feb 2012 | 2:20:39 UTC - in response to Message 23475.
Last modified: 16 Feb 2012 | 2:22:26 UTC

So you ran one normal length task and jumped to the conclusion that GPUGrid has been knocked down the pecking order!
Sort of ignores all the other Long tasks you ran that rewarded the usual high credit.

As already reported these Toni tasks are being prioritized into the Long queue to expedite some outstanding research.
So the research is coming first within the GPUGrid project never mind the research group.
Tasks of this size normally go into the normal queue. Their credit matches that of the normal tasks here, which is less than Long tasks. There won't be many of these Toni tasks in the Long queue (which was also depleted recently).

I have already worked out that the credit CC2.0 cards get by running Long tasks here is the same or slightly more than D@H (often 10 to 20% more, depending on the task), at least for well optimized systems.

You are using W7, which is at least 11% slower than XP here. Even so, running Long tasks here you would on average get ~10% more credit, not half the credit!

One of Nate's tasks that you finished nice and quick for full bonus credit:
I5R15-NATHAN_CB1_1-61-125-RND8108_0 3145557 12 Feb 2012 | 0:39:41 UTC 12 Feb 2012 | 8:49:43 UTC Completed and validated 16,647.80 1,584.94 35,811.00 Long runs (8-12 hours on fastest card) v6.15 (cuda31)
86400/16648=5.19 tasks per day.
5.19tasks per dayX35811credits/task=185852 credits per day.

Anyway D@H is a one week old Alpha project, and as such the apps are not well tuned so errors occur, reducing actual credit averages.
Also, you can't use XP there, and XP is best here.

Bottom line is, high end NVidia cards belong here and not at D@H.
Use your low or mid range NVidia cards there by all means and chip in now and again if you want but AMD's are better there. Those using their NVidia cards there now are supporting the start of a new alpha project and all that goes with alpha testing. GPUGrid is the main project, not an offshoot or an alpha project.
____________
FAQ's

HOW TO:
- Opt out of Beta Tests
- Ask for Help

Simba123
Send message
Joined: 5 Dec 11
Posts: 147
Credit: 69,970,684
RAC: 0
Level
Thr
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwat
Message 23481 - Posted: 16 Feb 2012 | 3:36:29 UTC

I thought I read somewhere that the ToniTake3 in the long queue were
going to produce points as if they were long units instead of short ones?

Or am I wrong?



Profile skgiven
Volunteer moderator
Volunteer tester
Avatar
Send message
Joined: 23 Apr 09
Posts: 3968
Credit: 1,995,359,260
RAC: 0
Level
His
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 23483 - Posted: 16 Feb 2012 | 10:05:25 UTC - in response to Message 23481.
Last modified: 16 Feb 2012 | 10:08:30 UTC

Yeah, that's part of the plan, if any more are released as Long tasks (whatever the name).

"TAKE wus in the long wu should be almost finished. I created some more in the normal queue" - Toni.

Question from Sabroe SMC, "The Credits for this WUs are fair too low. Only 9000Cr for 9000 sec of crunching. Nathan and Giannis gave the double". Response from Toni, "They should be in line with the short wus".

News : New wus on the long queue
____________
FAQ's

HOW TO:
- Opt out of Beta Tests
- Ask for Help

Toni
Volunteer moderator
Project administrator
Project developer
Project tester
Project scientist
Send message
Joined: 9 Dec 08
Posts: 1006
Credit: 5,068,599
RAC: 0
Level
Ser
Scientific publications
watwatwatwat
Message 23484 - Posted: 16 Feb 2012 | 10:32:52 UTC - in response to Message 23483.
Last modified: 16 Feb 2012 | 11:05:07 UTC

TAKE3, being in the long queue, should have been double credits. That was my mistake. I did not cancel them because there are not many of them.

Just a bit of background. I tend to refrain from aborting jobs due to "minor" errors (with some definition of "minor" with which you might not agree). There are three reasons: (a) it delays research results, because all of the results need be analyzed in batch; (b) it wastes computing power, because typically a fraction of the aborted WUs still manages to start, but is not usable, or becames a duplicate of the next resubmission, and so on; (c) it is time taken from research and put into technicalities.

T

Toni
Volunteer moderator
Project administrator
Project developer
Project tester
Project scientist
Send message
Joined: 9 Dec 08
Posts: 1006
Credit: 5,068,599
RAC: 0
Level
Ser
Scientific publications
watwatwatwat
Message 23491 - Posted: 16 Feb 2012 | 17:52:10 UTC - in response to Message 23484.
Last modified: 16 Feb 2012 | 18:01:03 UTC

I've made an emergency fix so that TAKE3 jobs will give 10000 credits + bonuses each, but this will apply only the the newly-created workunits.

Profile [PUGLIA] kidkidkid3
Avatar
Send message
Joined: 23 Feb 11
Posts: 81
Credit: 954,353,044
RAC: 218,738
Level
Glu
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 23493 - Posted: 16 Feb 2012 | 19:27:20 UTC

Hi all,
my first run of a WU ACEMD2 on a GTS450 (1Gb DDR5) ended correctly.
The description of work is full of this warning :

.
. (a lot of this)
.
MDIO: cannot open file "restart.coor"
# Using device 0
# There is 1 device supporting CUDA
# Device 0: "GeForce GTS 450"
# Clock rate: 1.62 GHz
# Total amount of global memory: 1073741824 bytes
# Number of multiprocessors: 4
# Number of cores: 32
MDIO: cannot open file "restart.coor"
# Time per step (avg over 2000000 steps): 32.448 ms
# Approximate elapsed time for entire WU: 64895.810 s
called boinc_finish


Is this normal or i made some error ?
Thanks in advance

Profile skgiven
Volunteer moderator
Volunteer tester
Avatar
Send message
Joined: 23 Apr 09
Posts: 3968
Credit: 1,995,359,260
RAC: 0
Level
His
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 23494 - Posted: 16 Feb 2012 | 20:06:59 UTC - in response to Message 23493.

Welcome to the Forum.

The task ran OK.

MDIO: cannot open file "restart.coor" - is not an error.
____________
FAQ's

HOW TO:
- Opt out of Beta Tests
- Ask for Help

TylerChris
Send message
Joined: 12 Feb 10
Posts: 11
Credit: 50,020,466
RAC: 0
Level
Thr
Scientific publications
watwatwatwatwatwatwatwat
Message 23502 - Posted: 17 Feb 2012 | 12:15:04 UTC
Last modified: 17 Feb 2012 | 12:18:39 UTC

Hi skgiven
Have enjoyed reading your posts for sometime here and at WCG. have always found them to be constructive as well as informative however I feel you have missed the point here.
Will try again using your 470's as the example.
You wrote:

So you ran one normal length task and jumped to the conclusion that GPUGrid has been knocked down the pecking order!
Sort of ignores all the other Long tasks you ran that rewarded the usual high credit.

Err no
Used that task as an example to show the discrepancy as have not crunched any ACEMD2 tasks for a while,so had nothing to link to.
Your 470s crunching at donate @home here
To summarise they took around 3700 secs for 6250 credits.
now take a look at the same gpus crunching ACEMD2 tasks here.
Think the comparison is pretty clear.Around twice as many credits are granted for filling the coffers as is for the science.
You wrote;
I have already worked out that the credit CC2.0 cards get by running Long tasks here is the same or slightly more than D@H (often 10 to 20% more, depending on the task), at least for well optimized systems

Yes the Long tasks, a good amount of crunching here is on the ACEMD2 tasks that do not carry a 50% bonus .Take the bonus away then what do you have? do the donate at home have a 24 hour deadline with less credits granted if not reached?
You wrote;
You are using W7, which is at least 11% slower than XP here. Even so, running Long tasks here you would on average get ~10% more credit, not half the credit!

What has windows got to do with the argument? yes windows 7 is a little slower but does not change the maths much.
Have withdrawn the card from the project because I think the projects values are wrong, in my opinion the science should be valued more highly than bitcoin mining from it's volunteers.
The credit system as it stands as I see it is,crunch ACEMD2 we will award you a few credits.
But come over to donate@home and stick money in the coffers and we will give you at least double credits.
Hope this makes my position clearer.

Profile skgiven
Volunteer moderator
Volunteer tester
Avatar
Send message
Joined: 23 Apr 09
Posts: 3968
Credit: 1,995,359,260
RAC: 0
Level
His
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 23503 - Posted: 17 Feb 2012 | 14:19:55 UTC - in response to Message 23502.
Last modified: 17 Feb 2012 | 15:01:44 UTC

Suggestions were already made to increase the credit for normal tasks where they are returned very earlier. The was primarily to allow people with high end cards to run some normal tasks (badge system related) without seeing a massive dip in credit RAC. This project is different and weight is put behind the fast return of long results as their actual value to the project is much greater than the slow return of the short tasks. The credit here accurately reflects the needs of this project, and the input of fast turnover vs slow. The credit system here has been modified and adapted over the years, accounting for things such as application performance increases. It does not take into account other unrelated and uncomparable credit systems, especially those for projects that turned up after this one.

The credit at D@H is 10 or 20% lower for top NVidia card there than it is here if running the Long tasks (which are best for credit here). So you can usually get up to 20% more credit here with big cards by selecting to run Long tasks. Obviously if you have a lesser card here and run normal length tasks you will get less credit. Well, in theory.

How important is Alpha testing relative to normal running? More so; it allows people to troubleshoot, debug, find optimal settings... The contribution of these people facilitates all those that come along later. Many people have issues such as tasks running continuously (reaching 100% and just keep going for ever), some people have had strings of failures, and I have seen many tasks freeze/crash or not start, due to immature apps and bad settings. I was somewhat surprised to find that you also needed to free a CPU thread, without doing so could cost you 20% credit. Surprised because of the low CPU usage of the app. Anyway, I only ran a few NVidia tasks on one card during early testing before bringing it back here. I use my AMD GPU at D@H and POEM. Stopped using it at MW months ago. After a week of D@H alpha testing we know task size cannot increase as there is no checkpointing... So as you can see, the theoretical maximum credits per day are very much theory - most people encounter issues, and don't get maximum credits. D@H is nothing like GPUGrid, so even trying to compare credit system is folly. Its probably closer to some maths projects.

In the first couple of days the D@H credit was checked specifically and was left alone as the top NVidia cards would get more credit here, and on average they do. CC2.1 cards will get around the same or slightly less, and cards running the shorter tasks will obviously not get the long task bonus here, but that should be seen as reflecting this projects needs rather than the D@H project.
A lot of this is somewhat unimportant, especially in the long run:
Firstly ATI/AMD cards are about 3 times as fast at D@H so are much better suited to that project. NVidia cards are relatively poor.
We are also around a month from seeing GF600 cards, which may or may not improve upon their implementation of the calculation that allows ATI to card perform better.
AMD 7700 cards have just been released and and untested as yet.
AMD 7800's are also out next month.
The apps have only just been improved for the 7900's (performance doubled) to the extent that they match the 6900 series. It will take time and development before the bugs are ironed out and apps are optimized for all of the 7000 series cards and the GF600's. Until then the credit per task will remain static but peoples RAC will vary with changes in app performance.

You should be crunching here because GPUGrid does Bio-molecular modeling on GPU's, expands science, knowledge and helps finds cures for illnesses, despite any credit system concerns (which are a meaningless mess Boinc-wide). It matters little to me if I have 210M Boinc Credits or 230M!
____________
FAQ's

HOW TO:
- Opt out of Beta Tests
- Ask for Help

Profile SMTB1963
Avatar
Send message
Joined: 27 Jun 10
Posts: 38
Credit: 524,420,921
RAC: 0
Level
Lys
Scientific publications
watwatwatwatwatwatwatwatwatwatwat
Message 23506 - Posted: 17 Feb 2012 | 17:59:25 UTC - in response to Message 23503.

skgiven writes:

The credit at D@H is 10 or 20% lower for top NVidia card there than it is here if running the Long tasks

ATI/AMD cards are about 3 times as fast at D@H so are much better suited to that project.

It's astonishing to me that anyone could look at these two statements and fail to see a problem. You can argue all you want about TylerChris' specific example, but IMO he has raised a valid point.

@TylerChris: I hope you will reconsider withdrawing your support...things are still at a very early stage with D@H, and my guess is that policies regarding these matters are still being formulated. Despite skgiven's somewhat argumentative tone, the leadership here has demonstrated they are listening to volunteer concerns - so no need to do anything rash ATM. : )

We are also around a month from seeing GF600 cards, which may or may not improve upon their implementation of the calculation that allows ATI to card perform better.

So what? If Kepler changes the bitcoin performance equation when it comes out, fine. In the meantime, it is ridiculous to purpose ANY nVidia card for bitcoin mining. You know it, I know it, GDF knows it, and every noob miner on the bitcoin network knows it.

While I strongly believe bitcoin (as it currently stands) is NOT worth supporting, I recognize that people of good conscience can arrive at a different conclusion when it comes to supporting GPUGRID through D@H. But the current BOINC credit awards for nVidia participation in D@H are a perverse incentive to engage in a woefully inefficient activity. That Kepler may or may not remedy the problem in the future is a very poor argument for allowing the current situation to continue.

Toni
Volunteer moderator
Project administrator
Project developer
Project tester
Project scientist
Send message
Joined: 9 Dec 08
Posts: 1006
Credit: 5,068,599
RAC: 0
Level
Ser
Scientific publications
watwatwatwat
Message 23516 - Posted: 18 Feb 2012 | 12:50:16 UTC - in response to Message 23506.
Last modified: 18 Feb 2012 | 13:47:57 UTC

D@H is a different project, just like hundreds of others. Each has its credits/work ratio, for various reasons, mostly related to the impossibility to precisely measure flops performed. Credits in-equality between projects is not a new discovery. This may not be the right thread to discuss it.

The only real solution is to put the credits in perspective and give them their real value: none. Crunch, instead, for the project that you think it's best serving science. Credit-shopping, as well as complaining about missing points is, IMHO, wasteful for everyone's time but - again - it's one's choice.

We DO thank you for the effort that you put in supporting our simulations. Attempting to quantify the amount of "thanks" with a precisely assigned amount of credits may be an excess of formalization.

Profile GDF
Volunteer moderator
Project administrator
Project developer
Project tester
Volunteer developer
Volunteer tester
Project scientist
Send message
Joined: 14 Mar 07
Posts: 1957
Credit: 629,356
RAC: 0
Level
Gly
Scientific publications
watwatwatwatwat
Message 23520 - Posted: 18 Feb 2012 | 16:56:18 UTC - in response to Message 23516.
Last modified: 18 Feb 2012 | 17:38:49 UTC

The credit at donateathome.org will be close to the one at gpugrid for the short application, even if the ops/s is higher over there because the algorithm is simpler and the gpu can perform better. A first adjustment is already inside the new beta D@H app which is going to be released soon there.

gdf

Profile SMTB1963
Avatar
Send message
Joined: 27 Jun 10
Posts: 38
Credit: 524,420,921
RAC: 0
Level
Lys
Scientific publications
watwatwatwatwatwatwatwatwatwatwat
Message 23522 - Posted: 18 Feb 2012 | 21:12:59 UTC - in response to Message 23516.
Last modified: 18 Feb 2012 | 21:14:39 UTC

D@H is a different project, just like hundreds of others. Each has its credits/work ratio, for various reasons, mostly related to the impossibility to precisely measure flops performed. Credits in-equality between projects is not a new discovery. This may not be the right thread to discuss it.

The only real solution is to put the credits in perspective and give them their real value: none. Crunch, instead, for the project that you think it's best serving science.

While I tend to agree with your position on the value of credits, the reality is they do in fact serve as powerful incentives for how volunteers contribute their computing resources to GPUGRID and D@H.

Arguments along the lines of "we can't address this issue because it's impossible to precisely measure flops performed" don't carry a lot of weight in my book. Why? GPUGRID currently uses credit incentives without any regard at all to flops/mips/whatever for long vs short and <24hr vs >24hr workunits. These bonuses have nothing to do with GPU performance and everything to do with affecting volunteer behavior.

Presumably, the current GPUGRID bonus incentives exist to reward efficiency. If efficiency is a value that is shared by D@H, the possibility that there may be a problem with the way D@H credits are awarded relative to GPUGRID ought to be looked into instead of being dismissed out of hand. Further, there may be D@H volunteers running nVidia cards who might not realize that they are paying more money to their utility companies than they are generating for D@H. BOINC credits awarded at D@H don't seem to discourage this blatant inefficiency.

Profile skgiven
Volunteer moderator
Volunteer tester
Avatar
Send message
Joined: 23 Apr 09
Posts: 3968
Credit: 1,995,359,260
RAC: 0
Level
His
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 23528 - Posted: 19 Feb 2012 | 0:38:19 UTC - in response to Message 23522.

While I tend to agree with your position on the value of credits, the reality is they do in fact serve as powerful incentives for how volunteers contribute their computing resources to GPUGRID and D@H.

For some people, and to varying extents, but not all. I've never been tempted by the maths, chess or similar projects; I wouldn't spend money on the electric to find a prime number, but if someone else want to, that's up to them.
How many people do you think stopped crunching GPUGrid to crunch for D@H?

Arguments along the lines of "we can't address this issue because it's impossible to precisely measure flops performed" don't carry a lot of weight in my book. Why? GPUGRID currently uses credit incentives without any regard at all to flops/mips/whatever for long vs short and <24hr vs >24hr workunits. These bonuses have nothing to do with GPU performance and everything to do with affecting volunteer behavior.

If Boinc can affect the implementation of a universal GPU credit system that 'fairly' grants credit based on performance, and factors in considerations such as sp or dp, GPU utilization, CPU requirements, power requirements, other hardware requirements, bandwidth needs and so on, then great, they've got my backing 100%. The credit system here is based on steps (which reflects actual performance of the app on the GPU) and return time. Credit variation here exists due to the different task performances on the apps. GPUGrid usually runs several task types for different research projects.

Presumably, the current GPUGRID bonus incentives exist to reward efficiency.

Yes, and to pick up on concerns expressed earlier regarding the greenness of this system - running a high end card 24/7 is often twice as efficient (in terms of results per watt) as running lesser cards. Several of the crunchers here went well out of their way to produce performance per watt tables to encourage the purchase of greener cards for crunching. So yes, more credit is awarded for fast turnover of long tasks (which expedite the research over short tasks), and these tasks tend to be run on greener cards for crunching.

If efficiency is a value that is shared by D@H, the possibility that there may be a problem with the way D@H credits are awarded relative to GPUGRID ought to be looked into instead of being dismissed out of hand. Further, there may be D@H volunteers running nVidia cards who might not realize that they are paying more money to their utility companies than they are generating for D@H. BOINC credits awarded at D@H don't seem to discourage this blatant inefficiency.

The D@H credit system is more rudimentary. It rewards for task completion. The task runtimes are consistently similar on similar cards, so as with most projects faster cards get more credit, whether AMD or NVidia. Presently AMD cards are about three times as efficient generally. The problem with chaining the D@H credit system to reflect GPUGrid's is that they are two distinct projects with totally different tasks, apps and project needs. D@H has to work out what's right for D@H, and it will, in due course. Some credit changes are already planned there (comments and suggestions were considered, as normal), and the new credit system should go some way to alleviating your concerns.

However there is a problem with making such changes now. The apps are very immature. Even within the first week the performance on the HD 7900's doubled. So credit for some card types doubled in a week. I don't want to see the credit change every few days. The 7770 and 7750's are AFAIK untested, and performances may change dramatically with drivers or app refinements, for these and other cards. Performances are discussed openly in the threads there. With so many cards coming onto the market over the next few months, the efficiencies (GPU running cost vs pooled BC credit) for different cards is largely unknown. Obviously NVidia cards are not efficient now, but the developers still need a benchmark to work from, or they won't be able to compare the new cards. I don't anticipate many NVidia's being used at D@H, at least until GF600 arrives. At present some of the AMD cards would at least on average match BC's to running cost, but only in some areas where electric costs are low. Then there are clock settings to consider; overclocking &/or under-volting the GPU/stream processors/GDDR changes the picture again. For sure the more capable crunchers can configure their card and settings to make them more viable.

Everyone should remember it's an experimental project; everything is alpha.
____________
FAQ's

HOW TO:
- Opt out of Beta Tests
- Ask for Help

Profile SMTB1963
Avatar
Send message
Joined: 27 Jun 10
Posts: 38
Credit: 524,420,921
RAC: 0
Level
Lys
Scientific publications
watwatwatwatwatwatwatwatwatwatwat
Message 23552 - Posted: 19 Feb 2012 | 18:00:44 UTC - in response to Message 23528.
Last modified: 19 Feb 2012 | 18:02:34 UTC

Thanks for your detailed and thoughtful reply, skgiven. It appears that you and I agree on a great many things, like:

    Projects determine the credits awarded, not the BOINC client.
    Projects have discretion in determining the amount of credit awarded for task completion.
    BOINC credits may be granted based on factors other than GPU computing performance.
    BOINC credit influences volunteer behavior.
    Efficient utilization of volunteer computing resources is an important project objective.
    Project volunteers benefit from guidance on suitable hardware for a given project.


In light of the above, I'd like to pose following questions to you:

    Do you believe that D@H volunteers could find themselves paying more in electricity costs than the value of the BTC they generate for the project?
    Do you believe D@H project leadership has a duty to inform volunteers of this possibility?
    Do you believe such a situation is inefficient?
    Do you believe that D@H should structure its BOINC credit incentives to discourage volunteers from deploying hardware unsuitable for bitcoin mining?

____________________________________________

Concerning the issue raised by TaylorChris, I'm not advocating "chaining" D@H credits to GPUGRID credits - and I don't think he is either. I'm simply pointing out that since credit awards for both D@H and GPUGRID are controlled by the same group, and that the group has discretion in awarding credits, it makes perfect sense to maintain a balance of sorts between the two (if possible).

TaylorChris has pointed out what he feels is a gross imbalance between the two projects. I maintain that his complaints are valid, and should be listened to. Responses such as "Credits in-equality between projects is not a new discovery" would only be valid if TaylorChris was complaining about credit disparity between GPUGRID and Collatz/Einstein/etc. He isn't.

Lastly, I have no idea how many people have stopped crunching GPUGrid to crunch for D@H. Feel free to let us know if you have access to the data. What I do know is that TaylorChris has said he will quit GPUGRID. That matters.

Profile skgiven
Volunteer moderator
Volunteer tester
Avatar
Send message
Joined: 23 Apr 09
Posts: 3968
Credit: 1,995,359,260
RAC: 0
Level
His
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 23556 - Posted: 19 Feb 2012 | 20:01:07 UTC - in response to Message 23552.
Last modified: 19 Feb 2012 | 20:14:18 UTC

Do you believe that D@H volunteers could find themselves paying more in electricity costs than the value of the BTC they generate for the project?

They could, and individually some inevitably will. What people contribute with is down to individual choice. At present its an early/experimental project, with a range of cards being used, but many of the top crunchers have high end cards which in theory could generate more funds than their running costs. Ideally, as a pooled group of contributors the total cost of electric would be less than the value of BitCoins. This would obviously go some way to making this approach of generating funds more acceptable to those that don't accept it. If 'in the long-run' the cost of generating revenue is less than the expense of fueling the method, it will have been very worthwhile. If not then it's just a novel way of generating funds. This is what make the experiment interesting and challenging. If you want to donate and have a top AMD card for crunching anyway, and use it for mining as part of a collective group that could well be a better way to make a donation - if collectively you pay less for the electric than the actual donation. I would not however exclude people from donating on grounds of their GPU. In many ways some of the older cards actual value is low, so it's really just down to cost of electric vs collective donation. For new cards that would exclusively be used at D@H then you would have to factor in purchase cards, but I doubt that many people will do that.

Do you believe D@H project leadership has a duty to inform volunteers of this possibility?

I think that has already been done. I would prefer that there was more detailed stats, but at an early alpha stage (with apps failing, development ongoing) any such stats or tables would be temporary, and it would probably take as long to generate such tables as it would to improve the code (which is the priority at this stage).

Do you believe such a situation is inefficient?

I don't know how efficient the cards are at this stage; that would depend on electric costs of every crunchers individual cards, as well as clocks, card specs and so on. We don't have all that info.
Again, at this stage the cards will become more efficient with app development. So for example the doubling of performance of the 7900's may have made them efficient, but before that probably not. If performance improves again then their efficiency will improve too. New cards will change the whole picture.
So telling someone to not crunch on a card now might be counterproductive in the long run if it impedes development.

Do you believe that D@H should structure its BOINC credit incentives to discourage volunteers from deploying hardware unsuitable for bitcoin mining?

The present situation is sufficient in my opinion; the more 'efficient' cards generate more credit anyway. I expect most high end NVidia crunchers will use their cards here or at other GPU projects.
I have never had any inhibitions about telling someone their GPU specs are poor and 'not recommended' for the project, but at this stage I don't want to overly discourage the use of a card that might in the future be more efficient. While I don't think that present NVidia cards are 'efficient' or ever will be, it's down to an individuals choice and I'm slightly worried about making sweeping statements such as "NVidia cards give poor performance", not because it's inaccurate, but because that general impression might discourage people in a few months, possibly even for a GPU that is more efficient that AMD's (or not). Generic sweeping statements like that can pop-up in searches for years.
I would encourage crunchers at D@H to make their own calculations of 'efficiency'. Lists can be maintained by the community.

Some existing GPUGrid crunchers crunch at D@H, but mostly with AMD cards. Some former crunchers that presently just use AMD cards crunch at D@H, and some non-GPUGrid crunchers crunch at D@H (mostly AMD only crunchers). Overall there are not that many crunchers with credit, and there is not much work done on NVidia cards.
____________
FAQ's

HOW TO:
- Opt out of Beta Tests
- Ask for Help

Profile Mad Matt
Send message
Joined: 29 Aug 09
Posts: 28
Credit: 101,584,171
RAC: 0
Level
Cys
Scientific publications
watwatwatwatwatwatwatwatwatwatwat
Message 23701 - Posted: 29 Feb 2012 | 15:33:44 UTC

I don't understand the logic here. This project never has been paying extensively high credits. Everyone has seen what happened at Primegrid last year, up to the point where folks started selling ATI cards and replaced them by Nvidias.

If you just wanted to have that amount of computing power for science, you'd know what to do... So, why don't you?

Now on the other hand, it looks like you exactly know what to do to get ATIs on board. ;) That's really simple to me. Excuse me for ignoring more subtle arguments here, which certainly are valid. But at the end of the day, I think this is what matters. Ignoring competition on BOINC isn't realistic in my eyes.


____________

Post to thread

Message boards : Number crunching : Re Toni_TAKE3

//