We've released 4.34. The only major revision here is another check to search for this 0'd statefile error. If it encounters a 0'd statefile, and after 100 attempts over 10 minutes it cannot read the file, it should delete the statefile and the result file and start over. It should try this 3 times before giving up completely. In the process, it creates a file called zeroed_statefile_log.txt. The number in the file represents the number of times it has tried so far. (Don't change the number.)

Let me know if this happens to you ...

We've released 4.34. The only major revision here is another check to search for this 0'd statefile error. ...

...
Question: Is FLOP counting active in v4.34 ?

By empirical test, yes it is. The <result> section in client_state.xml for an AP WU being processed by 4.34 has the <fpops_cumulative> field and the value grows as work is done.

You also want to note time to completion as there was an adjustment to bring DCF more into line.


____________
Thanks to Paul and Friends
Please consider a Donation to the Seti Project

You also want to note time to completion as there was an adjustment to bring DCF more into line.

So I guess we wait to see how close Fpops are...

You also want to note time to completion as there was an adjustment to bring DCF more into line.

That would be a splitter code change, I'll be surprised if new AP work is made before the server problems settle out. The AP WU on my 10490 host was created in April, so of course has the old estimate.

Joe

Just completed my first AP4.34 wu time taken 45:31:09 Validated okay.

After reporting this morning DCF is now down to 0.21945 this is due in part to running 6.02,

(4088916)

Two further wu running all have been from april.

BionclogX is giving completion times of 42:01:40 + 3:17:36 run time
BionclogX is giving completion times of 42:52:27 + 2:44:16 run time

Hmm, the fpops based credit claim on 4088916 was 1869. That was about 41 credits per hour. On the same host with 6.02 work, the VLAR 63.98 credit units are running at about 25 credits per hour and the VHAR 19.11 credit units at about 31 credits per hour. That suggests the AP fpops may need to be scaled down before going to main.

And if you take some MAR (0.533) into account that host used to have only 17 credits per hour with v6.02.
What distribution of AR do you think to choose here, Joe ?
____________
_\|/_
Urs

Finished my first APv4.34 wu successful.
DCF before: 0.431284
to completion: 56:05:00 hours
completed in: 59:09:02 hours
DCF after: 0.349533
<fpops_cumulative>1 614 850 000 000 000
claimed credit: 1869
validated ok
granted credit: 1258
____________
_\|/_
Urs

Eric stated, he attempted to do the the math with the same over payment as Seti Main.
"obvious reasoning?"

Hmm, the fpops based credit claim on 4088916 was 1869. That was about 41 credits per hour. On the same host with 6.02 work, the VLAR 63.98 credit units are running at about 25 credits per hour and the VHAR 19.11 credit units at about 31 credits per hour. That suggests the AP fpops may need to be scaled down before going to main.

Joe

Hmm, the fpops based credit claim on 4088916 was 1869. That was about 41 credits per hour. On the same host with 6.02 work, the VLAR 63.98 credit units are running at about 25 credits per hour and the VHAR 19.11 credit units at about 31 credits per hour. That suggests the AP fpops may need to be scaled down before going to main.

Joe

Eric stated, he attempted to do the the math with the same over payment as Seti Main.
"obvious reasoning?"

Hi Joe,

I take it from the Hmmm it was only a suggestion.

Just gone back over 1100 wu most 6.02 to the 29th june most of them match up with my wing hosts only a few came in at 19.12 knocked back to 19.11 I did how ever find a couple of computor errors which I'll dig out tomorrow as I'm off to the land of nod.

Michael

Just completed two more AP4.34 wu’s both Validated okay.

After reporting these this morning DCF is now down to 0.260107.

(4089288)44:21:27 claimed 1869.04 granted 693.68

(4089287)44:19:14 claimed 1869.04 granted 1689.54

michael

Finished my first APv4.34 wu on linux successful.
DCF before: 0.811734
to completion: 106:13:03 hours
completed in: 95:15:16 hours
DCF after: 0.808313
<fpops_cumulative>1 614 850 000 000 000
claimed credit: 1869
validated ok
granted credit: 1269

One thing puzzles me here: why is the wu-time on x86_64 now 50% longer than with 4.33 ? Maybe this wu only ?
____________
_\|/_
Urs

Just completed last AP4.34 wu’s Validated okay. And last 6.02.


(4089287)100:52:31 1869.04 claimed 767.72 granted same claimed credits on this host (laptop T2080 1.73 GHz) as main host Q6600 2.40GHz.

Well, well --

Looks like I've finally arrived at a nearly correct setting -- course, it took the download of 4.34 to do it (I guess), but Time to Complete and Calculated completion values are very close together (122 hours vs 117 hours). Also, the system is not driving BOINC into 24/7 priority. DCF is set at 1.000000.

We'll see how the package comes out about 4 to 5 days from now ....
____________


If I've lived this long, I've gotta be that old

Just completed first of the latest batch off AP4.34 wu’s Pending. Start DCF .253944 complete DCF .341649


(4148972)44:51:31 claimed 1869.04

(4145070)44:31:55 claimed 1869.04

Origional Download completion times for units were 30:09:04

Michael

Bringing this to the correct forum:

Could you show me where you got the 50% figure from? As of 2:30 pm 7/17, I see two successful 4.34 Linux results in the database (out of 62 successful workunits), which have received_time - sent_time = 4.02 days and 5.25 days. For the 4.33 Linux results, the received_time - sent_time ranges from 2 to 24 days, with an average of 11.23 days.

Check hostid 16343 tasklist for the ca. 50% figure. There is only one 4.34 result (done with the x86_64 application on opensuse10.3 64bit) in that list and a few 4.33 before.