[Karl Schimanek]

Originally Posted by Karl Schimanek 

Alex, what's about DTrace? Maybe a better option than Shark?

Regards

DTrace

[adream]

this is how my 8-core rac graph looks like,

appears that it has reached the limit of RAC

pretty bleeding amazing tho :-)

regards

adream

[zombie67]

Yep, mine looked almost exactly the same. Mine topped out a few hundred less. I could probably make up the difference if I didn't use it as my daily work machine. I am now adding other projects, so you will see the RAC drop dramatically.

[bobpalmer]

I had renamed the app_info.xml file when boinc was not recognizing anonymous platform. Yesterday boinc started running WU's with a new app version 518. I don't see anything in the log file going back to May 29 about downloading a new app version. Of course the new version 518 is not optimized, and the run times are ridiculously long.

2007-06-20 02:37:48 [SETI@home] Starting task 21fe99aa.15509.22386.61078.3.207_0 using setiathome_enhanced version 513
2007-06-20 02:50:58 [SETI@home] Starting task 12ap99aa.21719.22673.179842.3.107_0 using setiathome_enhanced version 518

Is Alex's optimized code compatible with version 518 requirements? I had been running seti_enhanced-ppc-v7.1-g5-nographics.

-- B

[adream]

same thing happened to me

boinc dumped the optimised client and ran unoptimised for a day, hence the sudden drop in RAC

i just reinstalled the optimised app and all is well

mine was also running without an app info file quite happily for a couple of weeks, i think they changed something on the server and its all back to normal now

regards

adream

[arkayn]

Right now I only have the 513 settings in my app info file due to the problems with the 5.9.X line of workers. I will add in anything else when they come out with the new workers.

[beadman]

Alex: Help!!

I was running the seti_enhanced-i386-v7.2-coreduo-nographics, with the correct app_info.xml version on my MBP and some time last night, BOINC downloaded the default.setiathome_5.18_i686-apple-darwin version which increased my times by about 25%. I took it back out and restarted the enhanced version. Are we going to have to check daily to make sure we're running the correct client?

beadman

[zombie67]

Sounds like the app_info.xml needs to be updated to account for this. I don't know how though.

[Odysseus]

Originally Posted by zombie67 

Sounds like the app_info.xml needs to be updated to account for this. I don't know how though.

It should just be a matter of changing the version entry, or adding another one, like this:
<app_version>
<app_name>setiathome_enhanced</app_name>
<version_num>518</version_num>
<file_ref>
<file_name>seti_enhanced-ppc-v7.1-g4-nographics</file_name>
<main_program/>
</file_ref>
</app_version>
(Of course the file_name should be that of whichever optimized app you’re running.)

@Alex (or anyone who’s “in the loop”): any idea of when optimized apps based on the v5.18 (or later) sources might become available?

[arkayn]

Looks like I might have to put back in Alex's original app_info file now. It has all the stops up to 5.18.

[beadman]

Alex:
Don't know if you've seen this before or not, but I'm getting some errors in my work units - doesn't affect validation, but thought I'd mention it anyway. The stderr out says:

<core_client_version>5.8.17</core_client_version>
<![CDATA[
<stderr_txt>
MacOS Error -5000 occured in /Users/alexkan/seti/boinc/mac_build/../api/mac_icon.C line 107
MacOS Error -5000 occured in /Users/alexkan/seti/boinc/mac_build/../api/mac_icon.C line 107
OS X optimized S@H Enhanced application by Alex Kan
Version info: OS X SSE3 (Intel, Core Duo-optimized v7.2-nographics) V5.13 by Alex Kan

Work Unit Info:
...............
WU true angle range is : 0.433785
MacOS Error -5000 occured in /Users/alexkan/seti/boinc/mac_build/../api/mac_icon.C line 107
MacOS Error -5000 occured in /Users/alexkan/seti/boinc/mac_build/../api/mac_icon.C line 107
OS X optimized S@H Enhanced application by Alex Kan
Version info: OS X SSE3 (Intel, Core Duo-optimized v7.2-nographics) V5.13 by Alex Kan

Work Unit Info:
...............
WU true angle range is : 0.433785

Flopcounter: 16036158013403.041016

Spike count: 0
Pulse count: 1
Triplet count: 3
Gaussian count: 0
</stderr_txt>
]]>
Validate state Valid

