I would like to propose a JIT policy be used on this project and I will attempt to articulate why.

In view of this projects need for a "FAST TURN AROUND" of WU's would a policy of ONE WU per GPU and a GPU only gets another when it has returned the last one. This simple policy would surely speed the throughput of WU's especially since GERARD has expressed on this forum a desire to do that and I would think he considers it an important goal.

This would also end the inefficiency of having a WU cached on one machine for several hours that could be RUNNING on another machine that can't get any work.

We could get a faster throughput of WU's and from that an increasing availability of new WU's because new WU's are generated from returned results.

Does that make sense to you?

I take your point SK but without sounding to be too harsh my suggestions are aimed at "project benefits" NOT "user benefits" although I'm sure some of the difficulties you mention could be mitigated.

My point of view is that, the project benefits are more important and while a few users may suffer I wouldn't let them become a bottleneck.

As for running 2 WU's on one GPU that has no project benefit whatsoever and is only designed to raise RAC. In fact it actually slows the project down

Sorry! I completely disagree with this suggestion! I wanted to propose quite the opposite: Three WUs per GPU!

I recently acquired two GTX 970 and put them in the same computer (quite an investment) and as many suggested I am running two WUs at the same time, just to get a better load on them! Nothing to do with your suggested RAC optimization, as you might well know if your read the forums and the experiences of GTX 980 (TI) owners.

Now with the new policy of GERARD of small batches I have a huge problem! I do receive four WUs in a short time and all finish more or less at the same time after 18 hours… (within 24 hours) and then they get stuck for several hours in the up-load queue, with luck it solves itself over the night or until I come back and up-load those units by hand!

It is because the Internet Provider from Spain applies out dated Internet Polices on its subsidiary branches in the Southern Hemisphere: High Fees, slow up- and down load speeds, guarantying only 10% of the announced speeds, and penalizing the up-load speed even more.

This translates in a minimum up-load time of 30-40 minutes for each WU (if it is one by one, and not in parallel) and often gets interrupted by other WUs starting to up-load from my other computers or from the receiving up-load server at GPUGRID.net and then it kicks in the awful BOINC policies of logarithmic waiting time for each stop and finally they do not up-loaded at all until I intervene manually.

If we had three or four WUs per GPU, at least I would be able to keep crunching until the first WUs have been up-loaded (automatically or by hand), but at the moment, the GPUs just sit idle!

Don’t suggest a secondary or alternative BOINC Project, I do have already some with recourse sharing set on 0%, this is not quite a solution:
1) I do have an emphasis on GPUGRID,
2) There are not a lot of projects that have short turnaround times (or do penalize short WUs like GPUGRID does itself), which is a necessity as it serves only for occiping the GPUs until there are new WUs from GPUGRID available.

There shall be more WUs available per GPU and not less for those crunching out-side Europe or North America and for those who have a slow Internet Connection!!

I like the JIT queue too, but as an option. That is, if people have good upload/download speeds and want to run only 1 work unit at a time, they could do it. Otherwise, they would use the normal queue.

But I doubt that they have enough work for both at the moment. In fact, I get the impression they mentioned the fast turn-around at all mainly because they don't. But if the work permits, I would opt for it myself.

Here's my thought:

Set the server to default to "1 task per GPU"
... but allow a web profile override, so the user could change it to "2 tasks per GPU", or even "3 tasks per GPU" (to better support the case where they actually run 2-per-GPU but are uploading).

Recap: "1 per GPU" by default, but overrideable by user to be 2 or 3.

However, for hosts that are not connected to the internet 24/7, the default setting may cause them to crunch less.

Honestly, I like the setting where it's at right now (server sends 2 per GPU), but wish we could have a web user override setting, for 3 per GPU.

I recently acquired two GTX 970 and put them in the same computer (quite an investment) and as many suggested I am running two WUs at the same time, just to get a better load on them! Nothing to do with your suggested RAC optimization

It's not that simple.

