Berkeley's responsibility, which they should have exercised but didn't, would be limited to not sending new work to outdated applications.

So is it possible to be implemented at this point or has that already passed the point of no return?

Certainly. All they need to do is update the <min_version> field in the APP record in the database and make sure the Scheduler knows about the change. It defaults to 0, when the Scheduler checks that a host's app_info.xml has that or higher it will always be so. If the field were updated to 500 then new work would not be sent to older apps (I think even reissues would be restricted). That's the suggestion I made in SETI Beta before 5.00 even appeared there.

That method is not as thorough as making a different application name like "astropulse2" would have been, but a new name requires more server-side changes.

                                                               Joe

[quote]

Getting bit is bad, but like it or not, the ones who have been are a small minority.

Well, hope "small minority" way of thinking will be not extended to another spheres of existance..... :| Each disappointed cruncher from this "small minority" set is real human with real nerves and feelings....
BTW, interesting to know how big this "small minority" share in work done.
Cause each PC with optimised app is at least 2 times more valuable for project than the same PC with stock app.
And using of opt apps is well correlated with best CPUs using , with 24/7 crunching and with farm of PCs holding.
So I think this "small minority" is pretty big share of project power indeed.

Here is a problem, and I've been trying hard to not make this personal.

Lost credit is a problem, even if it's one person. It should be fixed.

I can't imagine that the problems are intentional. Eric and Josh both seem to be interested in doing the right thing, even if they aren't here all the time posting about it. When they're chatting on here, they aren't working on the problem.

I'm crunching AP with the latest optimized app., and I'm getting credit on most work units (I've been doing nothing but AP for a while, and while my machines aren't the fastest, I think the only one that wasn't granted was my fault).

I'm willing to keep crunching so I can either return damaged results for inspection, or valid completed work so they can tell it has been solved.

I don't like being told that I'm somehow insensitive. That I'm suggesting that the value of work is insignificant (although, you did say it isn't about credit, I didn't). I think the failures provide important results, even (or especially) if the result provided is "needs more work."

---

I think the failures provide important results, even (or especially) if the result provided is "needs more work."

If you would see crash on 1, 2, 10 hosts, will you try 100 000 to be convinced that problem is exist or you will launch debugger before involving 100 000 hosts in testing of faulty app ?
It's simple example when repeating "it need more work" too many times just nonsense.

Here I have a situation where I was using 5.0, wingman 4.36, and third anonimous wingman 5.0 is working right now. Let's see if all three get credit.

Two 5.0 got credits, 4.36 left behind with zero for it state "invalid" what once was "valid". All stock.

I was afraid of that, I have a similar task where I'm guessng the wingman that did the tasks back in Oct. with stock 4.36 won't get credit either.

Berkeley's responsibility, which they should have exercised but didn't, would be limited to not sending new work to outdated applications.

So is it possible to be implemented at this point or has that already passed the point of no return?

Certainly. All they need to do is update the <min_version> field in the APP record in the database and make sure the Scheduler knows about the change. It defaults to 0, when the Scheduler checks that a host's app_info.xml has that or higher it will always be so. If the field were updated to 500 then new work would not be sent to older apps (I think even reissues would be restricted). That's the suggestion I made in SETI Beta before 5.00 even appeared there.

That method is not as thorough as making a different application name like "astropulse2" would have been, but a new name requires more server-side changes.

Seems better than the alternative we have at the moment at least to me.

---

Think I am doing one now, my wingman is waiting for me his third wingman. I am using 5 and they used 4.36, so will it be sent out again?

---

Is anyone looking at the "Zero" problem?

I have 8 today and had only 4 yesterday.
It's been said that we may get credit later or may not.

I don't care about the credits, but it just seems to me to be out of control and knowbody knows what to do, or haven't indicated how to remedy it.

It will get to a point when alot of people will not want to run AP. I hope not.

---

Is anyone looking at the "Zero" problem?

Try to read relevant threads again. This was answered too many times already.

just to inform you all, i got mu astropulse credits it took a while to crunch and just as much time to credit me, i will in the future will allow more of astropulse to crunch away down my end of town :) .