Hope this helps...
beadman

[Odysseus]

Originally Posted by beadman 

MacOS Error -5000 occured in /Users/alexkan/seti/boinc/mac_build/../api/mac_icon.C line 107

This has come up here before, somewhere upthread, and also in the S@h Mac Q&A forum (where IIRC Alex indicated that he’s aware of it). It’s apparently triggered by an attempt to give the executable file its green-dish icon, which fails due to some kind of permissions issue; it happens with the stock v5.13 apps as well.

[beadman]

Originally Posted by Odysseus 

This has come up here before, somewhere upthread, and also in the S@h Mac Q&A forum (where IIRC Alex indicated that he’s aware of it). It’s apparently triggered by an attempt to give the executable file its green-dish icon, which fails due to some kind of permissions issue; it happens with the stock v5.13 apps as well.

Ok, thanks for the info. I hadn't seen that. Just thought I mention it just in case.

beadman

[bobpalmer]

Originally Posted by Odysseus 

It should just be a matter of changing the version entry, or adding another one, like this:
<app_version>
<app_name>setiathome_enhanced</app_name>
<version_num>518</version_num>
<file_ref>
<file_name>seti_enhanced-ppc-v7.1-g4-nographics</file_name>
<main_program/>
</file_ref>
</app_version>

I would assume that there are different results expected from different versions. Just changing the version_num in the app_info.xml would not change the fact that Alex's V7.1 was written as a version 513 app. But then maybe someone has better information about what the changes are between 513 and 518. In the past, S@H stopped sending WU's if the app was too old.

[kennet]

559019275 136959645 26 Jun 2007 8:57:40 UTC 26 Jun 2007 16:09:26 UTC Over Client error Aborted 0.00 0.00 ---
559019255 136959613 26 Jun 2007 8:57:40 UTC 26 Jun 2007 13:13:04 UTC Over Client error Aborted 0.00 0.00 ---
559019131 136959579 26 Jun 2007 8:57:40 UTC 26 Jun 2007 14:35:52 UTC Over Client error Aborted 0.00 0.00 ---
559018769 136959464 26 Jun 2007 8:57:40 UTC 26 Jun 2007 19:28:00 UTC Over Client error Aborted 0.00 0.00 ---
558863667 136909323 26 Jun 2007 5:07:55 UTC 26 Jun 2007 11:50:21 UTC Over Client error Aborted 0.00 0.00 ---

Ever since I have been using 5.10.7 there have been over an hundred occurrences of this error. The one saving grace is that there is no time consumed on the work units. Of course there is the time downloading and the invalidated effort by both the user and Boinc.

Contrary to others here my application never did download 518 and still is using 513.

Has anyone else experienced this error?

Is it Boinc side or our side?

Kenn

[adream]

Originally Posted by kennet 

559019275 136959645 26 Jun 2007 8:57:40 UTC 26 Jun 2007 16:09:26 UTC Over Client error Aborted 0.00 0.00 ---
559019255 136959613 26 Jun 2007 8:57:40 UTC 26 Jun 2007 13:13:04 UTC Over Client error Aborted 0.00 0.00 ---
559019131 136959579 26 Jun 2007 8:57:40 UTC 26 Jun 2007 14:35:52 UTC Over Client error Aborted 0.00 0.00 ---
559018769 136959464 26 Jun 2007 8:57:40 UTC 26 Jun 2007 19:28:00 UTC Over Client error Aborted 0.00 0.00 ---
558863667 136909323 26 Jun 2007 5:07:55 UTC 26 Jun 2007 11:50:21 UTC Over Client error Aborted 0.00 0.00 ---

Ever since I have been using 5.10.7 there have been over an hundred occurrences of this error. The one saving grace is that there is no time consumed on the work units. Of course there is the time downloading and the invalidated effort by both the user and Boinc.

Contrary to others here my application never did download 518 and still is using 513.

Has anyone else experienced this error?

Is it Boinc side or our side?

Kenn

AFAIK thats not an error Kenn, thats a new feature !

