I hope so, it'd take me a long time to make up those 99 Trillion Credits ... :)

The /stats directory where the xml resides has been protected now, probably to prevent the stats from being picked up. I guess my stats just got it a little too quickly though. I'll hang on and see if it's updated again otherwise I'll restore the beta stats back to the last update..

Bok

It seems that there are again some units being credited too high:

WU 2412545 claimed 111.55, granted 1,107.58

WU 2623621 claimed 111.53, granted 1,387.23

Now that the new validator has been running for over a week, and the replica database has caught up so we can see our results, I thought I'd see how things are going.

Ever since SETI went to 'flopcounter' credit some years ago, the value of a task has been pretty rigorously defined - sure, there are a few glitches, the occasional BOINC v4 client, early exits (-9 overflow) and so on, but in general the principle held. Then we got CUDA, and a task could have two different values - a higher flopcount with the CUDA app, or a lower flopcount with the CPU app. Under quorum rules, CUDA-CUDA scores high, all others score low. (Generalisations all round, but I'm just reminding people of the groundwork).

Here are a couple of graphs, drawn from the 800 or so tasks I've reported and had validated since 6 April (OK, 834 to be precise) - hence exclusively with the new validators. Mostly, I seem to have been working on resends, so I've had a high validation rate - fewer than 200 pendings in the same period. I haven't looked to see when or what my various wingmates reported or claimed. All of my tasks were run on one of my three 9800GT-series CUDA cards, using Jason's experimental hybrid app.


(Direct link)

This graph shows the amount of credit I claimed, and the amount granted. Note that I've had to go to a logarithmic scale to accommodate WU 2602546 - my record for this series with 4,703.16 credits awarded. You can see that the vast majority of my tasks were mid-AR claiming 114 credits at the start of the run, gradually declining to 111 credits at the end - I wonder if Eric's 60-day normalisation average script is fighting against David's 'new credit' validators?


(Direct link)

I wondered whether the new formula would settle down over time, so this graph plots the %age by which the credit granted was above or below my claim, against the time when my task was reported (I got a huge allocation on Saturday because of the 'DCF squared problem I've written about elsewhere, so I've been reporting them in batches - hence the vertical lines). I've omitted that extreme value, and also 42 (just on 5%) '-9 overflow' tasks claiming less than 1 credit - the %age variation is pretty meaningless for those.

Edit - since I've got all those figures in Excel, it's a cinch to total them. Claimed 87,228.27, granted 135,854.09

Being on the BETA project is always a bit problematic ... 4 years ago I was granted "-10,675,007.77" credits ... and was locked out of BETA for a few days 'till it was reset to "0". Perfection on the first try is not a requirement ... (but it does give us something to talk about)

EdF

---

Good morning.

How is David getting on with new AP validation Code?

Or are we waiting for all WU's to be returned?

Michael

Yeah, I would like to see how new AP build validates ;)

---

News about SETI opt app releases: https://twitter.com/Raistmer

I came across host 40143 (task list) while I was checking quorum partners yesterday. It appears never to have produced valid work since it was attached a year ago. Not a problem, because the daily quota of one task per day kept things under control.

Until 17 April, when the daily quota mechanism was re-jigged with the intention of establishing separate limits for each application (a good thing, IMO). But it hasn't worked: this host has trashed 8,400 tasks in 25 days.

The question is, how many other hosts like this are out there? If we could pull a list together, Eric could block them from wasting bandwidth while David finishes off the new server code.

I came across host 40143 (task list) while I was checking quorum partners yesterday. It appears never to have produced valid work since it was attached a year ago. Not a problem, because the daily quota of one task per day kept things under control.

Until 17 April, when the daily quota mechanism was re-jigged with the intention of establishing separate limits for each application (a good thing, IMO). But it hasn't worked: this host has trashed 8,400 tasks in 25 days.

The question is, how many other hosts like this are out there? If we could pull a list together, Eric could block them from wasting bandwidth while David finishes off the new server code.

Almost all Linux hosts are erroring every AP task they get, and the ATI hybrid also gets quite a few errors. The project has been creating about 630 AP WUs a day recently, a high majority get 6 errors promptly so exceed the max allowed.

I haven't done a thorough survey, but perhaps 10% don't reach too many errors. Some might provide some useful data for the Beta testing, like WU 2724574.

Anyhow, a random wuid anyplace between 2720000 and 2730000 will probably turn up several more hosts which are promptly trashing every task they get, but have not been throttled by the quota.

                                                            Joe

Now when Validator works again, some big irregularity in credit granting for AP results revealed.
not early exited result claims ~1k of credits (more than on SETI main btw).
Sometimes it get ~2k of credits, twice more than requested (!), sometimes it get only ~250 credits, 4 time less than requested.

If such code will go on SETI main we will get new "credit uprising" w/o any doubts :)

