Alex, you're beating your head against a wall. Trying to get creditscrewed fixed has been an on-going issue since its introduction. Time seems to be spent beautifying the front end, yet they won't even introduce a simple "cosmetic" change that would greatly enhance the front end - User Name <100.

Alex, you're beating your head against a wall.

He, he thanx Sirius :) I'm fully aware of that which is why I (indirectly) confessed to being a masochist :D

In fact I was planning on calling the other thread "Flogging a dead horse". I still have the jpeg bookmarked that I was planning to use in the intro post :D



But most of the people here are Beatles & Stones generation as opposed to Ramones & Pistols generation so I decided against it :)

Come on guys.
Could we just take a chill pill here?
At the moment, it's really a rhetorical discussion.
No need to be snapping at each other over it.

Meow.

---

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

What I was trying to say (to Rob only) is:

...DO NOT attempt to compare credit awarded between projects.

Then you should have said so in one of your earlier posts, and not wait until Richard & I had both said so repeatedly.

---

Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

Considering I was using a mechanism that was in place long before any other projects were born I kinda didn't think I had to.

It is always worth stating one's assumptions - that way people know where one is starting from, and, if required, can pose their own assumptions.

---

Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

@TBar WTF dude, why are you being so pissy towards me? Did you think I was accusing you of cheating?

Hey, I just used a phrase similar to what you used. I see you didn't like it either. I was going to use a smiley, but decided not to since you didn't. I kinda thought it was funny. Right now I'm seeing even the GPU pairs scoring less than 60 credits and the CPUs scoring in the 40s. It seems to be getting lower and lower. I was scoring between 75 & 100 credits for 3 minutes of Arecibo non-VLARs, now I'm getting 50 to 60 for the same 3 minutes of GPU time. Naturally my RAC has started to dive as usual when running GBT only. In a system based on Angle Range, the GBT tasks would be scoring Higher than the Arecibo non-VLARs since the Angle Ranges are lower. In CN you are doomed to receive fewer and fewer credits no matter how much longer the tasks take.

[In reply to Richard's graph]

I have no idea if this is useful or even relevant but somewhere buried in CN it says an app needs "a few dozen" tasks on each host from the time of introduction to level out.

On an unrelated note I noticed it takes the server a LOT more than "a few dozen" to stop sending slower app tasks by the bucketload. Seemed to [start to] cool off around 75?

And this behaviour is perfectly in line with the analysis of the code I did a couple of years back - the damping and normalisation sections of the code are too aggressive, and effectively assume that everything that changes is an attempt to cheat so hammer the credit down.
It is worth noting that much the same is happening with the credit from APs, it used to be consistently in the high hundreds, but recently it looks to have been in the low hundreds
The credit generation model employed by SETI is probably beyond redemption - it is too reliant on the user never changing anything and the tasks all being in the same family (e.g. Arecibo, GBT.....). Personally I would like to see that model consigned to the bin, and a proper task based one employed in its stead.

---

Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

I see you didn't like it either.

No, what I didn't "like" was that you replied to me but you were not talking "to" me.
I haven't seen that style of reply before and don't know what to make of it.
Now that you mention it though that "outfoxing" line really DID need a smiley face :)

Unfortunately as to the more interesting parts of your post I can't comment because of lack of GB knowledge.
(Did you see my reply to Grant in the other thread?)

What do you mean by "slower tasks"?

On an unrelated note I noticed it takes the server a LOT more than "a few dozen" to stop sending slower app tasks by the bucketload. Seemed to [start to] cool off around 75?

There are a couple reasons a task may be slower than normal, data source & task type (VHAR, VLAR.....).
If there are only tasks of one type available that's all we get - there is no guarantee that we will ever see a "sensible mix", but Murphy dictates we will more often than not see a "poor mix" than a "good mix".
Or do you mean the application type (CUDA32, CUDA50 SoG etc.) - again this is s bit of a lottery until the calibration has finished, and if one is unfortunate in wingmen you may have to wait several days or weeks to get enough validated tasks using the range of apps to get to the "right" application.

---

Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

Bad writing.

to stop sending slower app tasks by the bucketload

should be
"to stop sending tasks to slower apps by the bucketload"

...you may have to wait several days or weeks to get enough validated tasks using the range of apps to get to the "right" application.

Yeah but the number that gets thrown around is "10 valid tasks". Which is why I thought 70something might be noteworthy... I don't know really, just thought it strange.

It would appear that you are asking about "slower applications", and not tasks that take longer to execute.

