Something I 'should' have said originally...
Reported RDCF is... 1.349718

(RDCF=Result Duration Correction Factor)
____________

Updating as the W/U is now overdue
Shows 66.770% cpu time 714:36:00 to finish 306:07:30.
714:36/66.77% = 1070.24 less 714.6 = 355.64 left

From now about 21.9 days if the time to complete is correct. But time to finish plus time spent running doesn't add up to the percent done divided by the time spent running. Something is going on there. Perhaps it is why the work unit got sent to this host in the first place.

The DCF in the client_state.xml file is the same for the Seti Beta project as on the web site. You didn't mention to look for the project in the file as it wasn't the first project.

Gary with what you gave
316 hrs/30% * 100 = 1052.8 hrs or 43 days

Using Explorer and find in the BOINC folder "client_state.xml" file you can search for <duration_correction_factor> to find the "active" number on your computer.
Please use notepad to prevent stray information from affecting the client_state.xml file.

Al:
That would be the correct host. Presently showing cpu time 315:58:xx, percent 30.015, to complete 525:45:xx with a DCF of 1.120672. Not sure where to find the DCF on the computer side but that's what's on the website.

Gary

Gary

Thank you for hanging in there, I presume that HostID 22531 is the one your are talking about.

Do you have an idea of the DCF and runtime numbers, CPU Time, Percent complete and estimated run time from BOINC Manager?

Al

Got a W/U that looks like it won't finish until about 6 days past it's deadline.
http://setiweb.ssl.berkeley.edu/beta/workunit.php?wuid=1147085
Looks like Astropulse should have never sent this machine a w/u as it's been running 24/7 on it. [uh maybe 23.75/7 -- ME's got to be rebooted daily] Before it downloaded the W/U it had an Einstein w/u in the queue that hadn't started yet that said it would take about 7 days to complete. Obviously the time to complete needs some revision on the server side before Astropulse goes live.

I'm going to let the w/u finish as I think I'll still be done before another result comes back. And also I may be providing a very slow machine data point for the w/u scheduling side of the world. And maybe a Windows ME data point too.


Oh, the Mac side of the house the 4.33 testing goes on. Had one w/u fail immediately after a reboot
http://setiweb.ssl.berkeley.edu/beta/workunit.php?wuid=1145206
Got another crunching.

Hi,

after more than 1 year not crunching for SETI beta I wanted to give Astropulse a try and downloaded my first AP workunit.

But as you can see, my wingmen already got their credits (but I guess the credits were granted manually).

I just got an odd set of messages reporting an AP task:

I just got an odd set of messages reporting an AP task:

...
Sun 6 Jul 14:30:00 2008|SETI@home Beta Test|Scheduler request failed: Server returned nothing (no headers, no data)
...
Sun 6 Jul 14:31:06 2008|SETI@home Beta Test|Scheduler request succeeded: got 0 new tasks
Sun 6 Jul 14:31:06 2008|SETI@home Beta Test|Message from server: Completed result ap_23ap08aa_B0_P1_00305_20080619_14751.wu_2 refused: result already reported as success

The WU was cleared from my BOINC Manager (v5.10.45) on the second attempt; the result indeed seems to have been received OK, awaiting quorum at the moment.

Hi,

after more than 1 year not crunching for SETI beta I wanted to give Astropulse a try and downloaded my first AP workunit.

Finished after 268 hours. Initial estimates were around 185 hours (DCF climbed from 1 to 1.437656, Athlon XP 2000+, 256 MB RAM, Win98 SE).

But as you can see, my wingmen already got their credits (but I guess the credits were granted manually).

The already granted credits of my successful wingman were removed from the "Workunit details" page (but not from the "Computer summary" page) shortly after I started crunching. After this result passed a proper validation the result got 1,748.80 credits again. The computer summary now shows 3,498 total credits although this computer crunched only this task. That's a nice present for my wingman ... ;-)

Regards,
Carsten

Updating as the W/U is now overdue
Shows 66.770% cpu time 714:36:00 to finish 306:07:30.
714:36/66.77% = 1070.24 less 714.6 = 355.64 left

Jim et al

Various programs that allow multiple users to access the same "file" follow different rules about what happens when the file is open and someone touches it. Any Seti application follows the Common Sense Rules. Virus scanners tend to ignore those rules, IF they trap a virus they want to insure they have it LOCKED! Then it can not do any damage. That is a reason why people tell you to exclude BOINC and any Project Applications and/or directories.

I hope that makes more sense...

Al

I run a relatively old version of Symantec Antivirus. I'll see if I can exclude files.

I'm not sure I am comfortable with this explanation. Windows apps should be able to retry or somehow get around trying to read a file that is being virus scanned. Admitting that I know nothing about AP, why should it be any different than other Windows BOINC apps that don't have this problem?

