During the most recent flurry of AP WUs this past week, I processed perhaps 80+ of them, and have generally seen the expected somewhat broad range of credit granted for the validated ones with normal results (from about 300 to 1000+), and of course the miniscule credit for the 30/30 overflows (usually less than 1 credit). HOWEVER, I just noticed one WU which finished normally, had fairly low blanking, appeared to give a reasonable result, and only was granted 24.62 credits! I don't believe I've ever seen such a low credit for a normally completed AP WU.

Here's the link to the WU (at least until sometime tomorrow): http://setiathome.berkeley.edu/workunit.php?wuid=1317661176

The STDERR shows, for results:

    single pulses: 3
repetitive pulses: 0
  percent blanked: 4.79

The credit is so far out of the normal range for an AP that it startled me. Anybody ever run across this before, or have any thoughts?

I've seen that happen once or twice before, and it has happened to me at least once. Not really sure what the cause was, other than it's part of the possibilities that come with the random number generator. It's just like once before, and I can't find it in my spreadsheet at the moment, I got ~850 credits for one of those 100% blanked sub-1 second APs. Both me and my wingmate. Guess that makes up for some of those times where you feel like you got robbed.

---

Linux laptop:
record uptime: 1511d 20h 19m (ended due to the power brick giving-up)

Well, I just looked through my database and found an even worse one from a couple of weeks ago that apparently slipped by me, 1.99 credits for nearly 4 hours of processing on a highly blanked AP:

Name	ap_07jl08ab_B4_P1_00128_20130831_32455.wu_0
Workunit	1310827092
Created	1 Sep 2013, 1:36:31 UTC
Sent	1 Sep 2013, 8:42:00 UTC
Received	1 Sep 2013, 21:37:03 UTC
Server state	Over
Outcome	Success
Client state	Done
Exit status	0 (0x0)
Computer ID	6980751
Report deadline	26 Sep 2013, 8:42:00 UTC
Run time	13,480.56
CPU time	12,510.23
Validate state	Valid
Credit	1.99
Application version	AstroPulse v6 v6.04 (opencl_nvidia_100)

    single pulses: 2
repetitive pulses: 0
  percent blanked: 80.70

I'll say one thing, if these sorts of credit levels start popping up more frequently, it sure would cure the AP hogs who think they're so valuable!

Probably caused by the people who re-shedule tasks from CPU to GPU. The credit system uses the processor to which the task was assigned to calculate the score, so if it thinks the task was run on a very slow CPU it will award credits on that basis.

---

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

Probably caused by the people who re-shedule tasks from CPU to GPU. The credit system uses the processor to which the task was assigned to calculate the score, so if it thinks the task was run on a very slow CPU it will award credits on that basis.

Except it wasn't. Follow the link in Jeff's opening post, and both replications were allocated the stock NVidia application for their respective platforms. You'll have to find a different explanation for the variance in Valid AstroPulse v6 tasks for computer 6902160.

Anyway, I'd be surprised if somebody who self-identifies as a 'musculoskeletal oncology surgeon' has time to move tasks from CPU to GPU - I hope he hasn't, anyway.

Those wern't re-scheduled, but previous similar 1's may have been resulting in this result.

Personally I think that some better safe guards need to be implemented to stop the cheats, this may seem harsh to some, but why should they gain at the expense of most others.

In short: Fix the credit difference between AP & MB tasks then these ridiculous things wouldn't happen to start with (but then these idiots are helping with the balance, though just in the wrong way).

Cheers.

Probably caused by the people who re-shedule tasks from CPU to GPU. The credit system uses the processor to which the task was assigned to calculate the score, so if it thinks the task was run on a very slow CPU it will award credits on that basis.

Except it wasn't. Follow the link in Jeff's opening post, and both replications were allocated the stock NVidia application for their respective platforms. You'll have to find a different explanation for the variance in Valid AstroPulse v6 tasks for computer 6902160.

Anyway, I'd be surprised if somebody who self-identifies as a 'musculoskeletal oncology surgeon' has time to move tasks from CPU to GPU - I hope he hasn't, anyway.

Richard, they don't confess rescheduling, but have you seen this thread, http://setiathome.berkeley.edu/forum_thread.php?id=72502#1414523?(just as an example)

Plus check a couple of those out there that were very vocal about the credit reduction on MB's and check out their aborted MB tasks when AP's become available (sadly I have to say that 1 is a countryman of mine).

Cheers.

Richard, they don't confess rescheduling, but have you seen this thread, http://setiathome.berkeley.edu/forum_thread.php?id=72502#1414523?(just as an example)

