BTW, very simple and quite elegant IMO way to deal with limits is to allow users to set limit by themselves with low default.

What it will give: those who needs (or think that they needs, no matter) more tasks will get more tasks.
"unattendent hosts" will be limited still just because they don't care!
Active fraction small enough so this solution will greatly reduce tension on forums while will not bloat database too much.

Right? ;)

---

SETI apps news
We're not gonna fight them. We're gonna transcend them.

I want a 100/GPU limit.
Do I have to ask again?

@raistmenr...........Don't try to evade your previous comments.
Apologize or retract, please. You are trying to evade the question, and I think, to save face, you should.

@claggy..............
Dunno what you mean, I have been up to the total 1800 limit on my 9 rigs, regardless of the mix.

---

"Freedom is just Chaos, with better lighting." Alan Dean Foster

Rasitmer............
My post was not based upon the impact or that not of, credits issued.
Meow.

Mark, perhaps you wanted to address your post to me though you still can't write my nick right after all these years. Well, ok with that, no matters. But you are definitely not the William, and I definitely did not comment any of your posts before so I don't quite understand why you answer me regarding your posts.
Also, personal insults not welcomed either. If you have one of those your "funny states" again, then time stop perhaps.

---

SETI apps news
We're not gonna fight them. We're gonna transcend them.

Rasitmer............
My post was not based upon the impact or that not of, credits issued.
Meow.

Mark, perhaps you wanted to address your post to me though you still can't write my nick right after all these years. Well, ok with that, no matters. But you are definitely not the William, and I definitely did not comment any of your posts before so I don't quite understand why you answer me regarding your posts.
Also, personal insults not welcomed either. If you have one of those your "funny states" again, then time stop perhaps.

I am not in one of those 'funny states', and did not make any 'personal insults'.
If I did, you would certainly hear them.

Just get back to the coding board, my friend, and do what I cannot.
I do not know your background, and certainly cannot do what you do.
That does not stop me from commenting on what I perceive to be right or wrong.

Carry on, buddy. You certainly have done more right than wrong.

And I shall continue to comment when I feel appropriate.

OK?

Hmm..........do you have cats, Raistmer?
As my sig goes, that might settle the matter once and for all........LOl.

---

"Freedom is just Chaos, with better lighting." Alan Dean Foster

...
BUT as you can see from the tech post, the database is very bloated ...

I think the "very bloated" database refers to the science database, which wouldn't be affected by this change.

Changing the limits would have a direct impact only on the BOINC database, which is currently relatively small - they might like to keep it that way.

If we can't get them to up the 100 CPU and 100 GPU tasks limit, can we at least get them to put in 200 task Total limit per host,
and take it from the Server side tasks in progress number, and not what the client reports (as not all clients report that),
that'll stop them building excessive caches. (more than 200 tasks anyway)

Claggy

That and a 'total channels to do' <200 will help most people here. Right now the total channels to do is 416. To last out 416 to 0, I'd need around 450 APs. If the total channels to do was never more than 200 after loading, there might be a chance to not run out of AP work.

My biggest problem is 100 CPU WU can take 10 days to clear wile 100 small GPU WU only 10 hours. I can crunch CPU WU wile crunching MB GPU WU so I like to have them but if I want to clear my cache and not abort 100 CPU WU it is a problem.

---

My biggest problem is 100 CPU WU can take 10 days to clear wile 100 small GPU WU only 10 hours. I can crunch CPU WU wile crunching MB GPU WU so I like to have them but if I want to clear my cache and not abort 100 CPU WU it is a problem.

My biggest problem is 700.00 power bills,.
You got an answer for that?

I am sorry for you.
I got 9 rigs, 24/7, that do what you even ATTEMPT to achieve, SIR.\0

I do in one day what some crunchers hope to achieve in their lifetime.
Pretty amazing, eh?\\

---

"Freedom is just Chaos, with better lighting." Alan Dean Foster

My biggest problem is 100 CPU WU can take 10 days to clear wile 100 small GPU WU only 10 hours. I can crunch CPU WU wile crunching MB GPU WU so I like to have them but if I want to clear my cache and not abort 100 CPU WU it is a problem.

My biggest problem is 700.00 power bills,.
You got an answer for that?