Thanks,
Jim

I run a virus scan. I'm not sure how to figure out if it looks at the BOINC folder. Even so, why would I get this error? My other BOINC apps don't seem to mind.

Thanks,
Jim

Some virus scanners may lock files while they are scanning them.
The AP application probably needs exclusive access to its files.

Which scanner do you use?

In most virus scanners it is possible to exclude certain folders or files from scanning.

Just completed my first Astropulse workunit.

309 hours with 1.2 GHz AMD Duron.

-Juha

Jim et al

Various programs that allow multiple users to access the same "file" follow different rules about what happens when the file is open and someone touches it. Any Seti application follows the Common Sense Rules. Virus scanners tend to ignore those rules, IF they trap a virus they want to insure they have it LOCKED! Then it can not do any damage. That is a reason why people tell you to exclude BOINC and any Project Applications and/or directories.

I hope that makes more sense...

Al

cut.

OK I have done some testing re the locked files, first with all Boinc files and directories excluded from real time scanning, and then with real time scanning turned off. (Vista/OneCare) The results are consistent in the fact that none of these procedures had any effect on the 'Can't delete previous state file; The system cannot find the file specified. (0x2)'

I have 4 applications running at all times and all of these write to the same file, is this what is locking the file and disallowing it's deletion? Or is one of the running apps trying to delete the file while another app has it in a rewrite state?

The other concern, is this behaviour causing or adding to any of the errors, both in Seti and AP?

I know that 4.33 is old now, but is the Mac app going to take 370+ hours for a G4 like mine? Or is it the debugging that is going on that causes the long run times?

BTW, I tried 4.34 this morning and got 2 compute errors right away. Here is one of them. I notified Dotsch, and hopefully he can pinpoint the problem with 4.34 on PPC.
____________
Click to help Seti City.

How did you get a Mac app? I don't see it in the apps list.

Jim

I know that 4.33 is old now, but is the Mac app going to take 370+ hours for a G4 like mine? Or is it the debugging that is going on that causes the long run times?

BTW, I tried 4.34 this morning and got 2 compute errors right away. Here is one of them. I notified Dotsch, and hopefully he can pinpoint the problem with 4.34 on PPC.

How did you get a Mac app? I don't see it in the apps list.

Jim

I know that 4.33 is old now, but is the Mac app going to take 370+ hours for a G4 like mine? Or is it the debugging that is going on that causes the long run times?

BTW, I tried 4.34 this morning and got 2 compute errors right away. Here is one of them. I notified Dotsch, and hopefully he can pinpoint the problem with 4.34 on PPC.

Thanks,

Jim

How did you get a Mac app? I don't see it in the apps list.

Jim

I know that 4.33 is old now, but is the Mac app going to take 370+ hours for a G4 like mine? Or is it the debugging that is going on that causes the long run times?

BTW, I tried 4.34 this morning and got 2 compute errors right away. Here is one of them. I notified Dotsch, and hopefully he can pinpoint the problem with 4.34 on PPC.

I have been beta testing for Dotsch; it's not ready for prime time yet. PM him for more info.

Updating as the W/U is now overdue
Shows 66.770% cpu time 714:36:00 to finish 306:07:30.
714:36/66.77% = 1070.24 less 714.6 = 355.64 left

http://setiweb.ssl.berkeley.edu/beta/workunit.php?wuid=1147085

Good Luck. The new wingman is running an Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz [x86 Family 6 Model 15 Stepping 11].

I hope you get credit even if he reports first.

Updating as the W/U is now overdue
Shows 66.770% cpu time 714:36:00 to finish 306:07:30.
714:36/66.77% = 1070.24 less 714.6 = 355.64 left

http://setiweb.ssl.berkeley.edu/beta/workunit.php?wuid=1147085

Good Luck. The new wingman is running an Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz [x86 Family 6 Model 15 Stepping 11].

I hope you get credit even if he reports first.

He reported a long time ago. Understand manual credits are being given. Anyway final update, now at 99.351% done showing about 7 hours to go and crunching for 1104 hours. It will be done by the time I wake up.

We will see what happens to the DCF after it reports!

Gary

...
Got credit, but I see the claimed credit for this work unit varies from 669.38 up to 2,167.15 a factor of over 3! Something better be done about getting the counts correct before Astropulse goes live on the main site or the complaints will be flying.
...
Gary

...
Got credit, but I see the claimed credit for this work unit varies from 669.38 up to 2,167.15 a factor of over 3! Something better be done about getting the counts correct before Astropulse goes live on the main site or the complaints will be flying.
...
Gary

AstroPulse 4.34 and 4.35 report exactly 1.61485e+15 fpops_cumulative for completed WUs, which converts to a claim of 1869.04 credits. The fpops are proportionally reduced if the app exits early, as for 30 pulses found.

Joe