oh yeah those waiting on credits, just be patient, not like me, in time the credits will come along

I quit doing AP because I will never know if I will ever get the credits that are due me I had several WU that simply disappeared I don't know where they went to I will never know beside for the amount of time involved I get less credit than with a MB WU do I quit doing those AP WU.

Hi, just added optimized AP (5.0) to 1 (QUAD6600) host, editted the app_info.xml file.
It works ok, ended with NO errors, now will have to see if they get validated and creditted.
I'am a bit confused, as to why there are that many (di
fferent) optimized versions and which one has to be used?

Here is a piece of the BOINC logfile, since the UPdate:
11-12-2008 15:46:53||BOINC 6.1.0.32 v5 - 32 bit Windows Edition by Crunch3r
11-12-2008 15:46:53||Platform: windows_intelx86
11-12-2008 15:46:53||enabled features:
11-12-2008 15:46:53||-cpu_affinity
11-12-2008 15:46:53||-delayed return_results_immediately (1 min)
11-12-2008 15:46:53||log flags: task, file_xfer, sched_ops
11-12-2008 15:46:53||Libraries: libcurl/7.16.4 OpenSSL/0.9.8e zlib/1.2.3
11-12-2008 15:46:53||Data directory: D:\Program Files\BOINC
11-12-2008 15:46:53|SETI@home|Found app_info.xml; using anonymous platform
11-12-2008 15:46:53|SETI@home|[error] State file error: duplicate app version: astropulse windows_intelx86 435
11-12-2008 15:46:53|SETI@home|[error] State file error: duplicate app version: astropulse windows_intelx86 436
11-12-2008 15:46:53||Processor: 4 GenuineIntel Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz [x86 Family 6 Model 15 Stepping 11]
11-12-2008 15:46:53||Processor features: fpu tsc sse sse2 mmx
11-12-2008 15:46:53||OS: Microsoft Windows XP: Professional Edition, Service Pack 3, (05.01.2600.00)
11-12-2008 15:46:53||Memory: 2.00 GB physical, 3.85 GB virtual
11-12-2008 15:46:53||Disk: 270.45 GB total, 269.30 GB free
11-12-2008 15:46:53||Local time is UTC +0 hours
11-12-2008 15:46:53|Einstein@Home|URL: http://einstein.phys.uwm.edu/; Computer ID: 1258433; location: home; project prefs: default
11-12-2008 15:46:53|SETI@home|URL: http://setiathome.berkeley.edu/; Computer ID: 4226016; location: home; project prefs: default
11-12-2008 15:46:53||General prefs: from SETI@home (last modified 04-Dec-2008 22:06:11)
11-12-2008 15:55:14|SETI@home|[file_xfer] Started download of file ap_06mr08af_B6_P0_00295_20081211_28384.wu
11-12-2008 15:55:51|SETI@home|[file_xfer] Finished download of file ap_06mr08af_B6_P0_00295_20081211_28384.wu
13-12-2008 15:39:08|SETI@home|Starting task ap_06mr08af_B6_P0_00295_20081211_28384.wu_1 using astropulse version 500
14-12-2008 2:16:25|SETI@home|Starting ap_31ja08aa_B6_P1_00106_20081211_16651.wu_1
14-12-2008 2:16:25|SETI@home|Starting task ap_31ja08aa_B6_P1_00106_20081211_16651.wu_1 using astropulse version 500
14-12-2008 4:36:55|SETI@home|Computation for task ap_06mr08af_B6_P0_00295_20081211_28384.wu_1 finished
14-12-2008 4:36:57|SETI@home|[file_xfer] Started upload of file ap_06mr08af_B6_P0_00295_20081211_28384.wu_1_0
14-12-2008 4:37:02|SETI@home|[file_xfer] Finished upload of file ap_06mr08af_B6_P0_00295_20081211_28384.wu_1_0
14-12-2008 13:30:05|SETI@home|Starting ap_17ap08ad_B2_P0_00144_20081211_24957.wu_1
14-12-2008 13:30:05|SETI@home|Starting task ap_17ap08ad_B2_P0_00144_20081211_24957.wu_1 using astropulse version 500