I am sorry for you.
I got 9 rigs, 24/7, that do what you even ATTEMPT to achieve, SIR.\0

I do in one day what some crunchers hope to achieve in their lifetime.
Pretty amazing, eh?\\

It's called dedication, or insanity. Maybe both. :P

---

SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[

@william

That´s we could call "agressive negotiations"... :)

Back to topic:

I just want 3 things:

- a cache who holds for at least 1/2 a day (100WU GPU limit is not enought).
- cruch MB or AP and receive on the same host the same credit for the same crunching time.
- don´t need to rescheduling my work to achieve that!

I don´t thing is too much to ask...

BTW... i could add... i wish my power bill where low as 700 US$/month...

Before anyone say nothing, yes i´m insane... but any BFB cruncher sure is...

Anyway I still love´s the kitties... :)

---

But a 200 task limit is what I see right now. 100 for CPU and 100 for GPU.

200 total on one box.

---

Boinc....Boinc....Boinc....Boinc....

For those who want to complain about how big the database is, one way would be to do something about rigs like these 1's that have annoyed me over the last 3 days.

6918964
6134523
7126088
5851927
6775327
5173830
5744165
5816451
7143915
5355835
6204067
5636309
6309357
7011923
6687080
7174864
5255577
5256566
5337199
5940343
5967897
6107404
6253478
6818618
6889146
5813849
6062303
6772486
5814038
5422967
7062362
5940769
6962510
5567264
6765911
4750332
6709864
6143011
6995169
7182427
6901240
5857368

This is not all of them, but they are the worst of the lot.

I'm sure that my "State: All" numbers will then drop a lot.

On the other side, those who by rescheduling or by "magic" just so that they can get AP work above the current set limits set will never have my respect just the same as those who abort MB work to get more AP's whenever they are being split.

Cheers.

My biggest problem is 700.00 power bills,.
You got an answer for that?

Yes, Kuwait one cent for a K/h.

---

No way, too hot to crunch... and no B-girls, bad for me at least. I´m out.

---

Maybe a quick to implement change, the powers that be at Seti could implement the 200 WU limit as a floating quota as one poster mentioned. If you don't crunch any CPU, then 200 is available for GPUs. It wouldn't totally fix the problem, but it would be a band-aid for a little while.

A more permanent fix would be a quota based on number of GPUs. I've got 8 in my big cruncher and 100 work units (especially MBs) won't take to me too far.

Or maybe a more all-encompassing solution that would vary the number of work-in-progress work-units per host. It could look at such things as host reliability (not trashing work-units), host uptime, average work-unit turnaround time, crunch power of the cpus/gpus and number of cancelled tasks. I know this would be a lot to implement, but could be a more long-term solution.

The way things stand now, anyone including myself with lots of gpus stuffed into a single host is screwed - yes, my fault for building such a beast. I'm thinking of building another one, but the logistics of cost to build, cost of electricity and cooling are preventing me from executing the plan.

---

My point is, The quantity makes no diference, the balance is what is important, if the balance from AP to MB where recovered (as was in the Seti 6 era) a lot of troubles like this will be avoid.

BTW, it's strange indeed that such balance still unreachable. If CreditNew self-adapting (if not how re-scheduling can harm it at all?) then quite a lot time passed to re-balance credits between AP and MB.

The fact is - it did not happen. Maybe becasue some of base assumptions in very foundation of CreditNew are not good. Measuring CPU vs GPU times for MB and AP shows that current CUDA MB is relatively good for NV than current openCL AP.
So how CreditNew can pay less for more suitable app at all? How it can be that hoarding AP tasks on NV will increse RAC while it should decrease it?...

Within the design limits of CreditNew, balance has been achieved. That is, a host doing stock MB CPU tasks and stock AP CPU tasks gets about the same credit per hour for each.

The comparison is a little difficult to judge since AR has so much influence for MB tasks and the stock AP CPU stderr doesn't reveal how much blanking was involved. But if you go back several thousand in the Top computers list and choose hosts with no GPU, you can find systems with enough MB and AP CPU stock tasks listed to judge for yourself. Hosts with GPUs would also be suitable, you just have to ignore the GPU results.

I realize that this thread is mostly concerned about GPU credit rates. At a minmum, some evolution of CreditNew will be needed before GPU credit rates become sensible.

