[davygravy]

I have a G3 B&W 400MHz 256MB running the optimized client and worker from Team MacNN. For this one machine, I look through the newly accessible Results pages to find dozens of WU's with granted credit = 0, but with claimed credit in the 30 to 40 cs range. If I look at the details of the WU/result, I see this message:

<core_client_version>4.06</core_client_version>
<stderr_txt>
SETI@Home Informational message -9 result_overflow
NOTE: The number of results detected exceeds the storage space allocated.

</stderr_txt>

What is up? Is the client not working on my machine? Since I first noticed this, I have reinstalled the system software, put in a new G4 500MHz processor, double-checked the entire system, and this is still going on.

W/ this computer I have had two WUs validated to grant credit - vs about 20 granted 0 credit. All of the 30 pending results that I have checked have the same message in the stderr_txt field.

When I check to see the progress/outcome of other hosts' work on this unit, I see that they have been granted credit.

Anyone else have this problem?

Thanks,

davygravy

PS All of the other clients I am using on other machines are working fine - G4 & G3 optimized, and standard BOINC-issue.

[mikkyo]

How much free space is on that machine's hard drive and how much have you allocated to Seti work?

[davygravy]

Thanks for your reply, mikkyo,

Well, lots of free space, over 25GB... my prefs are:

Use no more than
.5 GB

Leave at least
.2 GB

Use no more than
10% of total space

Use no more than
75% of total virtual memory

from my hosts page for this machine...
==============
CPU type
Power Macintosh PowerMac1,1

Number of CPUs
1

Operating System
Darwin 7.5.0

Memory
256 MB

Cache
976.56 KB

Swap space
0 MB

Total disk space
29.87 GB

Free Disk Space
26.33 GB

Measured floating point speed
1005.32 million ops/sec

Measured integer speed
807.94 million ops/sec

====

I thought about that possibility, too. I did some digging and found this:

http://homepage.mac.com/pauldbuck/si...-msg-info.html

...which does say something about storage space -but I have over 25GB free. Could it be a RAM problem? Do the special compiles require more than 256MB?

I am now running the standard-issue Boinc 4.13 for Mac OS X 10.3. I'll see what stderr.txt says to that. I find it strange that no one else has had this problem... could it be bad RAM? Wait, that cant' be - I ran a RAM stress test on it not 2 weeks ago, and it passed just fine.

??

[davygravy]