once theres a quorum of two reached with results database then your boinc manager is told that crunching these WU's is unnecessary so your manager aborts em

save you crunching stuff that has already been returned and checked against another result

theres lots of talk whether this effects RAC etc but to me it seems like a good idea as far as the science and our electricity bills are concerned crunching only what is needed

regards

adream

[BTBlomberg]

So adream, this is likely more of a problem if one has <work_buf_min_days> set too high in their global_pref file? I say that because if the machine is not fast enough to cruch a WU in time to reach participation in the quorum one must be fetching too many days of WUs. If so one would get stuck in a pattern of "Errors" like kennet.

If so kennet may need to back this value off. Right?

[adream]

yup instinctively i would say that big caches on slow computers will be effected unless it updates often which doesn't seem to happen

im trying to drop my cache down to a day or so but have 800 ghost wu's on my 8-core :-)

regards

adream

[kennet]

Originally Posted by kennet 

559019275 136959645 26 Jun 2007 8:57:40 UTC 26 Jun 2007 16:09:26 UTC Over Client error Aborted 0.00 0.00 ---
559019255 136959613 26 Jun 2007 8:57:40 UTC 26 Jun 2007 13:13:04 UTC Over Client error Aborted 0.00 0.00 ---
559019131 136959579 26 Jun 2007 8:57:40 UTC 26 Jun 2007 14:35:52 UTC Over Client error Aborted 0.00 0.00 ---
559018769 136959464 26 Jun 2007 8:57:40 UTC 26 Jun 2007 19:28:00 UTC Over Client error Aborted 0.00 0.00 ---
558863667 136909323 26 Jun 2007 5:07:55 UTC 26 Jun 2007 11:50:21 UTC Over Client error Aborted 0.00 0.00 ---
Kenn

If you check the times here you will see that the WUs did not sit more than an half day. In many cases they sat for as little as two to three hours on my computer.

This computer has a RAC of 2300. I have reduced, as indicated in a previous email, the
number of days cache to one.

Kenn

[BTBlomberg]

This whole thing seams odd as I have several PC and two G4 laptops all running with 5 or more days of cache and have not seen this issue. On the PCs I am using the KWSN optimized clients Alex has had his hands in and on G4s the latest Optimized client from Alex.

I know after the horrific downtime last month WU that were ghosts (not really downloaded) were being resent to those who were suposed to have gotten them, could it be that they were resent after their preasigned report by date?

[adream]

Originally Posted by BTBlomberg 

This whole thing seams odd as I have several PC and two G4 laptops all running with 5 or more days of cache and have not seen this issue. On the PCs I am using the KWSN optimized clients Alex has had his hands in and on G4s the latest Optimized client from Alex.

I know after the horrific downtime last month WU that were ghosts (not really downloaded) were being resent to those who were suposed to have gotten them, could it be that they were resent after their preasigned report by date?

AFAIK the aborted units only happen with 5.10.7 version of boinc manager,so if yoour not running that they arent gonna happen

regards

adream

[beadman]

Wow! Just saw Bad to the Bone at RAC 6159 with a quad - what a performance! He's beating out all the V8's running windoze!

beadman

[zombie67]

w00t!!

[arkayn]

I think I have hit my top RAC at 1928, I have been hovering around there for the last week or so.

[beadman]

Originally Posted by arkayn 

I think I have hit my top RAC at 1928, I have been hovering around there for the last week or so.

That's pretty good - my MBP hovers around 1400.
beadman

[Odysseus]

Originally Posted by bobpalmer 

I would assume that there are different results expected from different versions. Just changing the version_num in the app_info.xml would not change the fact that Alex's V7.1 was written as a version 513 app. But then maybe someone has better information about what the changes are between 513 and 518. In the past, S@H stopped sending WU's if the app was too old.

AIUI there are no substantive differences between the Multibeam app and earlier S@h Enhanced versions, although the credit claims (i.e. Flop multiplier) for the new version has been adjusted. The screensaver shows some additional WU specs relevant to the new data, and has been retitled.