Sure, in situations where 1) the availability of work units depends on others being completed, AND 2) there are no work units available ... then doing 2-at-a-time can cause a decrease in overall project efficiency.

HOWEVER

In situations where work units are readily available ... then doing 2-at-a-time can cause an increase in overall project efficiency, because we can get them done ~10% quicker.

SO ... Please don't fault the users doing 2-at-a-time. If the admins believe that 1-at-a-time will help them more, then they could/should publicly request that, and some of us would be persuaded to revert to 1-at-a-time. But, in the meantime, if I can get work units done faster by 2-at-a-time, increasing my machines overall throughput, then I'm going to do that.

:)

Sure, in situations where 1) the availability of work units depends on others being completed, AND 2) there are no work units available ... then doing 2-at-a-time can cause a decrease in overall project efficiency.

In situations where work units are readily available ... then doing 2-at-a-time can cause an increase in overall project efficiency, because we can get them done ~10% quicker.

This project usually has tasks. So, the more common scenario is the scenario where 2-at-a-time would help.

I have temporarily set mine to 1-at-a-time, until plenty of work units are available.

Lighten up, please.

This project usually has tasks. So, the more common scenario is the scenario where 2-at-a-time would help.

there will NEVER be a time or situation when a small increase in throughput at the (large) expense of speed will be of any benefit to this project

Re-reading your initial first post, I do believe that there is a compromise that can be made server-side, but I don't know exactly what it is.

Perhaps if the server:
1) detects/estimates that it will come close to running out of work
AND
2) the remaining work units are of the type where new ones would be generated upon the completion of the existing work units
THEN ... the server could switch to a "hand out 1-per-GPU" mode.

If those conditions aren't met, it could switch back to "2-per-GPU" mode.

But the client will still crunch at their same x-per-GPU setting, which sort of sucks, since generally 2-at-a-time is better, but in cases like we have right now, 1-at-a-time is better. Ideally, it'd be best if that too could be controlled server-side, and I don't think it's outside the realms of possibility.

The server already, by default, currently says "run 1-at-a-time" (gpu_usage = 1.0), but imagine an additional user web setting that says "Run up to this many tasks per GPU", where the user can change the default from 1 to another value like 2 (gpu_usage = 0.5). Basically, then, the server can choose gpu_usage 0.5 when there's plenty of work available, but choose gpu_usage 1.0 when in "1-per-GPU" mode. And the user wouldn't need an app_config.xml file.

The whole thing would be dynamically controlled, server side. Complicated, but possible, I think. And it would surely increase throughput, during droughts.

I'd love to hear the admins respond to this proposal. I think it's a great compromise, that could fix multiple problems.

The server already, by default, currently says "run 1-at-a-time" (gpu_usage = 1.0), but imagine an additional user web setting that says "Run up to this many tasks per GPU", where the user can change the default from 1 to another value like 2 (gpu_usage = 0.5). Basically, then, the server can choose gpu_usage 0.5 when there's plenty of work available, but choose gpu_usage 1.0 when in "1-per-GPU" mode. And the user wouldn't need an app_config.xml file.

The whole thing would be dynamically controlled, server side. Complicated, but possible, I think. And it would surely increase throughput, during droughts.

This will handicap the hosts with lesser GPUs, but surely will decrease the overall processing time. I don't think the participants with lesser GPUs will appreciate much this though.
It's like Formula-1: if you over-complicate the rules, it will hurt competition.

I'm sorry guys but I think you are over thinking my original post.

One WU per GPU and you don't get another one until

you begin to upload last one
last one is 99% complete

Nobody needs to be alienated, leave the project, or have theit contribution or card questioned.

It really is that simple.

One WU per GPU and you don't get another one until

you begin to upload last one
last one is 99% complete

Folding handles it by awarding "Quick Return Bonus" points that rewards the faster cards more than they would normally be.

Also, they overlap the download of the new work unit with the finishing of the old work when it reaches 99% complete. I think that is why the Folding people never bought into BOINC, but developed their own control app. Maybe BOINC could adopt some part of it?

