reference WU Result Overflow @ NetBSD

Questions and Answers : Unix/Linux : reference WU Result Overflow @ NetBSD
Message board moderation

To post messages, you must log in.

AuthorMessage
Dotsch
Volunteer tester
Avatar

Send message
Joined: 9 Jun 99
Posts: 2422
Credit: 919,393
RAC: 0
Germany
Message 172233 - Posted: 27 Sep 2005, 7:41:47 UTC

I have tried to compile boinc and seti for NetBSD (x86).
But I if I run my binary against the reference WU, I get a result overflow after 35 % :

SETI@Home Informational message -9 result_overflow
NOTE: The number of results detected exceeds the storage space allocated.

Any hints ?

ID: 172233 · Report as offensive
Profile Crunch3r
Volunteer tester
Avatar

Send message
Joined: 15 Apr 99
Posts: 1546
Credit: 3,438,823
RAC: 0
Germany
Message 172265 - Posted: 27 Sep 2005, 12:00:35 UTC

Might be related to copiler flags like -ffast-math etc.

Join BOINC United now!
ID: 172265 · Report as offensive
Dotsch
Volunteer tester
Avatar

Send message
Joined: 9 Jun 99
Posts: 2422
Credit: 919,393
RAC: 0
Germany
Message 172296 - Posted: 27 Sep 2005, 15:20:42 UTC - in response to Message 172265.  

Might be related to copiler flags like -ffast-math etc.

Thanks, will try to recompile it.
Was compiled "only" with -O3 -funroll-loops.

ID: 172296 · Report as offensive
Dotsch
Volunteer tester
Avatar

Send message
Joined: 9 Jun 99
Posts: 2422
Credit: 919,393
RAC: 0
Germany
Message 172904 - Posted: 29 Sep 2005, 21:04:39 UTC - in response to Message 172296.  

Might be related to copiler flags like -ffast-math etc.

Thanks, will try to recompile it.
Was compiled "only" with -O3 -funroll-loops.

No success with reduced optimisation.
ID: 172904 · Report as offensive
Profile Crunch3r
Volunteer tester
Avatar

Send message
Joined: 15 Apr 99
Posts: 1546
Credit: 3,438,823
RAC: 0
Germany
Message 172915 - Posted: 29 Sep 2005, 21:32:39 UTC - in response to Message 172904.  

Might be related to copiler flags like -ffast-math etc.

Thanks, will try to recompile it.
Was compiled "only" with -O3 -funroll-loops.

No success with reduced optimisation.


Wich compiler version did you use ? If its a gcc 3.x.x try using "-ffloat-store" as cflag.


Join BOINC United now!
ID: 172915 · Report as offensive
Dotsch
Volunteer tester
Avatar

Send message
Joined: 9 Jun 99
Posts: 2422
Credit: 919,393
RAC: 0
Germany
Message 173198 - Posted: 1 Oct 2005, 0:30:04 UTC - in response to Message 172915.  


No success with reduced optimisation.


Wich compiler version did you use ? If its a gcc 3.x.x try using "-ffloat-store" as cflag.
[/quote]
Used gcc version 3.3.3 (NetBSD nb3 20040520)
Have resolved such a simliar problem with -ffloat-store ?
ID: 173198 · Report as offensive
Profile Crunch3r
Volunteer tester
Avatar

Send message
Joined: 15 Apr 99
Posts: 1546
Credit: 3,438,823
RAC: 0
Germany
Message 173214 - Posted: 1 Oct 2005, 1:39:03 UTC - in response to Message 173198.  
Last modified: 1 Oct 2005, 1:44:23 UTC


No success with reduced optimisation.


Wich compiler version did you use ? If its a gcc 3.x.x try using "-ffloat-store" as cflag.

Used gcc version 3.3.3 (NetBSD nb3 20040520)
Have resolved such a simliar problem with -ffloat-store ? [/quote]

Yes.There's a bug in gcc up to gcc 3.4.4 causing a SIGFP/SIGSEGV.
It is suggested to use the "-ffloat-store" cflag.
Also JUST use "-O2".
If all of that wont work try adding a "-mieee".

Give it a try.



Join BOINC United now!
ID: 173214 · Report as offensive
Dotsch
Volunteer tester
Avatar