Plus check a couple of those out there that were very vocal about the credit reduction on MB's and check out their aborted MB tasks when AP's become available (sadly I have to say that 1 is a countryman of mine).

Cheers.

Yes, I've read it, and I was bored by it. Some people do that, sure. And some people talk about it, a lot.

But I think it's wrong to ascribe a particular case as "probably" caused by what you would describe as cheating, when the evidence doesn't support it. Spineboy probably won't be reading this thread, but I think he'd be entitled to be offended if he was.

Richard, they don't confess rescheduling, but have you seen this thread, http://setiathome.berkeley.edu/forum_thread.php?id=72502#1414523?(just as an example)

Plus check a couple of those out there that were very vocal about the credit reduction on MB's and check out their aborted MB tasks when AP's become available (sadly I have to say that 1 is a countryman of mine).

Cheers.

Yes, I've read it, and I was bored by it. Some people do that, sure. And some people talk about it, a lot.

But I think it's wrong to ascribe a particular case as "probably" caused by what you would describe as cheating, when the evidence doesn't support it. Spineboy probably won't be reading this thread, but I think he'd be entitled to be offended if he was.

I must humbly apologise, but I didn't mean to infer in any way that Spineboy was a cheat (sorry Spineboy, even if you ever read this), but I meant that the result maybe a flow on effect from those who do (I also find that I get low scores when winged by an AMD/ATi card, but then that maybe another story or just another factor that needs to be factored in).

Cheers.

I'm sure he will be happy to accept that - it wasn't your confusion in the first place.

So, back on topic - which part of CreditNew came up with that credit figure for this one task?

Both computers have valid tasks credited in the normal 500-600 range. But looking at Jeff's computer this time, the other striking thing is how long that task took to run: All AstroPulse v6 tasks for computer 7070962 - 11,522 seconds. It will be interesting to see whether WU 1317821442 gets marked similarly.

According to stderr_txt for Jeff's task, the job was run on device number 1. It isn't completely unambiguous, but comparing with other jobs that were run on device 0 and device 2, I'm assuming that means the GeForce GT 640. We know that CreditNew only maintains data at the host level, not the device level: could having three different GPUs, all of different capabilities, be a contributory factor? Do users with heterogeneous GPUs notice a wider variability in credit granted, compared with single GPU hosts or hosts with multiple, but identical, GPUs?

Now there I also seem to catch the odd weird return in rigs with mis-matched cards which could very well be another influencing factor here, when they don't exceed the time limit allotted factor.

Maybe BOINC itself needs a better way to report the available cards.

[edit]IF you run all AMD/ATi cards or all nVIDIA cards it seems that BOINC thinks that all the cards are the same as the 1st inline, so maybe this is another factor that needs looking at.[/edit]

Cheers.

Now there I also seem to catch the odd weird return in rigs with mis-matched cards which could very well be another influencing factor here, when they don't exceed the time limit allotted factor.

Maybe BOINC itself needs a better way to report the available cards.

[edit]IF you run all AMD/ATi cards or all nVIDIA cards it seems that BOINC thinks that all the cards are the same as the 1st inline, so maybe this is another factor that needs looking at.[/edit]

Cheers.