This is ok, but the BOINC client-server architecture is not working this way, because there's the concept of "reporting completed tasks": it's not just the host has to upload the result, it has to be reported to the server to begin further processing (awarding credits for it, comparing results from different host for validation, creating and issuing new tasks, etc). That's why the "report_results_immediately" option is recommended for GPUGrid users. But there's no preemptive way for sending workunits to hosts in BOINC.

One WU per GPU and you don't get another one until

Last WU is uploaded and credit is granted.

One WU per GPU and you don't get another one until

Last WU is uploaded and credit is granted.

OK with me, but I can (and do) accomplish that now with zero resource share. However, they could grease the wheels a little by providing more granularity in their bonus system. They are probably not prepared to do a full "Quick Return Bonus", which calculates the bonus on a continuous exponential curve, but they could provide more steps. For example, rather than just 24 and 48 hour bonus levels, they could start at 6 hours and have increments every six hours until maybe 36 hours. That would keep an incentive for the slower cards, while rewarding the faster cards appropriately. They can work out the numbers to suit themselves, but the infrastructure seems to be more or less in place for that already.

One WU per GPU and you don't get another one until

Last WU is uploaded and credit is granted.

OK with me, but I can (and do) accomplish that now with zero resource share. However, they could grease the wheels a little by providing more granularity in their bonus system. They are probably not prepared to do a full "Quick Return Bonus", which calculates the bonus on a continuous exponential curve, but they could provide more steps. For example, rather than just 24 and 48 hour bonus levels, they could start at 6 hours and have increments every six hours until maybe 36 hours. That would keep an incentive for the slower cards, while rewarding the faster cards appropriately. They can work out the numbers to suit themselves, but the infrastructure seems to be more or less in place for that already.

Before I go to bed.

Betting Slip starts his argument with the wrong hypothesis:

“GPUGRID project needs the fastest turnaround times possible and every second counts!”

This seems to me completely out of place:

First of all if a project needs a turnaround time that fasts, it’s on the wrong place with BOINC as its platform as it is a scientific citizen project depending on volunteers and their willingness to spend quite a lot of their money on hardware and energy. If there is really the need for turnaround times at the speed of light, I think the project shall pay its time on a supercomputer! As GPUGRID decided to use the BOINC platform, I do think the turnaround time is important but not every second counts, as Betting Slip likes to imply.

Second: As Gerard wrote in another post somewhere, there is an intellectual process in analyzing the generated data from the WUs and generating the next batch of WUs, as the scientist has to decide, where to go. So if GPUGRID really would need the results that fast as Betting Slip suggests, GPUGRID staff would have to work 24 hours / 7 days to analyze and generate new work, which it clearly does not, as normally WU shortage occurs over the weekends. And I think as it is a scientific research project publishing papers, it is not in a Formula 1 race, where every second counts!

This said, I think your suggestion of JIT(Just in Time) and all your further argumentation is discriminating all the participants which can not afford or are not willing to buy and/or replace the fastest GPU of every card generation, or with slow internet connections or do run two WUs at a time with no benefits what so ever for the project!

I would like to propose a JIT policy be used on this project and I will attempt to articulate why.

In view of this projects need for a "FAST TURN AROUND" of WU's would a policy of ONE WU per GPU and a GPU only gets another when it has returned the last one. This simple policy would surely speed the throughput of WU's especially since GERARD has expressed on this forum a desire to do that and I would think he considers it an important goal.

This would also end the inefficiency of having a WU cached on one machine for several hours that could be RUNNING on another machine that can't get any work.

We could get a faster throughput of WU's and from that an increasing availability of new WU's because new WU's are generated from returned results.

Does that make sense to you?

One WU per GPU and you don't get another one until

Last WU is uploaded and credit is granted.

