Astropulse 4.35 has just been released. This is intended to be the version that gets released to the public project. All the bugs that were in 4.34, are still in 4.35. (Except that it's now compiled with optimization, and a few other minor fixes.) We just want to make sure that we haven't inadvertently introduced any major new bugs. But feel free to report on all bugs.
Astropulse 4.35 has just been released. This is intended to be the version that gets released to the public project. All the bugs that were in 4.34, are still in 4.35. (Except that it's now compiled with optimization, and a few other minor fixes.) We just want to make sure that we haven't inadvertently introduced any major new bugs. But feel free to report on all bugs.
If this is the release version, it should have the correct year in the copyright notice of "astropulse_4.35_COPYRIGHT". It looks like this atm:
____________
_\|/_
Urs
Astropulse 4.35 has just been released. This is intended to be the version that gets released to the public project. All the bugs that were in 4.34, are still in 4.35. (Except that it's now compiled with optimization, and a few other minor fixes.) We just want to make sure that we haven't inadvertently introduced any major new bugs. But feel free to report on all bugs.
Congratulations, on the impending public release. I would love to run it, but am still getting Message from server:Astropulse is not available for your type of computer errors. Have I missed something along the way? Do i finaly have to load an ap info file into Beta?
Thanks,
Dick
____________
The estimated times with APv4.35 seem to be back in the same range as v4.33 was.
T7200, opensuse 10.3:
v4.35 : estimation ca. 60h
v4.34 : run times ca. 95h
v4.33 : run times ca. 60h
____________
_\|/_
Urs
How do we get 4.35 ? I'm still running 4.34. Will it update automatically?
How do we get 4.35 ? I'm still running 4.34. Will it update automatically?
Yes, it will update automatically (unless you're running with an app_info.xml). BOINC doesn't update immediately, it will finish any AP WUs which your host has already downloaded with 4.34 but for any new AP work downloaded it will get 4.35.
The Server Status page indicates that the is;
Results ready to send 174,871
Results in progress 8,873
Am I right in assuming a lot of this is enhanced MB, and unless we select AP only, that it will be quite a while before the AP units are processed.
If so can issue of the MB units be delayed so that at least some of the AP units can be checked using 4.35 before it is released to the masses on the main site.
The Server Status page indicates that the is;
Results ready to send 174,871
Results in progress 8,873
Am I right in assuming a lot of this is enhanced MB, and unless we select AP only, that it will be quite a while before the AP units are processed.
If so can issue of the MB units be delayed so that at least some of the AP units can be checked using 4.35 before it is released to the masses on the main site.
It may even be that all AP work has previously been assigned and the only ones which show up will be replacements for deadline timeouts or compute errors. It's my impression that AP work already has a higher priority.
I just went through the list of tasks on host 19596 (the current top host). It completed its last AP WU with 4.34 3 days ago, all work assigned since is enhanced MB.
The Server Status page indicates that the is;
Results ready to send 174,871
Results in progress 8,873
Am I right in assuming a lot of this is enhanced MB, and unless we select AP only, that it will be quite a while before the AP units are processed.
If so can issue of the MB units be delayed so that at least some of the AP units can be checked using 4.35 before it is released to the masses on the main site.
It may even be that all AP work has previously been assigned and the only ones which show up will be replacements for deadline timeouts or compute errors. It's my impression that AP work already has a higher priority.
I just went through the list of tasks on host 19596 (the current top host). It completed its last AP WU with 4.34 3 days ago, all work assigned since is enhanced MB.Joe
If you look at the index for http://boinc2.ssl.berkeley.edu/beta/download/ (which I don't recommend - especially on your dialup, Joe), you'll see that some/all of the AP data files are in the root of the download folder, not distributed through the fanout (that's what makes it such a pig to load). But it makes it easy to find the most recent work, which is:
ap_23mr08ab_B2_P1_00011_20080723_17023.wu created 23-Jul-2008 08:31
So the splitter is active today, and there should be tasks in the pipeline. We just have to munch our way through the MB stuff first. I was doing quite well while it was all shorties, but I'm starting to get the long stuff now.
Is it time to invoke Plan B again?
Edit - thinking about it: yes, I give notice that I do intend to invoke Plan B, at least on my BOINC v6.2.14 box: partly to flush the MB queue, but also to test my co-running app_info.xml, and also because nobody has answered my sandbox question yet.
The Server Status page indicates that the is;
Results ready to send 174,871
Results in progress 8,873
Am I right in assuming a lot of this is enhanced MB, and unless we select AP only, that it will be quite a while before the AP units are processed.
If so can issue of the MB units be delayed so that at least some of the AP units can be checked using 4.35 before it is released to the masses on the main site.
It may even be that all AP work has previously been assigned and the only ones which show up will be replacements for deadline timeouts or compute errors. It's my impression that AP work already has a higher priority.
I just went through the list of tasks on host 19596 (the current top host). It completed its last AP WU with 4.34 3 days ago, all work assigned since is enhanced MB.Joe
If you look at the index for http://boinc2.ssl.berkeley.edu/beta/download/ (which I don't recommend - especially on your dialup, Joe), you'll see that some/all of the AP data files are in the root of the download folder, not distributed through the fanout (that's what makes it such a pig to load). But it makes it easy to find the most recent work, which is:
ap_23mr08ab_B2_P1_00011_20080723_17023.wu created 23-Jul-2008 08:31
So the splitter is active today, and there should be tasks in the pipeline. We just have to munch our way through the MB stuff first. I was doing quite well while it was all shorties, but I'm starting to get the long stuff now.
Is it time to invoke Plan B again?
Edit - thinking about it: yes, I give notice that I do intend to invoke Plan B, at least on my BOINC v6.2.14 box: partly to flush the MB queue, but also to test my co-running app_info.xml, and also because nobody has answered my sandbox question yet.
I think the reason the MB units are back in the mix is because they are testing a mixed workflow because AP is 99.9% ready to go live on the main site.
Don't know the answer to your sandbox question, but you have to on a Mac as I'm testing AP on a Mac I know.
Gary
Well, that worked better than I could have expected:
23/07/2008 18:54:35|SETI@home Beta Test|Restarting task 23ap08aa.2018.21749.6.11.175_1 using setiathome_enhanced version 602
23/07/2008 19:03:48|SETI@home Beta Test|Sending scheduler request: To fetch work. Requesting 36 seconds of work, reporting 0 completed tasks
23/07/2008 19:03:53|SETI@home Beta Test|Scheduler request succeeded: got 1 new tasks
23/07/2008 19:03:55|SETI@home Beta Test|Started download of ap_23ap08ab_B1_P0_00120_20080716_06439.wu
23/07/2008 19:04:55|SETI@home Beta Test|Finished download of ap_23ap08ab_B1_P0_00120_20080716_06439.wu
That 'restart' was to activate the app_info and optimised MB / manually downloaded AP app. I've suspemded cached work, so the AP will start next.
And the test revealed something interesting:
23/07/2008 19:21:59|SETI@home Beta Test|Starting ap_23ap08ab_B1_P0_00120_20080716_06439.wu_1
23/07/2008 19:21:59|SETI@home Beta Test|[error] Process creation failed:
23/07/2008 19:22:00|SETI@home Beta Test|[error] Process creation failed:
23/07/2008 19:22:00|SETI@home Beta Test|[error] Process creation failed:
23/07/2008 19:22:01|SETI@home Beta Test|[error] Process creation failed:
23/07/2008 19:22:02|SETI@home Beta Test|[error] Process creation failed:
23/07/2008 19:22:02|SETI@home Beta Test|Computation for task ap_23ap08ab_B1_P0_00120_20080716_06439.wu_1 finished
23/07/2008 19:22:02|SETI@home Beta Test|Output file ap_23ap08ab_B1_P0_00120_20080716_06439.wu_1_0 for task ap_23ap08ab_B1_P0_00120_20080716_06439.wu_1 absent
Task 4243740. We're going to have to work on this.
Hmmm. This is getting worrying.
I'm not surprised the first one failed, because I deliberately moved (as opposed to copied) the downloaded .exe files into the project directory: I know this can cause permission problems.
So then I copied the files from another disk. Task 4243701.
And then I did a full 'repair' installation of BOINC v6.2.14, to fix the permissions the way the Mac users have to. Task 4243782.
(Both those failures showed five 'Process creation failed' errors in the message log, as before).
Can y'all have a think about this, while I grab something to eat? Box is XP Home SP3, so I have limited tools to view/change users and permissions. Other projects on other cores, and AK_V8 on this Beta project, all run fine, so the problem is strictly limited to Astropulse.
But at least the WUs are coming thick and fast: I have two more ready to blow up after dinner.....
Panic over. Turned out to be a corrupted download - requested 452KB, got 120KB. Now I've got the full file, it's running OK.
Leaving this thread for AP 4.35 error reporting - moving over to Astropulse release soon for deployment issues.
Finished my first APv4.35 wu after ca. 57h successful claiming 719.356481481482 cr, less than half than v4.34. I hope the stderr.txt looks like intended (see below). Still can't get the graphics to work on opensuse 10.3 64bit. Now the graphics button is greyed out.
<stderr_txt>
In ap_gfx_main.cpp: in ap_graphics_init(): Starting client.
In ap_client_main.cpp: in mainloop(): at dm_chunk_large 896
In ap_client_main.cpp: in mainloop(): at dm_chunk_large 1024
...<snip>
In ap_client_main.cpp: in mainloop(): at dm_chunk_large 3328
In ap_client_main.cpp: in mainloop(): at dm_chunk_large 3456
In ap_gfx_main.cpp: in ap_graphics_init(): Starting client.
In ap_client_main.cpp: in mainloop(): at dm_chunk_large 3456
...<snip>
In ap_client_main.cpp: in mainloop(): at dm_chunk_large 14848
In ap_client_main.cpp: in mainloop(): at dm_chunk_large 14976
called boinc_finish
</stderr_txt>
____________
_\|/_
Urs
Finished my first APv4.35 wu after ca. 57h successful claiming 719.356481481482 cr ....
Claimed credit 719.36, from BOINC v5.10.45? That wasn't in the script:
Astropulse 4.35 has just been released. This is intended to be the version that gets released to the public project. All the bugs that were in 4.34, are still in 4.35. (Except that it's now compiled with optimization, and a few other minor fixes.) We just want to make sure that we haven't inadvertently introduced any major new bugs. But feel free to report on all bugs.
I thought we were on flop counting now?
...
I thought we were on flop counting now?
I still think we are :
------------------------------------------------------------------------
r277 | korpela | 2008-07-15 02:23:20 +0200 (Di, 15 Jul 2008) | 2 lines
Changed paths:
M /astropulse/client/astropulse.h
Updated flops value for claimed credit.
------------------------------------------------------------------------
/astropulse/client/astropulse.h
#define TOTAL_FLOPS 1.61485e+15/2
This made me expect: half the FLOPs and half the credit, but its less.
edit:Devs changed that again to the current value in astropulse.h
r289 | korpela | 2008-07-22 02:15:59 +0200 (Di, 22 Jul 2008) | 3 lines
Changed paths:
M /astropulse/client/astropulse.h
Updated FPOPS for credit calculation.
------------------------------------------------------------------------
#define TOTAL_FLOPS 6.21524e+14
____________
_\|/_
Urs
So we've abandoned any pretence of actually counting the flops (probably wisely - the variation in credit/hour at different ARs was always a bit hard to reconcile with the concept of 'counting'), and moved to fixed credits instead?
Except for BOINC v4 clients, of course.....
So we've abandoned any pretence of actually counting the flops (probably wisely - the variation in credit/hour at different ARs was always a bit hard to reconcile with the concept of 'counting'), and moved to fixed credits instead?
Except for BOINC v4 clients, of course.....
For setiathome_enhanced, "counting" as a single word description is appropriate. It isn't implemented as counting by 1 for every floating point operation, of course. Instead it takes the number of fp operations within a loop, scales by the number of iterations of the loop, and adds that to the count. The reason for the mismatch with time is partly because even on very modern processors different kinds of fp operations have different costs, but even more because of all the other stuff which has to be done before and after the fp operations.
For AP, the fpops are the same for every WU, so precalculating it is quite practical. It REALLY ought to be passed in the WU header, though, so if they changed some of the parameters controlling what's done the fpops could be changed to match. As it stands, they'd have to make a new build.
My first AP 4.35 task under Windows, 4243659, has reported: 1 day 17:14:55 on the Q9300. My six day MCHE mode cache has turned into over 20 days of work, according to BOINCview (though I don't think I believe it, because I haven't updated the resource shares properly). It'll take at least 13 days to work these ones off, though.
stderr_txt contains the same debug output as Urs reported for Linux yesterday:
In ap_client_main.cpp: in mainloop(): at dm_chunk_large 896
In ap_client_main.cpp: in mainloop(): at dm_chunk_large 1024
....