---

News about SETI opt app releases: https://twitter.com/Raistmer

Yeah you're right. Yesterday I had more than 30k credits pending and today I received about 13k.. I processed quite a few of astropulse units with my GPU/CPU and the results are pretty strange

All the GPU tasks had 1095.01 and received from 263-2107 credits. The CPU tasks also claimed 1095.01 and received from 190-470 credits

I think there is not only a problem with granted credits calculation (since it was always 1095.01 no matter the cpu/run times) but also the problem with calculations regarding granted credits (eg. sometimes one task acuired 4x more credits than a similarly long one)

The other problem is that calculating astropulse on ATI GPU gives like 50x less credits than Collatz and other projects - I don't know if it's something wrong with SETI or the other projects calculations

Just in case I attach the results

Regards
Chris

Credits per 1000s time | Results data | Task ID | Run | CPU | Claimed | Granted
2.42 | AstroPulse v5.05 | 7920433 | 136,300.48 | 132,460.60 | 1,095.01 | 320.78
2.43 | AstroPulse v5.05 | 7920427 | 138,606.00 | 133,639.30 | 1,095.01 | 324.97
2.53 | AstroPulse v5.05 | 7920423 | 133,364.57 | 129,790.70 | 1,095.01 | 328.01
1.39 | AstroPulse v5.05 | 7897166 | 156,972.40 | 138,315.90 | 1,095.01 | 192.10
3.63 | AstroPulse v5.05 | 7897163 | 149,851.39 | 130,632.90 | 1,046.78 | 474.49
1.89 | AstroPulse v5.05 | 7896995 | 162,833.30 | 136,592.60 | 1,095.01 | 257.87
1.93 | AstroPulse v5.05 | 7832241 | 143,577.55 | 134,743.00 | 1,095.01 | 260.49
2.15 | AstroPulse v5.05 | 7829373 | 140,725.81 | 127,920.30 | 1,095.01 | 274.55
3.31 | AstroPulse v5.05 | 7829285 | 135,651.63 | 128,397.90 | 1,095.01 | 424.46
2.05 | AstroPulse v5.05 | 7823963 | 142,229.24 | 132,894.80 | 1,095.01 | 272.78
3.31 | AstroPulse v5.05 | 7820407 | 139,942.38 | 132,330.10 | 1,095.01 | 437.89
2.89 | AstroPulse v5.05 | 7820403 | 143,260.81 | 132,093.20 | 1,095.01 | 381.93
6.07 | AstroPulse v5.05 (ati13ati | 7829353 | 47,485.24 | 43,420.16 | 1,095.01 | 263.48
23.9 | AstroPulse v5.05 (ati13ati) | 7829612 | 41,583.67 | 39,104.46 | 1,095.01 | 934.67
52.66 | AstroPulse v5.05 (ati13ati) | 7829605 | 42,496.54 | 40,026.17 | 1,095.01 | 2,107.70
8.09 | AstroPulse v5.05 (ati13ati) | 7829603 | 41,125.87 | 38,728.11 | 1,095.01 | 313.30
28.91 | AstroPulse v5.05 (ati13ati) | 7829597 | 53,192.27 | 49,751.57 | 1,095.01 | 1,438.18
32.53 | AstroPulse v5.05 (ati13ati) | 7829364 | 42,608.25 | 39,591.82 | 1,095.01 | 1,287.96
5.44 | AstroPulse v5.05 (ati13ati) | 7829362 | 60,393.79 | 48,600.75 | 1,095.01 | 264.44
17.22 | AstroPulse v5.05 (ati13ati) | 7829361 | 44,486.47 | 42,183.20 | 1,095.01 | 726.38
15.54 | AstroPulse v5.05 (ati13ati) | 7829335 | 47,930.88 | 44,491.75 | 1,095.01 | 691.27
6.68 | AstroPulse v5.05 (ati13ati) | 7829334 | 56,263.07 | 53,959.76 | 1,095.01 | 360.30
5.62 | AstroPulse v5.05 (ati13ati) | 7829292 | 58,893.24 | 46,977.06 | 1,095.01 | 264.09
9.16 | AstroPulse v5.05 (ati13ati) | 7827561 | 50,217.85 | 47,677.07 | 1,095.01 | 436.52
6.49 | AstroPulse v5.05 (ati13ati) | 7824099 | 46,211.11 | 43,520.53 | 1,095.01 | 282.41
9.6 | AstroPulse v5.05 (ati13ati) | 7820396 | 47,198.79 | 45,197.95 | 1,095.01 | 434.01

Well, GPU AP currently in testing here uses GPU only sometimes hence lower credit granting.
But it's only one reason for lower credits. Second came from very poorly optimized initial app for MW. They used it as reference when esteblished their credit pay rate. Since then app was greatly improved so it recives much bigger credit value.
This is fundamental problem with credit inter-project pairing.
If greatly unoptimized app had chosen as reference, subsequent app optimization will give very high credit per hour values. But SETI app already passed few optimizations, its credits are "hard earned" ones. That is, reference app here already pretty good.

---

News about SETI opt app releases: https://twitter.com/Raistmer

wu 2765337

I hope that you're joking... 17 credits for an astropulse wu?? Good that we're in beta here, so that kind of things NEVER reach seti main...

wu 2765337

I hope that you're joking... 17 credits for an astropulse wu?? Good that we're in beta here, so that kind of things NEVER reach seti main...

The task overflowed slightly past .5 fraction done, I wonder if the server somehow thought it was a S@H Enhanced shorty WU, which would get that range of credit for a 50% overflow. That's unlikely, but probably more likely than David Anderson committing a joke.

                                                                 Joe

The task overflowed slightly past .5 fraction done

what do you mean with that "the task overflowed"?
Thanks a lot for your time!

The task overflowed slightly past .5 fraction done

what do you mean with that "the task overflowed"?
Thanks a lot for your time!

Too many signals found per WU.
When 30 single pulses & 30 repetitive pulses found app finishes computation - it's result overflow. Same situation as "-9 overflow" for SETI MB app.

---

News about SETI opt app releases: https://twitter.com/Raistmer

Result 2729959--another one of those AP 1095.01 claims. After 4 error-outs, 1 timeout, 1 inconclusive, 2 of us claimed 1095.01 and were granted 150.66. What a deal ;)

Since there seem to be changes at the Main project which might imply that the new credit calculation code is heading their way, I thought it might be an idea to analyse how well it's doing.

These are all validated results using the stock v6.10 'Fermi' application since it was installed and jobs became available on 19 May, using my host 12316. I've filtered out everything except credit claims between 22.11 and 23.43 inclusive: what's left should all be VHAR 'shorties' which reached full term. There are 1,150 of them. The x-axis is the time reported: everything is a bit bunched up because of daily quota.


(Direct link)

Anyone think that's conistent, reliable and explainable enogh to be transferred to the main project? No, I didn't think so either.

1st, current the claimed Cr. are less than at MAIN.

2nd, my PC calculated a few CPU WUs and I saw, that if the WU was restarted the Cr. claim is higher.

Well (one of a few results):
resultid=8098392 (claimed credit 76.22)

Higher (because of restart):
resultid=8098377 (claimed credit 81.06)
resultid=8098356 (claimed credit 81.05)

[All AR= 0.434995]

---

[offtopic]

'unable to change project preferences'

[/offtopic]

---