OK with me, but I can (and do) accomplish that now with zero resource share. However, they could grease the wheels a little by providing more granularity in their bonus system. They are probably not prepared to do a full "Quick Return Bonus", which calculates the bonus on a continuous exponential curve, but they could provide more steps. For example, rather than just 24 and 48 hour bonus levels, they could start at 6 hours and have increments every six hours until maybe 36 hours. That would keep an incentive for the slower cards, while rewarding the faster cards appropriately. They can work out the numbers to suit themselves, but the infrastructure seems to be more or less in place for that already.

Besides it makes more "profitable" to have a low cache setting even for fast hosts.
So basically it will encourage everyone to lower their cache size.
I think this is a very good idea.

I would like to propose a JIT policy be used on this project and I will attempt to articulate why.

In view of this projects need for a "FAST TURN AROUND" of WU's would a policy of ONE WU per GPU and a GPU only gets another when it has returned the last one. This simple policy would surely speed the throughput of WU's especially since GERARD has expressed on this forum a desire to do that and I would think he considers it an important goal.

This would also end the inefficiency of having a WU cached on one machine for several hours that could be RUNNING on another machine that can't get any work.

We could get a faster throughput of WU's and from that an increasing availability of new WU's because new WU's are generated from returned results.

Does that make sense to you?

This proposition doesn't make much sense to me. If anything, it will only achieve to slow WU processing dramatically!

Requiring a WU just completed, in order to get another one, means hosts that have not just completed a WU (or new hosts getting in the project) will never get a new WU! Unless BOINC supports priority queuing (and the GPUGRID people implement it), this is simply not feasible.

Without priority queuing, and with the current scarceness of WUs, eventually most hosts in the project would be denied new WUs, with the exception of a few lucky / "chosen ones". Not efficient and not fair!

Since we are a wonderful community of crunchers, devoted to "The Science", affectionate and considerate to one-another (especially so the mega / divine crunchers towards the mere "mortal" crunchers), why don't we all lower our work buffer to something like 5 minutes (or even zero, why not??), so that the WU pool has as many available as possible?

Why can't those that run > 1 WU on 1 GPU revert back to 1-on-1, at least for the current "dry" period, sacrificing some "efficiency" (or is it "more creditzzz!") for the benefit of better WU distribution?

Why do we need the project to enforce fairness unto us, and not be fair by ourselves??

Maybe RAC is the single most important crunching motive after all...
____________

Everyone has his own definition of "fair". If I were to believe some of them (which is unlikely), "fair" means requiring the GPU manufacturers to limit the speed of their cards so that some of the crunchers on GPUGrid don't fall behind in the ratings.

My definition of "useful" is for the science of GPUGrid (and all the other projects) to be advanced as fast as is feasible. I let the scientists figure that out. Sometimes they want the largest number of work units possible but don't care much about the delay ("latency" in computer-ese), and other times they want the delay to be minimized, since that gets back results they need to build new work units based on those results faster. It ultimately is dictated by the science they are trying to do, and our ideas of "fairness" are more or less irrelevant insofar as I am concerned. I will adapt my equipment to their needs, rather than vice-versa, and maybe get some useful work done.

GPUGrid isn't my only project. I'm attached to 59 projects.

I run certain cache/buffer settings that minimize the RPCs to the projects' servers, while also keeping my GPUs satisfied despite the GPU Exclusions I have in place that cause work fetch problems.

And my goal is to maximize GPUGrid's ability to get work done, utilizing my resources. I couldn't care less about the credits. So, generally, to maximize utility, 2-on-a-GPU is the best way to do that.

If a change should be made to increase project utility during times when work units are scarce, it should be made server-side. I recommend my prior proposals.

I did not want to finish my point without some numbers.

But first reading a new the discussion from yesterday and all the answers from today, I would like to stress what a lively community we are! And there seems varying ways to be “fair”, and it seems that I have missed some.