A few (small) errors, but it works (and since it works, I'am not fixing this, it isn't broken :) )
The AP WU's take about 12 hours.

---

Hi crunchers, the first optimized AP WU, got validated, here is the result:

<core_client_version>6.1.0</core_client_version>
<![CDATA[
<stderr_txt>
Unrecognized XML in parse_init_data_file: fraction_done_update_period
Skipping: 1.000000
Skipping: /fraction_done_update_period
In ap_gfx_main.cpp: in ap_graphics_init(): Starting client.
Unrecognized XML in parse_init_data_file: fraction_done_update_period
Skipping: 1.000000
Skipping: /fraction_done_update_period
AstroPulse v. 5.00
Non-graphics FFTW USE_CONVERSION_OPT USE_SSE3
Windows x86 rev 69 build 130a SSE filter by Raistmer with support of Lunatics.kwsn.net team. SSE3
SSE3 dechirping by JDWhale
CPUID: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz

Cache: L1=64K L2=4096K
Features: FPU TSC PAE CMPXCHG8B APIC SYSENTER MTRR CMOV/CCMP MMX FXSAVE/FXRSTOR SSE SSE2 HT SSE3

single pulses: 7
repetitive pulses: 30
class Astropulse::T_dechirp: total=9.39e+013, N=58167552, <>=1614252 (1.61e+006), min=1486197 (1.49e+006)
class Astropulse::T_ffa: total=2.45e+013, N=999, <>=24490429157 (2.45e+010), min=9457526574 (9.46e+009)
class Astropulse::T_coadd: total=2.06e+012, N=3139549086, <>=656 (6.56e+002), min=72 (7.20e+001)
class Astropulse::T_FFT_forward: total=2.92e+012, N=1817736, <>=1604657 (1.60e+006), min=1385991 (1.39e+006)
class Astropulse::T_FFT_inverse: total=8.13e+013, N=58167552, <>=1397557 (1.40e+006), min=1348056 (1.35e+006)
class Astropulse::T_filter: total=2.71e+011, N=1817736, <>=148991 (1.49e+005), min=106857 (1.07e+005)
called boinc_finish

</stderr_txt>
]]>

Validate state Valid
Claimed credit 755.634234334057
Granted credit 755.634234334057
application version 5.00

Here is the canonical result:

result

---

http://setiathome.berkeley.edu/workunit.php?wuid=347479884

Both validated it with 4.36... I'm using 5.00, no credit for me?

---

- Luke.

http://setiathome.berkeley.edu/workunit.php?wuid=347479884

Both validated it with 4.36... I'm using 5.00, no credit for me?

I would abort that WU since there is already a concensus for the results. Yours will just be a waste of your time

---

In a rich man's house there is no place to spit but his face.
Diogenes Of Sinope

http://setiathome.berkeley.edu/workunit.php?wuid=347479884

Both validated it with 4.36... I'm using 5.00, no credit for me?

I would abort that WU since there is already a concensus for the results. Yours will just be a waste of your time

Glad I didn't abort... because I've been given the credit!

---

- Luke.

http://setiathome.berkeley.edu/workunit.php?wuid=347479884

Both validated it with 4.36... I'm using 5.00, no credit for me?

I would abort that WU since there is already a concensus for the results. Yours will just be a waste of your time

Glad I didn't abort... because I've been given the credit!

And a genuine 'scientific match' credit to boot, because you've been given the rate for the job set by the previous hosts: if it had been Eric's script, you'd have been given your claimed figure instead.

http://setiathome.berkeley.edu/workunit.php?wuid=347479884

Both validated it with 4.36... I'm using 5.00, no credit for me?

I would abort that WU since there is already a concensus for the results. Yours will just be a waste of your time

Glad I didn't abort... because I've been given the credit!

And a genuine 'scientific match' credit to boot, because you've been given the rate for the job set by the previous hosts: if it had been Eric's script, you'd have been given your claimed figure instead.

Ah Huh, Must've been a lucky task that either didn't trigger the new Radar Blanking, or none of the original signals were found in a blanked region. Nice!

---

"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.