Send message
Joined: 9 Jun 99
Posts: 2422
Credit: 919,393
RAC: 0
Germany
Message 173303 - Posted: 1 Oct 2005, 10:35:36 UTC - in response to Message 173214.  

Used gcc version 3.3.3 (NetBSD nb3 20040520)
Have resolved such a simliar problem with -ffloat-store ?


Yes.There's a bug in gcc up to gcc 3.4.4 causing a SIGFP/SIGSEGV.
It is suggested to use the "-ffloat-store" cflag.
Also JUST use "-O2".
If all of that wont work try adding a "-mieee".
[/quote]
Hm, will try it, but I don't get any SIGSEGV or SIGFP.
But the results from the reference WU differs stongly.

ID: 173303 · Report as offensive
Dotsch
Volunteer tester
Avatar

Send message
Joined: 9 Jun 99
Posts: 2422
Credit: 919,393
RAC: 0
Germany
Message 173553 - Posted: 2 Oct 2005, 10:53:19 UTC - in response to Message 173303.  
Last modified: 2 Oct 2005, 10:53:50 UTC

Used gcc version 3.3.3 (NetBSD nb3 20040520)
Have resolved such a simliar problem with -ffloat-store ?


Yes.There's a bug in gcc up to gcc 3.4.4 causing a SIGFP/SIGSEGV.
It is suggested to use the "-ffloat-store" cflag.
Also JUST use "-O2".
If all of that wont work try adding a "-mieee".

Hm, will try it, but I don't get any SIGSEGV or SIGFP.
But the results from the reference WU differs stongly.
[/quote]

Thanks, the first run against the reference WU produces now valid results. I had compiled it with "-O -ffloat-store".
The next, more optimized binary is now running against the reference WU.

Is it posible, that -ffloat-store slow down the seti app by ~10 % ?

ID: 173553 · Report as offensive
Profile Crunch3r
Volunteer tester
Avatar

Send message
Joined: 15 Apr 99
Posts: 1546
Credit: 3,438,823
RAC: 0
Germany
Message 173575 - Posted: 2 Oct 2005, 12:53:06 UTC - in response to Message 173553.  

Used gcc version 3.3.3 (NetBSD nb3 20040520)
Have resolved such a simliar problem with -ffloat-store ?


Yes.There's a bug in gcc up to gcc 3.4.4 causing a SIGFP/SIGSEGV.
It is suggested to use the "-ffloat-store" cflag.
Also JUST use "-O2".
If all of that wont work try adding a "-mieee".

Hm, will try it, but I don't get any SIGSEGV or SIGFP.
But the results from the reference WU differs stongly.


Thanks, the first run against the reference WU produces now valid results. I had compiled it with "-O -ffloat-store".
The next, more optimized binary is now running against the reference WU.

Is it posible, that -ffloat-store slow down the seti app by ~10 % ?
[/quote]

No i dont think so (should be less than 1-3%).
By way i remember that tetsuji maverick rai said that in his tests with FreeBSD it showed a 10% slowdown compared to linux that's why he droped the client for it and went back to linux.



Join BOINC United now!
ID: 173575 · Report as offensive
Dotsch
Volunteer tester
Avatar

Send message
Joined: 9 Jun 99
Posts: 2422
Credit: 919,393
RAC: 0
Germany
Message 174621 - Posted: 6 Oct 2005, 5:57:46 UTC - in response to Message 173303.  

Yes.There's a bug in gcc up to gcc 3.4.4 causing a SIGFP/SIGSEGV.
It is suggested to use the "-ffloat-store" cflag.
Also JUST use "-O2".
If all of that wont work try adding a "-mieee".

Do you have some more details about this bug ? - A link ?


ID: 174621 · Report as offensive
Profile Crunch3r
Volunteer tester
Avatar

Send message
Joined: 15 Apr 99
Posts: 1546
Credit: 3,438,823
RAC: 0
Germany
Message 174650 - Posted: 6 Oct 2005, 9:37:05 UTC - in response to Message 174621.  

Yes.There's a bug in gcc up to gcc 3.4.4 causing a SIGFP/SIGSEGV.
It is suggested to use the "-ffloat-store" cflag.
Also JUST use "-O2".
If all of that wont work try adding a "-mieee".

Do you have some more details about this bug ? - A link ?