I just checked the stderr.txt in the clientstate.xml, and the worker completed the WU and downloaded it without any error or message. In fact, it completed the WU in a shorter amount of time - 10hrs instead of the 12hrs needed under the G4 optimized client/worker. (maybe a bit strange

I'll keep using this (4.13 from Boinc) standard-issue client & worker until JavaLizard gets the new version out. Then I'll try the optimized clients/workers again.

I'll also update this thread as to whether I see the error reappear or not, and whether or not it was just a fluke that the optimized seemed to take longer on my mahcine than the standard-issue.

davygravy


(edit: Sorry mikkyo, I must tip my hat to __you__ - you are the one doing the heavy lifting with this compiling stuff , right? My humblest apologies to someone who is hard a work clearing the path for the rest of us. I misread a few posts and thought it was JavaLizard who did this.)

[mikkyo]

Use no more than
.5 GB

If you have 25GB free you should probably up that number to something like 2Gb.
You have it set to use no more than 10% of total space, so if you ahve a 60GB drive that is 6Gb, but the other settings leave at least 200Mb free and never use more than 500Mb.
Basically you are limiting the amount of space that can be used by boinc at any time to 500Mb and with things like servers not responding and the caching of large amounts of work, you can easily hit the limit you have set.
I'm pretty sure it has nothing to do with the version of the client you are running.
I've seen the same problem, only for me it was the 10% of total space.
I had a small partition of 10Gb with 6Gb free and 10% of 6 is 600Mb so you can see where I would run into problems. I set mine to use no more than 90% total space and basically only use the "use no more than" setting to control the actual use.

For you Boinc 4.13 experiment did you use the same workunit?
If not your comparisons mean little.

[davygravy]

Hi mikkyo,

Again, thanks for your response and encouragement.

What kind of machine was that that you had the same error on? RAM? any upgrades or changes from the original specs?

True, different workunits are different, so it is like comparing apples and oranges. But since I went to the 4.13 client, three out of three workunits have been completed and their stderr.txt contained no error messages. In contrast, at least 90% of the WU's that were completed with the optimized client had the overflow message. 100% w/ no error vs 10% w/ no error. It may be apples and oranges, but the oranges are fine & the apples are mostly all rotting (fig of speech ;^) )

Since I changed only the client & worker (4.06 -> 4.13) on my B&W, and left all other parameters (like memory and storage) unchanged, there aren't any other variables that I can see - unless perhaps the optimized client was asking for units that inherently had complexity to the results that would cause it to get overflow all of the time. Can clients "ask" for inherently messy/difficult WU's, or do they just get the luck of the draw? If it is just luck of the draw, then its seems difficult to see why I'd get (v4.13) 3/3 w/ no errors would be way different than (v4.06) 2/20 w/ no errors.

I'm not suspecting that there is something wrong with the optimized code, but rather 1 or more of us just could possibly have oddities with our machines that make the code behave unpredictably-something assumed by programmers to be universal might be different on a few modded or finicky machines. On all of my other machines the optimized code is working very well - couldn't ask for more. JavaLizard (and anyone else that may have helped) has done a superb job with them. (please see edit below**)

The memory/hd-space parameters are the same for all of my other machines/hosts, and some have the same partition setup/sizes - yet they experience no similar problem. Sooooo...I'm just not seeing what is going on for sure.

I am going to run it just as is (w/ the v4.13 standard-issue) for a week or two - if I get consistently high validation rates w/ this over the next week or two, then I have _a_ solution to the problem. But that wouldn't really fix things, since I want to run an optimized client on the G4. Of course, that's my goal.

Regardless of whether or not using the V4.13 standard issue fixes things and gives me lots of valid results, after that has run its course over the next week or two, I will try your suggestion, mikkyo. That could be it. I just don't want to throw too many variables into the soup right now.

I will post back after I carefully see what happens, get counts & results, etc. I don't want to post bad or incomplete data - that's no help to anyone who might have the same problem that I have had lately. :^\


Thanks for your reply and the good suggestions,


davygravy


(edit: Sorry mikkyo, I must tip my hat to __you__ - you are the one doing the heavy lifting with this compiling stuff , right? My humblest apologies to someone who is hard a work clearing the path for the rest of us. I misread a few posts and thought it was JavaLizard who did this. My bad. ...)

[davygravy]

Hi mikkyo,

this has happened to someone else, maybe...

check out...


Boinc Q&A Mac OS X


davygravy

[mikkyo]

To clear up one thing, javalizard made his own altivec routines for the seti worker, I have just provided optimized clients and seti worker.
javalizards version of the worker contains new code, not just compile time optimizations.
Our versions are separate and different, though you can get to both form our team's download page.

As to the problem you are seeing:
The optimized and javalizard's altivec seti workers require an app_info.xml file.
This file triggers seti to grab special workunits, so by switching to a default boinc_4.13 you have actually removed two variables from the problem, the boinc version and the platform non-specific workunits.
A couple tests you could try is the default boinc_4.13 client with the optimized seti worker(and app_info.xml file), or the 4.06 client you were using with no optimized seti worker.
It is possible to move a workunit between clients/machines but it requires a lot more hand editing of xml files and stuff.
You could also try our newer boinc_4.11 compiles.

I'll be making a boinc_4.13 version soon enough as well.

As you can see though there are a lot of variables, and by switching to the default client, you are get default workunits too which won't help track down any problem if there is one.

It is possible you are encountering a RAM issue as well, though it seems unlikely.
One of the compile settings in the optimized worker uses a lot of RAM.
The VM settings in boinc don't really translate well to how macs work, either, so they can be an issue themselves.

Were the problems you were seeing with this machine present when all it was doing was running boinc-seti and no other apps running?

If other apps are running, since it only has 256Mb of RAM, you had to be paging to disk quite frequently and this alone can not only take up space, but cause other issues with cached data, and even possibly triggering boinc limits and other craziness.
I highly recommend at least 512Mb of RAM for all MacOS X users.

Which OS version are you running?
About This Mac under the apple will tell you or sw_vers on the command line.

BTW I have had a half dozen 7450s running boinc 3.20, 4.05, 4.06 and 4.11 over the last several months and not seen this problem on any of those machines.
You didn't say which seti worker you were running, javalizard's or my optimized compile.

The machine I had the problems with due to boinc disk settings was a G5 with 1Gb RAM, so it doesn't really relate, except as an example of disk space issue potential.

[davygravy]

That all helps.

(see edits below**)
I was using the 4.06 version at http://members.dslextreme.com/~reade...eam/boinc.html , specifically, the 7410/7400 version and the G3 version. I was getting the overflow w/ both of them on the B&W. I'm not sure - is that your version or JL's version?

I am aware of the anonymous platform setup, along with the need to include the xml file giving info on platform. Back when Boinc was still at v3.? (maybe even in the 2's, as well, early last year?) , I was trying to compile it for YellowDogLinux (a PPC variant of RedHat), but I gave up on that after a while. I understand some of the most basic things on Unix/Linux, and can compile an executable, do easy cli stuff, but am no guru.


I normally don't use that B&W machine much at all (it is just a backup & archive machine fo rthe most part, except for once a month or so when my wife or daughter :^\ want my nice 17in monitor & MDD). It has only 256MB RAM, but almost never has another application running (I am looking for a cheap 256MB, anyway, though). It has literally never crashed in OS X (10.3.5 currently install) for me.

I've run the same versions of Boinc that you've run on 7600/G3, 7600/G4, eMac, MDD, 2 Beige G3's, and, alas a B&W. The B&W has given me a lot of errors, but I recently discovered, digging through my results, that the 7600 had errors as well, I believe when it was running the 7400 in a carrier card (but I think not when it was running an old NewerTech 275G3 card).

I want to rack up some more WU's and get some validated results from this current v4.13 on the B&W (make _real_ sure it actually is working like I think it is - don't want a false positive), then I'll probably try the 4.13 optimized that you put up. If that doesn't go, I'll try JL's - he rewrote the FFT routines, right? (that must have taken a bucketload of work)

Thanks for your help and ideas,

davygravy



(** I really have to read more carefully. The client that I was using was the one you provided, at the top of the page, miikkyo. I see that JL's are pretty clearly listed at the bottom of the page. His downloads are just the workers, right?)

[haddock29]

I got that error on ~90% of 500 WUs compuetd with the 7450 seti client . When the disaster appears (when seti team shos us the units list), I dediced to try the non optimized clients. I have now no errors, with boinc 4.13 ans basic seti client. I had still erros with 4.13 an d the optimized G4 7450 client. The result_overflow error used to occur very quickly, often after a few minutes of cpu time.

I had the error on 2 very similar computers: a quicksilver 2*800, and a MDD 2*867. They have resepctively 1GB and 768 MB Rams, lot of free disk space, and OS 10.3.5.
Disk and memory prefs of my account are "no more than 10 GB, leave at least 1 GB, use no more than 50% of total space, no more than 50% of virtual memory".

Then, what is wrong ?

add for mikkyo: I remember a random error which occured with OS 10.2: when moving large dat blocks in memory, they were sometimes corrupted. The MDD had the problem, the quicksilver had not. The affected software was IDL (www.rsinc.com), a visualisation and data processing package. May be the error is still documented on their site. Clearly, in that case, compiling with altivec optimization gave random errors.

Alain

[mikkyo]

Perhaps the problem was just boinc_4.06 versus the current bug fixed 4.13 version.
Have you tried the boinc_4.13 optimized version yet?
It would be good to know if the problem come back when you switch to the optimized compiled version or not.

[haddock29]

I am a little bit puzzled with the 4 possble options: boinc client optimized or not, and seti client optimized or not.
As far as I understand, the optimized boinc client gives a much higher Mflops number in the dpu bench (x3), but has no impact on the processing speed of seti WUS. The optimized seti client is 20-30% faster than the non optimized version. The net effect is that the computer claims for a higher credit when everytging is optimized.
BTW, there is no 4.13 optimized boinc client on the macnn site, only a 4.11. The only test I can do is to run an non optimized boinc, and the optimized seti worker. Is that OK ?

Alain

[mikkyo]

A faster boinc client does have a net effect, as the client handles all the non-worker work for boinc projects(server communication, logging, worker coordination, benchmarks, downloading, unzipping workunits, control of the workers, etc). The faster all that occurs the sooner the worker gets to working.
Yes it is a bit confusing since with seti you can run both optimized boinc and worker, or any combination of them.
No one has to run the optimized version at all unless they want to crunch more than other folks.

The boinc 4.13 clients are on the beta page here if anyone wants to try them out:
http://members.dslextreme.com/~reade...boincbeta.html

[haddock29]

Mikkyo

In order to isolate the problem - if any -, I restarted boinc with basic boinc client 4.13 and the setiworker G4 7450. Optimization of the seti client is the important point, because the cpu time for the boinc client is only a few minutes per day. I hope I will have some results to morrow (its 11 PM here).
I am of course interested by running macs as fast as possible, and therefore by your work on the optimization of the clients. What I wrote before was not a criticism of optimization. Also, I have not a perfect control of english language.

Alain

[davygravy]

Hi Alain & mikkyo,

I'm interested in seeing Alain's results as well. Are you saying that you are now using the standard-issue boinc 4.13 w/ javalizard's altivec G4 7450, right?

As you've probably read in these posts and over at Boinc's own message board, I've had a lot of problems on some of my machines w/ some of the versions. But for other machines it seems to have worked fine or at least OK. All my hosts are running Panther 10.3.x.

I, too, have had 90% or more of my returned results shown to be invalid, on selected machines. Now the problem seems to be fixed though, at least partially.

I tried changing my preferences to allow more hard drive space for Boinc, but after 4 days of chugging, it didn't make any difference on the machines that were experiencing the problems-still long lines of zero-credit results. Reverting to the standard-issue boinc 4.13 client and work did fix things-I started getting credits very soon after this. This was on an 1GHz eMac, stripped down educational version, w/ (don't laugh, please) 128MB RAM (I said, don't laugh! :^) ).

On my B&W w/ 512MB RAM 500MHz G4, going to the standard-issue boinc 4.13 also helped. Using the otpmized Boinc 4.06 and the altivec 7400/7410 seti worker, between 90 and 95% of the results came up w/ zero credits. When I switched to the standard-issue boinc 4.13 w/ the standard seti worker, I started getting credits awarded almost right away, and not a zero-credit result since then on that machine.

On my MDD G4 (7450) 1.25GHz 512MB, I've had pretty good results, but still some zero-credit results - using the boinc_4.06_ppcG4-7450 and setiathome_4.3_ppcG4.7450.altivec . I suspect that the zero-credit results are from a problem other than the boinc client or the seti worker...? Seems to work well on this machine. I'll try the 4.13 optimized boinc client after mikkyo says that it has been tested.

On a Beige G3 542MHz w/ 320MB RAM, I have had poor results and I'll go back to the standard issue client and worker on that machine.

So I believe the following are true, at least for my machines, and/or from my experiences:
1. for some older or low RAM machines, the optimized client seemed to have problems (but that is not the fault of the optimization process or mikkyo or javalizard - maybe the machines are just anemic somehow and can't handle it.. or the compliers/optimizers assume something about the machines that isn't true) ...leading to long strings of zero-credit results.

2. for newer machines w/ enough RAM, the optimized and/or altivec-ed clients and workers seem to do very well. thank you, mikkyo & javalizard

3. there are still some bugs in the source code - and some of the zero-credit results are a result of those bugs - not optimization errors. maybe this will improve in time.

4. sometimes boinc seems unpreditable to me... but it's getting better.

5. when experimenting with these things and trying ot track down a problem, only change one thing at a time

davygravy

[haddock29]

Tests may be quite long, and seti-boinc site has a lot of problems... I run now the boinc 4.13 non optimized client and the seti worker 4.3 G4 7450 on a MDD dual 867. The number of 0 credit files is low, but non zero. These files have no error message, but are "invalid". In seti/boinc documentation, that should mean that the results are not compatible with the other two results. This is not the massive "two many results" problem I got with the optimized 4.06 boinc client.
I will wait a few days before switching to a fully optimized (boinc and seti) config.
BTW, despite I am sure (ps command) that the optimized seti worker is running, the cpu time per unit (as indicated by top ) is very high: 8 to 9 hours /WU. It is a typical time for seti classic. I remembered that the non working fully optimized config gave time 6 to 7 hours/WU. Seems that the boinc client ( which has a very small cpu time/day) has a strong impact on the speed of the seti client (!).

Alain

[davygravy]

FYI, anyone interested, I did get things fixed up. The 4.11 G4 optimzed Boinc client w/ the G4 Seti worker had been giving me 90% errors and very few successful results.

Virtually no errors now with the regular 4.13 client and the G4 Seti worker - very few - and my Average Credit has jumped from a weak 150 all the way up to around 350. I found that in excess of 90% of my WU's results were coming up "invalid" for one reason or another, using the optimized 4.11 clients - tried on G3's and G4's, nearly all exhibited this problem.

Swicthing to the 4.13 non-optimized (regular, standard-issue) client seems to have fixed it. as I am back up getting very few errors now.

Because of an error that another team member is having, I am going to try optimized 4.13 client (G4 version) with the G4 Seti worker, just in the hopes that this will be a better combination.

davygravy