It returned the first result without error, but it hasn't validated yet. It's about halfway through its second 4.09 result, so we'll see which one validates first.
I can't figure out the stderr, but looks sexy though ;)
[edit]I like the pace of the beta app though. Roughly the same WUs with 4.02 take 50-60 ksecs while 4.09 needs about 35-40 ksecs. All on AMD Opteron 2218. Nice speedup!
This is a FPU stack overflow; one of these "this should never happen" errors (if the compiler is working correctly).
At least the floating-point exception generation & handling is working.
Something that worries me, though, is the message "Obtained 0 stack frames for this thread", which means that this doesn't give us much of a clue where precisely the error happened (and thus why). Maybe the main stack (or stack pointer) was corrupted, too.
Something that worries me, though, is the message "Obtained 0 stack frames for this thread", which means that this doesn't give us much of a clue where precisely the error happened (and thus why). Maybe the main stack (or stack pointer) was corrupted, too.
Is the machine overclocked or was is a hot day?
Hummm ... machine is not overclocked and it's always a bit hot in this office (25-28 degrees C). BTW, it got another error: http://einsteinathome.org/task/87436641
A long shot: this machine runs Linux x86_64, BOINC x86_64 and i686 Einstein. Could this smell like a call for trouble?
Something that worries me, though, is the message "Obtained 0 stack frames for this thread", which means that this doesn't give us much of a clue where precisely the error happened (and thus why). Maybe the main stack (or stack pointer) was corrupted, too.
Is the machine overclocked or was is a hot day?
Hummm ... machine is not overclocked and it's always a bit hot in this office (25-28 degrees C). BTW, it got another error: http://einsteinathome.org/task/87436641
A long shot: this machine runs Linux x86_64, BOINC x86_64 and i686 Einstein. Could this smell like a call for trouble?
My expectation was that in case of getting a signal the exit code would match the signal (here: 8). However it seems that here an FPE results in an exit status 22, which might be confusing.
Again backtrace() seems to be unable to get a useful stack dump. The reason for this might indeed be the 64Bit system. I'll take a look.
I don't see this as likely explanation in my case. First of all, this box runs quite stable and doesn't have habit of trashing WUs just like that - in none of projects it participates in (SAH and Rosetta since BOINC x86_64, previously also CPDN). Actually I can't recall any trashed WUs for S5R2 nor for S5R3 4.02, it somehiw started with 4.09 ...
If it was due to some configuration mistake, it'd quite likely trash all WUs alike. Secondly, I'm not driving this machine out of any specification. Indeed the environmental temperature is slightly high in the office, but it's constant (aircons all over the place) and didn't cause any trouble until now.
Maybe the difference in WU's to explain why 4.09 took longer?
Yes, the one you crunched with 4.02 gave only 150 credits, the 4.09 result 221 credits. So thats a very nice speedup you got there, close to 50% more credits in less than 10% more CPU time.
It returned the first result
)
It returned the first result without error, but it hasn't validated yet. It's about halfway through its second 4.09 result, so we'll see which one validates first.
I've encountered one faulty
)
I've encountered one faulty run: http://einsteinathome.org/task/87453466.
I can't figure out the stderr, but looks sexy though ;)
[edit]I like the pace of the beta app though. Roughly the same WUs with 4.02 take 50-60 ksecs while 4.09 needs about 35-40 ksecs. All on AMD Opteron 2218. Nice speedup!
Metod ...
4.09 works well on my AMD X2
)
4.09 works well on my AMD X2 3800+, crunching times dropped from cca 23.5 to 16 hours
Nice improvement!
H99
RE: I've encountered one
)
Thanks!
This is a FPU stack overflow; one of these "this should never happen" errors (if the compiler is working correctly).
At least the floating-point exception generation & handling is working.
Something that worries me, though, is the message "Obtained 0 stack frames for this thread", which means that this doesn't give us much of a clue where precisely the error happened (and thus why). Maybe the main stack (or stack pointer) was corrupted, too.
Is the machine overclocked or was is a hot day?
BM
BM
RE: Something that worries
)
Hummm ... machine is not overclocked and it's always a bit hot in this office (25-28 degrees C). BTW, it got another error: http://einsteinathome.org/task/87436641
A long shot: this machine runs Linux x86_64, BOINC x86_64 and i686 Einstein. Could this smell like a call for trouble?
Metod ...
RE: RE: Something that
)
Exit Code 22 explained.
My expectation was that in
)
My expectation was that in case of getting a signal the exit code would match the signal (here: 8). However it seems that here an FPE results in an exit status 22, which might be confusing.
Again backtrace() seems to be unable to get a useful stack dump. The reason for this might indeed be the 64Bit system. I'll take a look.
BM
BM
RE: Exit Code 22 explained.
)
I don't see this as likely explanation in my case. First of all, this box runs quite stable and doesn't have habit of trashing WUs just like that - in none of projects it participates in (SAH and Rosetta since BOINC x86_64, previously also CPDN). Actually I can't recall any trashed WUs for S5R2 nor for S5R3 4.02, it somehiw started with 4.09 ...
If it was due to some configuration mistake, it'd quite likely trash all WUs alike. Secondly, I'm not driving this machine out of any specification. Indeed the environmental temperature is slightly high in the office, but it's constant (aircons all over the place) and didn't cause any trouble until now.
Metod ...
same box (sempron 3100+,
)
same box (sempron 3100+, 64bit linux):
h1_0093.00_S5R2__7_S5R3a - v4.02 - 41,615.41
h1_0472.05_S5R2__107_S5R3a - v4.09 - 45,367.65
Maybe the difference in WU's to explain why 4.09 took longer?
RE: Maybe the difference
)
Yes, the one you crunched with 4.02 gave only 150 credits, the 4.09 result 221 credits. So thats a very nice speedup you got there, close to 50% more credits in less than 10% more CPU time.
Team Philippines