https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=138791
http://bugs.mysql.com/bug.php?id=2338
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13719

Join BOINC United now!
ID: 174650 · Report as offensive
Dotsch
Volunteer tester
Avatar

Send message
Joined: 9 Jun 99
Posts: 2422
Credit: 919,393
RAC: 0
Germany
Message 175745 - Posted: 9 Oct 2005, 11:50:02 UTC - in response to Message 174621.  

[quote]Yes.There's a bug in gcc up to gcc 3.4.4 causing a SIGFP/SIGSEGV.
It is suggested to use the "-ffloat-store" cflag.
Also JUST use "-O2".
If all of that wont work try adding a "-mieee".

Was not resolved by use this flags. It works only temporarly.
The first run with the reference WU was successfull. After a test with live WUs I get the error again.
Btw. -mieee is only supported on alpha.


ID: 175745 · Report as offensive
Profile Crunch3r
Volunteer tester
Avatar

Send message
Joined: 15 Apr 99
Posts: 1546
Credit: 3,438,823
RAC: 0
Germany
Message 176218 - Posted: 10 Oct 2005, 13:17:06 UTC - in response to Message 175745.  

[quote]Yes.There's a bug in gcc up to gcc 3.4.4 causing a SIGFP/SIGSEGV.
It is suggested to use the "-ffloat-store" cflag.
Also JUST use "-O2".
If all of that wont work try adding a "-mieee".

Was not resolved by use this flags. It works only temporarly.
The first run with the reference WU was successfull. After a test with live WUs I get the error again.
Btw. -mieee is only supported on alpha.