Just for the record, I agree that any action taken by a user to circumvent the limits is unethical.

                                                                  Joe

...That is, a host doing stock MB CPU tasks and stock AP CPU tasks gets about the same credit per hour for each...

Actually, since the global (down)scale chooses a CPU app in both cases unilaterally (by design flawed omission of SIMD), and the preceeding individual host scales are determined by an underclaim (based on Boinc Whetstone), it works out that AP pays approximately 2x, due to there being no AVX in the stock AP CPU app yet. [And incidentally, but related, that by reasonable or not task estimates, AP should be made considerably more efficient to be on par with MB. i.e. you get a special bonus with AP for the stock CPU app being dated, to offset some of the underclaim.].

Both cases end up a fraction of the cobblestone scale, and diminishing. I've yet to find deflation documented as a design goal of CreditNew, but it's very apparent. Moore's law and (stock cpu app) optimisation driven with the current four identified design flaws in play.

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

Within the design limits of CreditNew, balance has been achieved. Joe[/pre]

Well, just another name ("design limits") for wrong asumption that lies on the ground of this credit system. Well, lets call them design limits, but those limits are preventing CreditNew to be useful. Quite valuable limits no one should break, not? :P

And for the record, I consider energy waste produced by stock AP-based hosts and any means that aimed to keep stock CPU AP tasks supply (100 tasks per ATi GPU limit including) as unethical. If category of moral applied to such topics at all of course, but quite many posters in this thread insist that it's applicable, so...

---

SETI apps news
We're not gonna fight them. We're gonna transcend them.

i.e. you get a special bonus with AP for the stock CPU app being dated,

Exactly. And if/when stock app will be updated to more efficient build at last? What then? Will AP credit drop like it was for MB7? If yes, then we will get another wave of desperation from credit-oriented (actually not only from them, some number to measure host performance needed anyway so when RAC changes for some external reasons not related to host performance it's bad for everyone) users. And then we again recive direct contradiction between credit system and project goals. Project goal is to increase its performance so updating stock app to faster one is good... but this will perhaps annoy quite a lot peoples because of CreditNew "design limits". So one could think twice before doing such update... So, very existence of such CreditNew credit system may hinder project's development.

---

SETI apps news
We're not gonna fight them. We're gonna transcend them.

My biggest problem is 700.00 power bills,.
You got an answer for that?

Yes, Kuwait one cent for a K/h.

You are quite cute.
I shall move my crunchers to Kuwait directly.
I suggest you move there too.

Meow.l

---

"Freedom is just Chaos, with better lighting." Alan Dean Foster

i.e. you get a special bonus with AP for the stock CPU app being dated,

Exactly. And if/when stock app will be updated to more efficient build at last? What then? Will AP credit drop like it was for MB7? If yes, then we will get another wave of desperation from credit-oriented (actually not only from them, some number to measure host performance needed anyway so when RAC changes for some external reasons not related to host performance it's bad for everyone) users. And then we again recive direct contradiction between credit system and project goals. Project goal is to increase its performance so updating stock app to faster one is good... but this will perhaps annoy quite a lot peoples because of CreditNew "design limits". So one could think twice before doing such update... So, very existence of such CreditNew credit system may hinder project's development.

If we brought stock CPU AP up to MB optimisation standards (AVX, polymorphic function dispatch etc), then AP credit will drop like a stone to at or below MB on a per hour basis. The mechasism is penalising optimisation of the stock applications, just the same (I'm told) as it's penalising multithreading on MilkyWay out, effectively dividing credit by the number of cores, when it should be multiplying. [Blocking technology progress!]

That's just a function of the design having assumed faster uses the same resources, so leaving out instruction level parallelism, vectorisation and coarser parallelisation completely out of the design.

What *could* have happened, at least in our case here at seti@home, is we know task estimates for FPU operation are 'not too bad' (relatively speaking), therefore any apparently more efficient processing that is valid is using some form of parallelism (what kind we don't care), and so can be used to gauge the average parallelism, scaling (upward) appropriately to compensate for shorter time, as opposed to dividing credit downward even further causing spiral deflation.

The end result of proper scaling would converge on the cobblestone scale.

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.