BOINC was 'designed' (if that's the right word) on the assumption that it would run on either home/general work computers, or on specialised supercompute clusters.

In the home/general office case, the assumption is that BOINC runs on the spare cycles only. And there is a further assumption that if a GPGPU is fitted, only the 'best' device (or devices, in the SLI/crossfire gaming situation where matched devices will be installed) will be used.

In the cluster/supercompute case (we're probably talking Teslas here), it will be even more likely that the builders will take care to match components.

The situation of a home computer specifically built for BOINC, containing a mixture of whatever parts are available either in the recycle bucket, or in the current budget, is probably a minority niche market. We talk about it a lot here, of course, because people who are motivated to attempt that sort of system build (and to learn how to configure <use_all_gpus>) are likely to come here and talk about it, too.

Not saying that BOINC made the right balance of decisions for the various niches, necessarily: but I think it's best to try and understand the situation before we call for changes to be made, and before we propose what changes those might be.

then, some tasks are just light:
http://setiathome.berkeley.edu/workunit.php?wuid=1317729085

A 590 and mine 780 does it in about 10 minutes. Mine was running either a MB or an AP at the same time on the GPU.

Credits in this case ok.

---

To overcome Heisenbergs:
"You can't always get what you want / but if you try sometimes you just might find / you get what you need." -- Rolling Stones

then, some tasks are just light:
http://setiathome.berkeley.edu/workunit.php?wuid=1317729085

A 590 and mine 780 does it in about 10 minutes. Mine was running either a MB or an AP at the same time on the GPU.

Credits in this case ok.

Exactly.

Found 30 single pulses and 30 repeating pulses, exiting.

No problem there. But - edit - it's a shame it took four attempts, and hence four downloads, to confirm that.

So, back on topic - which part of CreditNew came up with that credit figure for this one task?

Both computers have valid tasks credited in the normal 500-600 range. But looking at Jeff's computer this time, the other striking thing is how long that task took to run: All AstroPulse v6 tasks for computer 7070962 - 11,522 seconds. It will be interesting to see whether WU 1317821442 gets marked similarly.

According to stderr_txt for Jeff's task, the job was run on device number 1. It isn't completely unambiguous, but comparing with other jobs that were run on device 0 and device 2, I'm assuming that means the GeForce GT 640. We know that CreditNew only maintains data at the host level, not the device level: could having three different GPUs, all of different capabilities, be a contributory factor? Do users with heterogeneous GPUs notice a wider variability in credit granted, compared with single GPU hosts or hosts with multiple, but identical, GPUs?

Yes, it did run on the GT 640. With my current mix of GPUs on that machine (the 640 was just added in 10 days ago), the CPU times for the GT 640 are considerably higher than the for the GTX 660, but I don't think that's related to the credit issue. First of all, my machine wasn't the canonical result for that WU. Secondly, here's another WU that ran on the 640, http://setiathome.berkeley.edu/workunit.php?wuid=1317288420, and produced a credit of 705.33. Also, that second example I gave in an earlier post, which only garnered 1.99 credits, ran on the same machine's GTX 660 and, in that case, was the canonical result. All very strange!

{edit} Actually, upon rechecking, I realized that the 1.99 credit task ran on my GTX 650. At that time I only had the 660 and 650 on that machine. {/edit}

It will be interesting to see whether WU 1317821442 gets marked similarly.

Well, my wingman reported today and the results are in! Credit granted for this WU is 739.21, which easily falls within what I consider the normal range for an AP, and considerably above the meager 24.82 granted for the earlier WU. So, the problem doesn't appear to be related to my GT 640's longer run times, unless there's some other factor at work, as well. (Also, in both WUs, my result didn't serve as the canonical result anyway.)

The canonical result, is the result kept for future use, it has no significance in allocating credit. With two tasks processed for the WU, granted credit is equal to the lower claim, if three or more tasks are validated it is the average of the middle tasks. The highest and lowest claims are thrown out.

The canonical result, is the result kept for future use, it has no significance in allocating credit. With two tasks processed for the WU, granted credit is equal to the lower claim, if three or more tasks are validated it is the average of the middle tasks. The highest and lowest claims are thrown out.

I think the 'lower claim' idea went out when the credit system was changed. From CreditNew:

If replication is used, we take the set of instances for which approx is false. If this set is nonempty, we grant the average of their claimed credit.

But the point about credit being completely separate from the 'canonical result' is still true.

The canonical result, is the result kept for future use, it has no significance in allocating credit. With two tasks processed for the WU, granted credit is equal to the lower claim, if three or more tasks are validated it is the average of the middle tasks. The highest and lowest claims are thrown out.

I think the 'lower claim' idea went out when the credit system was changed. From CreditNew:

If replication is used, we take the set of instances for which approx is false. If this set is nonempty, we grant the average of their claimed credit.

But the point about credit being completely separate from the 'canonical result' is still true.

If it is the average of claimed credit then all the claims have to be very low for the reported incidents. This I find hard to believe, therefore I have to assume the granted is low claim when there are only two tasks.

The canonical result, is the result kept for future use, it has no significance in allocating credit. With two tasks processed for the WU, granted credit is equal to the lower claim, if three or more tasks are validated it is the average of the middle tasks. The highest and lowest claims are thrown out.

I think the 'lower claim' idea went out when the credit system was changed. From CreditNew:

If replication is used, we take the set of instances for which approx is false. If this set is nonempty, we grant the average of their claimed credit.

But the point about credit being completely separate from the 'canonical result' is still true.

If it is the average of claimed credit then all the claims have to be very low for the reported incidents. This I find hard to believe, therefore I have to assume the granted is low claim when there are only two tasks.

One possible case which fits the pseudocode in the Wiki is if one of the two claims was treated as "approx", and the other was low.

Other possible explanations include:
* Implementation doesn't match documentation
* Implementation is buggy
* Underlying algorithm is conceptually flawed

We're starting a code-walking exercise today, to try to get to the bottom of this once and for all.