One telling piece of evidence that the apps are essentially compatible arises from the unfortunate fact that some naughty people have been running optimized v5.15-based apps in the Beta project (where stock has been v5.17+): they’re apparently quite normal as far as the scientific validity is concerned. There has been a little irritation expressed at the fact that they underclaim WRT the Multibeam versions, though, and with a quorum of only two on the main project such murmurs—as there have been about old BOINC clients that make time-&-benchmarks claims—are likely to become an outcry once users of the new stock app start noticing a reduction in grants when paired with older optimized apps.

So I hope the optimizers are ‘on their marks’ to release versions compiled from the Multibeam codebase as soon as the new versions become ‘mainstream’—that is, released for the majority platform (whose name I won’t be so crass as to mention here ).

[kennet]

Originally Posted by Odysseus 

released for the majority platform (whose name I won’t be so crass as to mention here ).

Hey, the Commodore 64 is a hell of a machine.

[Bad to the bone]

Originally Posted by beadman 

Wow! Just saw Bad to the Bone at RAC 6159 with a quad - what a performance! He's beating out all the V8's running windoze!

beadman

Gaining strength again after the worker was kicked out by 5.18...
Where are the other guys running v8? Quit for good?

[zombie67]

I am running a veeery small share of S@H right now. Trying to bring up the scores on the smaller projects for a while now.

[Elphidieus]

Originally Posted by Bad to the bone 

Gaining strength again after the worker was kicked out by 5.18...
Where are the other guys running v8? Quit for good?

Welp... I guess I'm waiting for Alex's V8 client to complement my V8 beast....

[Bad to the bone]

Originally Posted by Elphidieus 

Welp... I guess I'm waiting for Alex's V8 client to complement my V8 beast....

Why not join the test crew?

[Elphidieus]

Originally Posted by Bad to the bone 

Why not join the test crew?

I wish I could participate, but my V8's still less than full capacity... Stock RAM and not running 24/7...

Will add more RAM in about a week or two...

[Bad to the bone]

Originally Posted by Elphidieus 

I wish I could participate, but my V8's still less than full capacity... Stock RAM and not running 24/7...

Will add more RAM in about a week or two...

Are we talking the same subject? I mean pre-release v8 of Alex's worker, not the 8 core box. Kinda confusing with all the eights. ;-)

[Elphidieus]

Originally Posted by Bad to the bone 

Are we talking the same subject? I mean pre-release v8 of Alex's worker, not the 8 core box. Kinda confusing with all the eights. ;-)

Are we on a different subject....? If I had confused you, i'd better apologise. However, I was referring to Alex's pre-release v8 client, and yes, I was also referring to my v8 box...

Right now I'm on v7.2, but it's not on full speed because of the memory bottleneck. Testing Alex's v8 client will not benefit due to the bandwidth issue....

[Bad to the bone]

A clear 8!

I wonder if Alex is already quietly coding on a 5.23 (or wherever the current development process will end) optimized worker. The days of 5.13 are numbered anyway and it seems, the pace is increasing. Nevertheless, what we have now is still VERY competitive.

[arkayn]

He is going to have to have it done soon as they plan on releasing multi-beam this week.

[zombie67]

Will the current optimized app work with MB at all? or just slower than it could? I still am not clear.

What exactly will happen when MB units start flowing, to those of us with app_info.xml? Will we just stop getting work?

[Gecko_r7]

Originally Posted by zombie67 

Will the current optimized app work with MB at all? or just slower than it could? I still am not clear.

What exactly will happen when MB units start flowing, to those of us with app_info.xml? Will we just stop getting work?

Yes it would work, but the new 5.24 main ap will have a new load store adjustment aka credit multiplier.
Older opt. aps will claim incorrect credit based on the older multiplier & when paired w/ the newer aps w/ the revised multiplier in quorum....well, you KNOW what will happen next. Let the anger and complaints begin.....

Once a final transition point is determined, I'd guess to get work on main will likely require either deletion of app_info or a version number edit in the app_info.xml

[kennet]

Index of /~alexkan/seti

Here are the new Alex Kan Seti Enhanced nographics versions 7.2. I take it that the mb in
the version name means multibeam?

I do not know if they process multibeam or not but these were made available the
21 and 22 of August 2007, as indicated at Alex's download site.

