Cheating requires active action in its on term.
Its almost impossible to always have AP units in cache.
But i dont care i crunch what i`m getting.

---

With each crime and every kindness we birth our future.

And if not to mush to ask, rise the 100 WU limit a little... it´s hard to see your expensive multi GPU host running empty... :)

+1 here :)

---

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

Its almost impossible to always have AP units in cache.

From personal experience I would say "impossible" w/o "almost" :)

But i dont care i crunch what i`m getting.

This decreases your host effeciency for the project while saves you more personal time of course ;)

---

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

Just to clarify something, all the reschedulers hosts pointed uses only NV.

If AP is more eficient to crunch in ATI and MB on NV and VLARs are on CPU´s then why not do that on the server´s side?

Maybe that´s will make the entire project more eficient and is the answer.

ops... do MB only on my Nvidias... it´s fine but my RAC will dive dive dive... i hate creditscrew!

---

Just to clarify something, all the reschedulers hosts pointed uses only NV.

If AP is more eficient to crunch in ATI and MB on NV and VLARs are on CPU´s then why not do that on the server´s side?

Because of lack of manpower perhaps.
Honestly I would prefer if Eric and Co would spend more time on SETI large tasks preparation and on app for GBT dsata than on this server tweaking and even on Android MB app (I know, it's interesting and fun but ... ).
We can't do those tasks at all. But we can tweak own hosts to improve things client-side.

ops... do MB only on my Nvidias... it´s fine but my RAC will dive dive dive... i hate creditscrew!

Exactly, so CreditNew is evil, I said that and will repeat.

---

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

This decreases your host effeciency for the project while saves you more personal time of course ;)

And saves your (and the planet's) consumption of electricity, unless the GPU is shared with other projects (including SETI MB).

Its almost impossible to always have AP units in cache.

From personal experience I would say "impossible" w/o "almost" :)

But i dont care i crunch what i`m getting.

This decreases your host effeciency for the project while saves you more personal time of course ;)

Depends on your point of view.
I`m very busy and have a private life as well.

Evenso i`m far away to call my host inefficient.
My PC is always doing work for the project.

---

With each crime and every kindness we birth our future.

This decreases your host effeciency for the project while saves you more personal time of course ;)

And saves your (and the planet's) consumption of electricity, unless the GPU is shared with other projects (including SETI MB).

Richard, see my prev post about other projects please.
Regarding SETI MB - it relatively less efficient (I wrote both apps so can say this w/o fear to harm author ;) ) on ATi GPUs than AP.

Look this investigation on this topic:
http://lunatics.kwsn.net/2-windows/what-is-best-hardware-for-what-seti-application.0.html

---

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

This decreases your host effeciency for the project while saves you more personal time of course ;)

And saves your (and the planet's) consumption of electricity, unless the GPU is shared with other projects (including SETI MB).

My computer is never idle.
Dont worry about that.

---

With each crime and every kindness we birth our future.

Evenso i`m far away to call my host inefficient.

Sure, but being optimizer I always aim to the best performance possible ;)
Consider this as next stage after tweaking default app params.

---

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