I still would like to mention my own experience:
My GTX 570 and GTX 670 (both cards in the higher faster segments of its generation) are used to crunch one WU at the time: GTX570 needs around 76000 seconds to finish a Gerard (with bonuses 24 hour, 50% bonus RAC 255000) and the GTX 670 finishes in around 61000 seconds.
My GTX 970 loaded with two WUs at a time need for each 76000 seconds, which is in line with my GTX 570.
And at least the GTX 650 TI never meets the 24h deadline, needs around 127000 seconds and its usual RAC is 212000 for each Gerard.
I set a very low cache number for all cards, so I will receive new WUS only if the actual WU is nearly finished, otherwise I will miss the 24 limits more often on all cards as I do have very slow and unreliable internet connection.

The two WUs of the GTX970 are more or less in line with the same card segment on the previous two generations. The GTX650TI never finishes the WUs in 24 hours, and I would like to mention that in the forums you can read that GTX750 TI struggle to comply with the 24 hours limit as well.

Therefore I personally do believe JIT and its variants discussed in this forum are not fair at all, as it obliges to have always the fastest cards of each generation and therefore benefits the users who can afford changing their GPUs each generation and buy the fastest card of each generation.

So as we can see with all the comments, from the user side there should be a much liberty in deciding how to tweak / run the WUs on their computers within the established rules of GPUGRID to comply with the established 24 / 48 hours limits to their liking.

However Betting Slip I am open to any help to tweak my cards to increase the through put, as I am running all the cards out of the package, and do only set the fan speed as high as possible.

Therefore I personally do believe JIT and its variants discussed in this forum are not fair at all, as it obliges to have always the fastest cards of each generation and therefore benefits the users who can afford changing their GPUs each generation and buy the fastest card of each generation.

Maybe I took it personally, or just my tranquilizer had rolled away?

Since we are a wonderful community of crunchers, devoted to "The Science", affectionate and considerate to one-another (especially so the mega / divine crunchers towards the mere "mortal" crunchers), why don't we all lower our work buffer to something like 5 minutes (or even zero, why not??), so that the WU pool has as many available as possible?

Why can't those that run > 1 WU on 1 GPU revert back to 1-on-1, at least for the current "dry" period, sacrificing some "efficiency" (or is it "more creditzzz!") for the benefit of better WU distribution?

Why do we need the project to enforce fairness unto us, and not be fair by ourselves??

Maybe RAC is the single most important crunching motive after all...

The group you refer as "we all" does not exist as a single entity, therefore it can't act like a single entity, so must it be "governed" by rules and motives to act coherently and effectively. (e.g. there are many contributors who don't read the forum at all - so they don't know that they should do something.) How many people read this thread at all? It has 448 views so far - that's much less than the active contributors.

My personal reason to have a spare workunit is that I have a strong evidence, that it's in much better hands on my host than on a host which fail every single workunit. You can call it vigilantism, but it is certainly the result of the inadequate governing. (i.e. the server gives work for unreliable hosts)

Here we go again. Every time it comes to "reform" the credit system this assumption/accusation/disillusion is made.
Maybe we'll have a cure for those deadly illnesses in 10-15-20 years from now, and maybe this project will have a tiny part in it, but it is certainly not enough to convince the rest of the population to take part in it. I am confident of that we could have that cure right now, if all people of the wealthier part of the world would have been united 20 years ago for this goal, and would have been using their computers since then to take part in biomedical research, but they were playing 3D games, buying new cars & bigger houses instead. Why? Because they are motivated to do so, they are socialized to do so. The credit system is the only thing which could be the "interface" between the "material world" and the "BOINC world". Surely greed and vanity also came along from the real world, but that's human nature (that phrase again). By reforming the credit system we're trying to make the best out of it.

So, you're admitting that you're not willing to lower your work buffer voluntarily, and the only way for this to happen is for the project to enforce this on us.

That's a very selfish argument, which is also not valid: how do you know the results you return are not invalid, every single one of them?

GPUGRID has a quorum of one, which makes all returned results potentially invalid! Just because a task doesn't crash on you, doesn't mean it doesn't contain computation errors, especially when running on a GPU. Incidentally, I strongly believe GPUGRID should establish a quorum of two.