Thats strange :-( especially because the reference wu works now.
Did all you "live WUs" fail or just some of them ? It might be possible that you've got a bunch full noisy Wus.


Join BOINC United now!
ID: 176218 · Report as offensive
Dotsch
Volunteer tester
Avatar

Send message
Joined: 9 Jun 99
Posts: 2422
Credit: 919,393
RAC: 0
Germany
Message 176287 - Posted: 10 Oct 2005, 16:34:24 UTC - in response to Message 176218.  

[quote]Yes.There's a bug in gcc up to gcc 3.4.4 causing a SIGFP/SIGSEGV.
It is suggested to use the "-ffloat-store" cflag.
Also JUST use "-O2".
If all of that wont work try adding a "-mieee".

Was not resolved by use this flags. It works only temporarly.
The first run with the reference WU was successfull. After a test with live WUs I get the error again.
Btw. -mieee is only supported on alpha.


Thats strange :-( especially because the reference wu works now.
Did all you "live WUs" fail or just some of them ? It might be possible that you've got a bunch full noisy Wus.


It was one regular WU, and one with noise. The regular WU was not validated, and has a result overflow, too.

But, in the moment I am testing again, with a different setup :

The reference WU with the app, compiled with gcc 3.3 and "-O -ffloat-store", was successfull on the first system. With "-O2 -ffloat-store" was no pulses detected, but with "-O -ffloat-store" everything is OK.
The second system runs the reference WU against this new binary in the moment.
Next step, if the second system computes right too, is to let some live WUs run.

But, I had readen in a other post, that anyone had the same probelms with the pules on NetBSD Sparc.
ID: 176287 · Report as offensive
Dotsch
Volunteer tester
Avatar

Send message
Joined: 9 Jun 99
Posts: 2422
Credit: 919,393
RAC: 0
Germany
Message 179199 - Posted: 17 Oct 2005, 7:49:17 UTC - in response to Message 176287.  


But, in the moment I am testing again, with a different setup :

The reference WU with the app, compiled with gcc 3.3 and "-O -ffloat-store", was successfull on the first system. With "-O2 -ffloat-store" was no pulses detected, but with "-O -ffloat-store" everything is OK.
The second system runs the reference WU against this new binary in the moment.
Next step, if the second system computes right too, is to let some live WUs run.

The changes in the CFLAGS don't change anything. Problem still extists.

ID: 179199 · Report as offensive
Profile Crunch3r
Volunteer tester
Avatar

Send message
Joined: 15 Apr 99
Posts: 1546
Credit: 3,438,823
RAC: 0
Germany
Message 179247 - Posted: 17 Oct 2005, 13:07:09 UTC - in response to Message 179199.  


But, in the moment I am testing again, with a different setup :

The reference WU with the app, compiled with gcc 3.3 and "-O -ffloat-store", was successfull on the first system. With "-O2 -ffloat-store" was no pulses detected, but with "-O -ffloat-store" everything is OK.
The second system runs the reference WU against this new binary in the moment.
Next step, if the second system computes right too, is to let some live WUs run.

The changes in the CFLAGS don't change anything. Problem still extists.


Maybe it has something to do with that:

-mno-fancy-math-387

Some 387 emulators do not support the sin, cos and sqrt instructions for the 387. Specify this option to avoid generating those instructions. This option is the default on FreeBSD, OpenBSD and NetBSD. This option is overridden when -march indicates that the target cpu will always have an FPU and so the instruction will not need emulation. As of revision 2.6.1, these instructions are not generated unless you also use the -funsafe-math-optimizations switch.


http://developer.apple.com/documentation/DeveloperTools/gcc-3.3/gcc/i386-and-x86_002d64-Options.html

Join BOINC United now!
ID: 179247 · Report as offensive
Dotsch
Volunteer tester
Avatar

Send message
Joined: 9 Jun 99
Posts: 2422
Credit: 919,393
RAC: 0
Germany
Message 180683 - Posted: 21 Oct 2005, 9:15:56 UTC - in response to Message 179247.  

[quote]
Some 387 emulators do not support the sin, cos and sqrt instructions for the 387. Specify this option to avoid generating those instructions. This option is the default on FreeBSD, OpenBSD and NetBSD. This option is overridden when -march indicates that the target cpu will always have an FPU and so the instruction will not need emulation. As of revision 2.6.1, these instructions are not generated unless you also use the -funsafe-math-optimizations switch. [quote]
Thanks with -funsafe-math-optimizations and -ffloat-store I get now the first validated result.

But I am not shure, if this is a problem on my system. I tested the binaries, with different FLAGS on two different systems, mostly on both systems, the reference WU was OK.
If I run it against a live WU on my system, I get only with the CFLAGS above a valid result. So I am not shure, if this is a hardware problem (memory, cpu or cache) or OS problem on my system. - But under windows this system produce only valid WUs.

I will start a new thread for requesting jelp from the netbsd people, in the hope that anyone can let run the different apps, and reverify the work of the different apps.



ID: 180683 · Report as offensive
Dotsch
Volunteer tester
Avatar

Send message
Joined: 9 Jun 99
Posts: 2422
Credit: 919,393
RAC: 0
Germany
Message 195844 - Posted: 26 Nov 2005, 20:28:55 UTC - in response to Message 180683.  

Thanks with -funsafe-math-optimizations and -ffloat-store I get now the first validated result.

Now I have the same problem on NetBSD on sparc. But it will now not been fixable by use this flags.
Have anyone a idea ?
ID: 195844 · Report as offensive
Profile Crunch3r
Volunteer tester
Avatar

Send message
Joined: 15 Apr 99
Posts: 1546
Credit: 3,438,823
RAC: 0
Germany
Message 195993 - Posted: 26 Nov 2005, 22:35:41 UTC - in response to Message 195844.  

Thanks with -funsafe-math-optimizations and -ffloat-store I get now the first validated result.

Now I have the same problem on NetBSD on sparc. But it will now not been fixable by use this flags.
Have anyone a idea ?


Actually i don't have access to a sparc and have no clue. This whole xxxBSD stuff seems to be real strange when it comes to compile standard source.

For instance my optimized setiathome for freeBSD was kind of weired.
On freeBSD the use 16-byte aligned malloc and thereby it was a real pain to get fftw3 compile.

Anyway you could try "-msoft-float or -mno-fpu" for software assistance in floatingpoint operations but it'll slow down. But it also depends how the whole system libs (libc etc.) is compiled.

That's the only thing i can think off otherwise you're on your own. Sorry


Join BOINC United now!
ID: 195993 · Report as offensive

Questions and Answers : Unix/Linux : reference WU Result Overflow @ NetBSD


 
©2025 University of California
 
SETI@home and Astropulse are funded by grants from the National Science Foundation, NASA, and donations from SETI@home volunteers. AstroPulse is funded in part by the NSF through grant AST-0307956.