Anybody else know. At a quick glance when I installed it and reinstalled Boinc 5.10.7 it
appeared that Seti resent the 'lost results' which I believe were multibeam.

http://tbp.berkeley.edu/~alexkan/set...nographics.zip core duo
http://tbp.berkeley.edu/~alexkan/set...nographics.zip core 2
http://tbp.berkeley.edu/~alexkan/set...nographics.zip G4
http://tbp.berkeley.edu/~alexkan/set...nographics.zip G5

Kenn

[reader50]

alexkan posted this in a different thread.

Originally Posted by alexkan 

[I am currently unable to post to the main SETI boards because my RAC is too low, so if someone could link to this post in one of the relevant discussions on the main boards, that would be fantastic. In the meantime, I'm working on getting my RAC above the required threshold.]

Let me start by apologizing for putting all you Mac crunchers in the uncomfortable position of having to choose between an optimized app with an outdated multiplier and a stock app whose multiplier was even more inflated. Had I recognized this earlier, I would have realized that merely asking everybody to revert to stock and wait for me to release v8 (especially given its current state) was not the right course of action.

The right thing to do, which is what I'm doing now, would have been to rev all the existing apps to use the new multiplier first:

ppc-v7.1mb-g4-nographics
ppc-v7.1mb-g5-nographics
i386-v7.2mb-coreduo-nographics
i386-v7.2mb-core2-nographics

The stderr output from these updated apps will have an extra "mb" in their version number, and will print the value of LOAD_STORE_ADJUSTMENT in use. As an extra measure of future-proofing, these apps will respect the per-WU <credit_rate> tags, if present. Sources for both v7.1mb and v7.2mb have been posted as well, in case people want to check my implementation of this feature for correctness.

As for v8...if I had a firm date for when it'll be done, I would have told everyone. I have been trying to finish up the remaining non-Core2 development and benchmarking recently, though.

[Thanar]

OK, people, I am now officially puzzled with all those client versions. I used to use Alex' clients, but since BOINC started downloading newer versions of the non-optimized client by itself, I let it do its work with the stock worker.

Very recently, I've been using the stock 5.23 which by the way solved another problem I used to have, that of the WUs restarting when the processor usage % was set to lower than 100%. Seems to work fine with the stock 5.23 client at last. Relevant post can be found on SETI's forums.

Tried again to install Alex' optimized clients right now and, after I successfully managed to resolve some owner/group permissions issues, I must say that even the latest download (v7.1 g4) still registers as 5.13 under BOINC, so I guess this is a remake of the old optimized version.

So, should I stay with the stock 5.23, or change to the 22-Aug released Alex' client? I am worried that I could start having WU restart issues again if Alex' client is based on source older than that of the 5.23 stock client.

[kennet]

Wed 22 Aug 13:55:31 2007|SETI@home|Reason: requested by project
Wed 22 Aug 14:57:12 2007|SETI@home|Computation for task 02mr07ah.25481.10706.9.5.222_1 finished
Wed 22 Aug 14:57:13 2007|SETI@home|Starting 02mr07ah.30594.9888.11.5.135_0
Wed 22 Aug 14:57:13 2007|SETI@home|Starting task 02mr07ah.30594.9888.11.5.135_0 using setiathome_enhanced version 527


As you can see above, with the latest Alex Versions released on the 21 and 22 August 2007, the version number is
most definitely 527.

I do believe, and have asked Alex (no answer yet), that the mb in the new 7.2 optimized version means multibeam.

Did you perhaps download an older version in error?

Kenn

[arkayn]

Mine is showing up as 5.27 for all work units.

[Thanar]

I must apologize. Indeed, I downloaded v7.1 again and this time it works fine, reporting as 5.27 under the manager. I guess I downloaded a wrong version yesterday, since I went directly to Alex' directory listing and I suppose I got a bit confused with all those versions in there.

I should keep in mind and see if a WU restarts on me again, since this issue has been puzzling me for over a month now, and saw a solution with the stock 5.23. I guess that if Alex' client is indeed based on a more recent version than the stock 5.23, the shouldn't be any restarts.

Thank you all for your replies.

[Thanar]

Looks like something is a bit wrong with Alex' client regarding to its ability to work right with the processor usage percentage under 100%. As you can see from the massages abstract below, I had a faulty result, with zero status, but then it restarted (a couple of times but with no exits) and still running up until now...

Thu Aug 23 12:25:16 2007|SETI@home|Starting 02mr07ai.15667.481.14.5.188_1
Thu Aug 23 12:25:16 2007|SETI@home|Starting task 02mr07ai.15667.481.14.5.188_1 using setiathome_enhanced version 527
Thu Aug 23 14:09:35 2007|SETI@home|Task 02mr07ai.15667.481.14.5.188_1 exited with zero status but no 'finished' file
Thu Aug 23 14:09:35 2007|SETI@home|If this happens repeatedly you may need to reset the project.
Thu Aug 23 14:59:56 2007|SETI@home|Restarting task 02mr07ai.15667.481.14.5.188_1 using setiathome_enhanced version 527
Thu Aug 23 17:03:37 2007|SETI@home|Restarting task 02mr07ai.15667.481.14.5.188_1 using setiathome_enhanced version 527
Thu Aug 23 19:41:29 2007|SETI@home|Restarting task 02mr07ai.15667.481.14.5.188_1 using setiathome_enhanced version 527
Thu Aug 23 19:54:45 2007|SETI@home|Restarting task 02mr07ai.15667.481.14.5.188_1 using setiathome_enhanced version 527

Will let you know how this ends up...

[Thanar]

OK, I think I have some more information on the restarting issue... Just now, the client paused (although there was no visual feedback from BOINC manager), processor activity near zero, accumulated CPU time stopped increasing and, two minutes later, the client started again, adding another "Restarting task..." line in the logs. What gives? Anyone can duplicate such a behaviour? Mind you, you have to reduce the processor usage percentage through preferences to match my configuration. I have it set currently to 50%.

However, looks like the situation has improved regarding the older versions, since it used to indeed restart the task back then. Looks like it resumes the task with this build. Let me repeat that the issue is not occurring when using the stock 5.23 client.

Any help would be greatly appreciated...

[kennet]

Wish I could help but I have not had this problem.

You could try reinstalling the Boinc Client: This will/should not affect your optimizer already included in your projects folder.

As a matter of interest, when I started to use the latest Kan optimizer, I had to reinstall the Boinc Client.

Kenn

[jedimstr]

You may also want to "Reset the Project" as the error message suggests. This will flush out the current hanging WUs and get a whole fresh set. If it still acts the same, or if it's fixed, let us know.

Originally Posted by Thanar 

OK, I think I have some more information on the restarting issue... Just now, the client paused (although there was no visual feedback from BOINC manager), processor activity near zero, accumulated CPU time stopped increasing and, two minutes later, the client started again, adding another "Restarting task..." line in the logs. What gives? Anyone can duplicate such a behaviour? Mind you, you have to reduce the processor usage percentage through preferences to match my configuration. I have it set currently to 50%.

However, looks like the situation has improved regarding the older versions, since it used to indeed restart the task back then. Looks like it resumes the task with this build. Let me repeat that the issue is not occurring when using the stock 5.23 client.

Any help would be greatly appreciated...

[arkayn]

Any time that I change something in that folder I end up having to reinstall the manager to get it back working.

[alexkan]

Originally Posted by Thanar 

OK, I think I have some more information on the restarting issue... Just now, the client paused (although there was no visual feedback from BOINC manager), processor activity near zero, accumulated CPU time stopped increasing and, two minutes later, the client started again, adding another "Restarting task..." line in the logs. What gives? Anyone can duplicate such a behaviour? Mind you, you have to reduce the processor usage percentage through preferences to match my configuration. I have it set currently to 50%.

However, looks like the situation has improved regarding the older versions, since it used to indeed restart the task back then. Looks like it resumes the task with this build. Let me repeat that the issue is not occurring when using the stock 5.23 client.

Any help would be greatly appreciated...

This could be happening because the app is built against a relatively old version of the BOINC libraries. I haven't made a habit of actually building from something more recent from CVS, so in theory these are the same libraries that I used when I initially began releasing optimized apps for Enhanced. I can try to fix this for future builds, but I think I'm going to leave the 7.1mb and 7.2mb apps the way they are for now.