Evenso i`m far away to call my host inefficient.

Sure, but being optimizer I always aim to the best performance possible ;)
Consider this as next stage after tweaking default app params.

I always did.
Thats why i help to optimize your apps.
I just have other goals.

---

With each crime and every kindness we birth our future.

Back to topic:

At the end...

Why we need to rescheduling ... to keep the cache filled with AP.
Why? ... mainly because creditscrew paids 2x more for the AP work than MB.
How to solve? ... fix creditscrew to achieve a balance on the credit paid.
Can it be done? ... yes but ... we all know the answer.

So we could only ask to each user to remember he lives on a comunity and balance his needs with the others, something like: if you rescheduling please do that with moderation and use only if you realy knows what you are doing and realy need that.

One last thing: Allways remember, to get space for a new tape to be splitted for AP first we need to clear the MB work allready splitted.

---

Back to topic:

At the end...

Why we need to rescheduling ... to keep the cache filled with AP.
Why? ... maindly because creditscrew paids 2x more for the AP work than MB.
How to solve? ... fix creditscrew to achieve a balance on the credit paid.
Can it be done? ... yes but ... we all know the answer.

So we could only ask to each user to remember he lives on a comunity and balance his needs with the others, something like: if you rescheduling please do that with moderation and use only if you realy knows what you are doing and realy need that.

Talking about fixing credit new is like talking to a bull giving milk.

---

With each crime and every kindness we birth our future.

Talking about fixing credit new is like talking to a bull giving milk.

Unfortunately you are right. But hope is the last thing we could loose...

That´s why i write:

So we could only ask to each user to remember he lives on a comunity and balance his needs with the others, something like: if you rescheduling please do that with moderation and use only if you realy knows what you are doing and realy need that.

It´s hard to belive some host with 3GTX 660 Ti who realy needs a 776 AP WU cache...

Going to work, hope you all have a good day/night.

---

I don't agree that cheating the limits is 'being all that you can be'.
Bulls**t.
You play by the same rules everybody else respects or they don't respect you.
Period.

I keep requesting that the 100/per GPU host be raised, but you don't see me cheating to get more, now do you.

You want to see me be all that I can be? I can do that.

Be very careful what you wish for.

I could easily bogart THOUSANDS of AP tasks here on my 9 rigs.
But, I don't crunch low class. I take what the servers shall send me, and crunch them all as assigned. Maybe I should polish up my rescheduling skills just to show you what can be done?

NOT.

My opinion, take it or leave it.

---

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

I was going to post something longer including an intricated take on creditnew, why rescheduling from CPU to GPU often gives lower credit and why credit looks random [including analogy], but I'll leave it for now. I don't have the time or the patience.

I'll just say that I find it utterly unethical to say 'it's broken anyway. so it doesn't matter if I screw up the numbers some more'.

Rescheduling screws up credit for everybody. Period. Now you and I may care little about credit, but each time credit drops some more we lose crunchers who worship the golden credit calf.
Yes, you could say 'small loss'.

Personally I believe that if people think credit important I have no right to look down on them for that.
I also believe that everybody should get the 'right' credit whether or not he/she puts store by that number.

Let me put this differently and harsh.
So you are that noble person that says 'I don't mind how much I get paid for my work, I'd work for nothing at all' does that give you the right to make your employer pay less to everybody else too, inclusing those who desperately need the money? I don't think so.

Yes, nobody has gotten a toaster yet. I'm just illustrating the 'you don't have the right to impose your set of values on other people' credo.
You may disagree with me on that. Did somebody use the word respect?

---

A person who won't read has no advantage over one who can't read. (Mark Twain)

Why are 500 channels being loaded into the splitters? A while back, the most that were loaded at one time was 200. With the current cache limits, 200 channels was a good number. You could Almost have your AP cache last until more channels were loaded. If 500 channels are loaded, there is NO WAY your cache will last through them.

If you load 500 channels, most dual card hosts will need over 500 APs to last through the period.
If you load only 200 channels, some dual card hosts can actually last until the next loading. Other hosts will run out hours before.

Until the cache limits are raised, DO NOT LOAD OVER 200 Channels at one time.
I speak from experience.

You did not reply or quote a post, so I must ask, William.
Are you responding to me, specifically?

I have made it clear that I applaud your and others' efforts in fixing what is broken in creditscrewed.

I await it eagerly.

I simply said that in the context of things as they are now, it treats me as goodly or badly as any other, and so as far as Seti work is concerned, I am not overly anxious about it.

Meow, friend.

---

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

Why are 500 channels being loaded into the splitters? A while back, the most that were loaded at one time was 200. With the current cache limits, 200 channels was a good number. You could Almost have your AP cache last until more channels were loaded. If 500 channels are loaded, there is NO WAY your cache will last through them.

If you load 500 channels, most dual card hosts will need over 500 APs to last through the period.
If you load only 200 channels, some dual card hosts can actually last until the next loading. Other hosts will run out hours before.

Until the cache limits are raised, DO NOT LOAD OVER 200 Channels at one time.
I speak from experience.

It's all relevant. You can have a long run of AP work, or you can have a few more shorter runs. I suspect the ratio is always about the same.
X percent of MB splitting on a dataset yields X percent of AP work.
My request is to raise the limits from 100/host to 100 per active GPU.
That is more realistic in terms of hold over time.

And yes, LOL. I remember when AP work was shunned because 'it takes too long to process'.

---

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

You did not reply or quote a post, so I must ask, William.
Are you responding to me, specifically?

I have made it clear that I applaud your and others' efforts in fixing what is broken in creditscrewed.

I await it eagerly.

I simply said that in the context of things as they are now, it treats me as goodly or badly as any other, and so as far as Seti work is concerned, I am not overly anxious about it.

Meow, friend.

No, I wasn't responding to you specifically, more to the feel of the thread and the opinion(s) voiced by a few people. Had I been wanting to reply to your post specifically I'd have done so.

---

A person who won't read has no advantage over one who can't read. (Mark Twain)