Ten validated, normal range (whatever that may be) for each application. Off the top of my head for nVida GPUs there are:
CUDA22 (you should never see this application if yo have a fairly recent GPU)
CUDA32 (you may see this application)
CUDA50 (you will probably see a lot of these)
SoG (you will probably see a lot of these)
(I think I've missed one, but that's at least 40 tasks before the decision can be made - although the slowest may be thrown out long before the fastest is selected)
(EDIT - yes I did miss one, CUDA42. This can be a bit of wild horse, sometimes it can be faster than CUDA50, but other times slower - depends on the exact hardware and software of the computer concerned)

If the result of the first ten for each of a pairing is too close to call you will continue to see them both until such time as one comes out in the lead. This is particularly true of SoG vs CUDA50, which to a certain extent depend on the mix of sources in operation at the time

One thing to note is that "Arecibo VLARs" are not necessarily included in the count of ten, and there have been fair number of them recently, so one can expect a lot more tasks to be run than one would expect.

---

Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

Yes please Tut. Can you supply the birch twigs and the blonds please

---

Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

female

---

Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

One thing to note is that "Arecibo VLARs" are not necessarily included in the count of ten, and there have been fair number of them recently, so one can expect a lot more tasks to be run than one would expect.

I think they will be counted, because they are tasks, pure and simple. They will run slowly, but do nothing to trigger the 'runtime outlier' exclusion.

For a new machine, that can lead (we've seen it) to a big batch of VLARs being issued, and by happenstance at a time when the scheduler is willing to test out CUDA50. Then, when your 'additional work' overfetch has decayed, it's time for another big fetch. How about some CUDA32 for afters, just as the queue has some normal ARs at the top. CN/RE will - quite correctly, on the evidence of the data - decide that CUDA32 is fastest on your machine - and there you'll stick. There's no reset button for CN.

Edit, come to think of it, tagging all Arecibo VLARs as 'runtime outlier' would be a safe and logically simple way of avoiding new instances of that kind of lock-in.

Oh, Mark.

It is only your way of dealing with the issue of CreditScrew here, because it affects all users participating in this project.

Except for what others could be saying, of course.

The key line in this discussion is

The Arecibo VLARs run a little over twice as long so should score about twice as much.

The bit in yellow is true, but only for NVidia GPUs. On CPUs (and, I believe, AMD GPUs) they run about the same time.

So, the 'should' is problematic, and that's what we're discussing here.

In general terms, a VLAR is pretty much the same amount of work as any standard task. So, if we're rewarding output, they should get the same amount of credit,

But NVidia GPUs find them tough going - they work harder, but more inefficiently. So if we're rewarding effort, the NVs would get a higher credit.

Effort or output? You can't reward both with a single number. The scientists have chosen to reward output: those are the rules of the game, however well or badly implemented. When GPU is matched against GPU, you get a bonus for effort, but that's just luck.

. . Yep, that is much as I have observed, on CPUs the Arecibo VLAR tasks take slightly less time than Arecibo normal AR tasks (about 5 to 10%) but on Nvidia GPUs (the only ones I have) they take about 110% longer. So as you say, Nvidia GPUs work longer and harder to get results on these tasks, which is inefficient use of the resource, especially considering the fact that Nvidia hardware far exceeds AMD/ATI hardware attached to the project, from what I have read. But when you get a flood of Arecibo VLAR work as happened recently it needs to be disseminated as quickly as possible which means sending it to Nvidias as well. If they perhaps stopped sending Arecibo normal tasks to CPUs then they could take somewhat more of the load when VLAR floods occur but it looks like Nvidia's need to take the hit for some time to come.

. . But I am concerned that GBT tasks, which now take roughly the same time to run as Normal Arecibo tasks, are dragging all the numbers down despite running with the same APR (or very near to it) as Arecibo normals. Why does credit screw do that?

Stephen

? ?

Ah Wedge009, you chose the one person who is famed for his aborting of thousands of tasks - when ever he sees something he doesn't like/want he just aborts the lot - last time I saw him do this it was APs, on another occasion it was BLP. He is a long way removed from the average user who will NEVER take any note of what is running on their computers.

Just checked out the link, WTH? How can there not be built into the system something that would penalize a person for doing this behavior? I imagine that it isn't common or prevalent in our project, but regardless, I feel that there shouldn't be a reward for someone behaving this way. Maybe kind of knocking them back like the system does when a client returns a large number of errored tasks, you only get them in dribs and drabs until you return a sufficient # of good results, and then the amount you are fed gradually increases. And then get knocked back again if you have the issue again. Would that be (somewhat) simple to implement, as we have a version of it now, just tweak the code to look for aborted vs. error tasks?

. . It does, or should, work the same for aborted tasks, When large numbers of tasks are aborted requests for work get "you have reached a quota" message until there is enough valid work returned to slowly raise the allotment.

Stephen

. . .