But, I hate hypocrisy! We're not only eager to help the project, we demand to "help" (makes me wonder, how many times we've processed the same WUs, over and over, just so BOINC credit is generated and awarded...).

We don't like it when scientists issue very long WUs and we lose the 24h bonus! On the other hand, we're sympathetic to the complainers, but we rush to grab as many WUs as we can, so our RAC isn't affected by the drought...

Donating the computer time, pay the electrical bill associated with it, and buying computer parts I otherwise would not need, is the philanthropic part of the equation participating in BOINC projects.

But reading and participating in the forums as well as the RACs are the fun it involves participating, and yes the later motivated me to buy some new stuff to get over a million RACs a day.

I still do not see any benefits in JIT, other that finally we are all at each other throat, discussing our personal motivation for participating!

Let’s get the job done, crunching through all the WUs as fast as possible!

... finally we are all at each other throat, discussing our personal motivation for participating!

Let’s get the job done, crunching through all the WUs as fast as possible!

Suddenly I've realized that we're doing a Mark Twain adaptation here in this thread. :)

Oh, dear, this is all doubledutch to me :(. I process about four GPUGrid WUs every weekend if available. If there's no work, I process other WUs.

You raise a good point; the only reason we are having this discussion is that there has been a shortage of work. That may be easing, but the point still remains: how to prioritize the distribution of what they do have (if at all). Only GPUGrid can really decide that, since they know best what they are trying to accomplish. I hope they consider the ideas here though, and set the proper rewards. I think the crunching will fall into line after that.

You raise a good point; the only reason we are having this discussion is that there has been a shortage of work. That may be easing, but the point still remains: how to prioritize the distribution of what they do have (if at all). Only GPUGrid can really decide that, since they know best what they are trying to accomplish. I hope they consider the ideas here though, and set the proper rewards. I think the crunching will fall into line after that.

I don't personally see any point to enforce a maximum amount of 1 WU per user. I think this is a decision that must come from the user, for the various reasons that you have expressed in this thread.

The best idea expressed in this thread to encourage crunchers to lower their work buffer by creating shorter than 24h return bonus level(s).
I think a 3rd bonus level of 75% for less than 12h would be sufficient, as a long workunit takes ~10.5h to process on a GTX970 (Win7).
I don't think there should be a shorter period for higher bonus, as it would not be fair to create a level which could be achieved only with the fastest cards. But it could be debated, as there's a lot of GTX980Tis attached to the project. Even some of my host could achieve higher PPD if there was a shorter bonus level with higher percentages, but the throughput increase of the whole project matters, not the single cruncher's desire.

It looks like a judicious compromise that will encourage the desired behavior (insofar as we know it) without burdening anyone.

After reading through this thread, I think we should leave things the way they are, with one exception not mentioned here. Which is not allow hosts with old and slow cards to be able to download tasks. I would include the 200 series and earlier, the lower end 400 and 500 series, early Quadro, early Tesla, and the M series. These cards take days to complete tasks (sometimes finishing after the deadline), and often finish with errors. This really slows the project.

200 series has been excluded for a while now.

After reading through this thread, I think we should leave things the way they are, with one exception not mentioned here. Which is not allow hosts with old and slow cards to be able to download tasks. I would include the 200 series and earlier, the lower end 400 and 500 series, early Quadro, early Tesla, and the M series. These cards take days to complete tasks (sometimes finishing after the deadline), and often finish with errors. This really slows the project.

200 series has been excluded for a while now.

200 series has been excluded for a while now.

Then this page needs to be updated:


https://www.gpugrid.net/forum_thread.php?id=2507

The server already, by default, currently says "run 1-at-a-time" (gpu_usage = 1.0), but imagine an additional user web setting that says "Run up to this many tasks per GPU", where the user can change the default from 1 to another value like 2 (gpu_usage = 0.5). Basically, then, the server can choose gpu_usage 0.5 when there's plenty of work available, but choose gpu_usage 1.0 when in "1-per-GPU" mode. And the user wouldn't need an app_config.xml file.

The whole thing would be dynamically controlled, server side. Complicated, but possible, I think. And it would surely increase throughput, during droughts.

I'd love to hear the admins respond to this proposal. I think it's a great compromise, that could fix multiple problems.

The server already, by default, currently says "run 1-at-a-time" (gpu_usage = 1.0), but imagine an additional user web setting that says "Run up to this many tasks per GPU", where the user can change the default from 1 to another value like 2 (gpu_usage = 0.5). Basically, then, the server can choose gpu_usage 0.5 when there's plenty of work available, but choose gpu_usage 1.0 when in "1-per-GPU" mode. And the user wouldn't need an app_config.xml file.

The whole thing would be dynamically controlled, server side. Complicated, but possible, I think. And it would surely increase throughput, during droughts.

I'd love to hear the admins respond to this proposal. I think it's a great compromise, that could fix multiple problems.

I still would REALLY appreciate this option. That way, I can set the "Run up to this many tasks per GPU" setting to 2, and the server would generally send "gpu_usage 0.5", but in times where the server decides it'd be better for 1-at-a-time, it would ignore my setting and send "gpu_usage 1.0".

From what I gather, this is possible. And, if it the admins think it would benefit their throughput enough to be useful, I would appreciate its implementation, as then I could see my GPUs get "dynamically adjusted" as deemed appropriate by GPUGrid, instead of "micro-managed" by me with an app_config.xml file.

Regards,
Jacob

The server already, by default, currently says "run 1-at-a-time" (gpu_usage = 1.0), but imagine an additional user web setting that says "Run up to this many tasks per GPU", where the user can change the default from 1 to another value like 2 (gpu_usage = 0.5). Basically, then, the server can choose gpu_usage 0.5 when there's plenty of work available, but choose gpu_usage 1.0 when in "1-per-GPU" mode. And the user wouldn't need an app_config.xml file.

The whole thing would be dynamically controlled, server side. Complicated, but possible, I think. And it would surely increase throughput, during droughts.

I'd love to hear the admins respond to this proposal. I think it's a great compromise, that could fix multiple problems.

I still would REALLY appreciate this option. That way, I can set the "Run up to this many tasks per GPU" setting to 2, and the server would generally send "gpu_usage 0.5", but in times where the server decides it'd be better for 1-at-a-time, it would ignore my setting and send "gpu_usage 1.0".

From what I gather, this is possible. And, if it the admins think it would benefit their throughput enough to be useful, I would appreciate its implementation, as then I could see my GPUs get "dynamically adjusted" as deemed appropriate by GPUGrid, instead of "micro-managed" by me with an app_config.xml file.

Regards,
Jacob

The problem I see with this is that it would apply equally to far unequally capable cards. For a recent, mid/high end GPU with 4GB or more it may be OK to process 2 tasks at a time, but what about an older GPU with say 2GB? At the best it would make processing crawl, at the worst it would cause crashes.

In the end, such an approach would also need to consider the type of GPU and amount of memory. I don't know how much complexity this would add to the scheduling logic and how more difficult it would make its maintenance.

Yes, I understand better now. You mean, the user setting a value for more than one task per GPU (a setting that would apply in general) and the server overriding this only for forcing 1-to-1 whenever the need arises.
____________

Yep, you got it! GPUGrid should only implement it, if they think the project throughput benefits would outweigh the dev costs. I can live with micro-managing the app_config.xml file, either way. I just think it sounds like a neat/appropriate feature for this project.

After reading these posts, I decided to set my queue time to 0.25 days. I have mismatched video cards, a 970 and a 660ti, so the queue is based on the slower card. I found that work returned by the 660ti was given less credit since the wu queue and compute time exceeded 24 hours. So this gave me the incentive to cut back on the number of waiting wu.

So this thread was beneficial to me. I have smaller wu queue (1 to be exact) and end up with more credits. A win win for all.

Thanks