On my Banias Pentium M the first unit finished (changed to new beta app at 49% crunched). time is slightly higher but still within the usual variation of runtime.
So 12% longer time observed, and this was still a mixed-application one. I'll revise my slowdown estimate to roughly 15% extra time, for Core 2 processors on Windows XP. I should have a much better estimate by tomorrow, when several unmixed results will be in from each of two hosts.
Now I have two unmixed results from my Quad Q6600 and three from my Duo E6600.
All five of these results are in a very tight cluster of increased CPU time required compared to closely comparable results computed on the same hosts using the production 4.33 ap.
The slow-down on these hosts, which I'll predict is going to be typical for Core 2 hosts running Win XP, is right about 14%.
In seven mixed-application and five all-new results returned so far, I've got no self-detected errors, and have successful validation for five on the E6600 and two on the Q6600.
Bernd, is there anything specific we can do to provide you useful feedback on this beta? With the exception of errors I generated in switching from beta to production 4.33, my machines have not been generating errors for weeks--since I got the CPU voltages up high enough to fully handle my overclock (and since your code releases removed some of the more common code-related problems)
If you'd like to see the error-trap code operate, and possibly are interested in what may be a typical signature for a Core 2 part running this application just slightly faster than its capability, I could slightly drop the CPU voltage on my machines to a level that will probably error within a few hours, but not right away.
If that is not interesting to you, I think these two machines may have done their bit for the beta, and might best return to the stock ap. I'll leave my Pentium III Win98 Coppermine relic and my Pentium M Banias WinXP laptop on the beta until they've each completed a pure beta result.
The first result is in from my Xeon, and is showing the slowdown too.
With 99% of the crunching done by 4.38, the slowdown from the previous result was about 12.9%. But I was having difficulty downloading work from SETI for most of that time, so a fairer comparison might be with the bottom of the trough, which makes it about 14.1%, matching archae86.
The machine is offline for the moment while I do some beta testing for SETI optimisers, but I'll come back and finish off the 'pure' 4.38 later.
edit:
I am runing a Sempron 3000+, win xp, BOINC 5.8.8
I think I was unpacking a dvd with winrar around this time. I checked the disk space on c: before I started, so hopefully it shouldn’t be lack of disk space that was the problem.
Then you're really interested in a subject, there is no way to avoid it. You have to read the Manual.
Hummm... some juicy looking stuff at the end of your stderr.txt:
[CRITICAL]: non-finite Dphi_alpha: -1.#IND00e+000, spind#:0, fkdot:5.063516e+002, Tas:-1.#IND00e+000, inv_fact[s]:1.000000e+000, inv_fact[s+1]:1.000000e+000, phi_alpha:-1.#IND00e+000. DT_al:1.115666e+007
XLAL Error - LocalXLALComputeFaFb (LocalComputeFstat.c:516): Input domain error
LocalXALComputeFaFb() failed
Level 0: $Id: HierarchicalSearch.c,v 1.179 2007/08/22 11:16:04 badri Exp $
Function call `COMPUTEFSTATFREQBAND ( &status, fstatVector.data + k, &thisPoint, stackMultiSFT.data[k], stackMultiNoiseWeights.data[k], stackMultiDetStates.data[k], &CFparams)' failed.
file HierarchicalSearch.c, line 1091
2007-08-25 16:45:00.5781 [normal]:
Level 1: $Id: LocalComputeFstat.c,v 1.49 2007/08/21 14:25:26 bema Exp $
2007-08-25 16:45:00.5781 [normal]: Status code -1: Recursive error
2007-08-25 16:45:00.5781 [normal]: function LocalComputeFStatFreqBand, file LocalComputeFstat.c, line 210
2007-08-25 16:45:00.5781 [normal]:
Level 2: $Id: LocalComputeFstat.c,v 1.49 2007/08/21 14:25:26 bema Exp $
2007-08-25 16:45:00.5781 [normal]: Status code 5: XLAL function call failed
2007-08-25 16:45:00.5781 [normal]: function LocalComputeFStat, file LocalComputeFstat.c, line 345
2007-08-25 16:45:00.5781 [CRITICAL]: BOINC_LAL_ErrHand(): now calling boinc_finish()
Interesting: The initial Wingman crashed as well, but in a different phase of the computation. Maybe there's something wrong with the input data. Bernd will be interested in this one, I guess.
Any problem with 4.38 more
)
Any problem with 4.38 more then the early report that is slower tthen 4.33. This because when I go to the beta page it´s still show 4.33 for win.
RE: Any problem with 4.38
)
The whole beta-test web page was reverted ( the Linux link also points to the previous beta.).
Massive bending of time-space causing a time travel of the server ???
CU
H-BE
No idea what happened, but
)
No idea what happened, but currently it looks like the one I posted (w. Apps 4.37 and 4.38) ...
BM
BM
RE: No idea what happened,
)
Just a small glitch, now back to normal.
CU
H-B
On my Banias Pentium M the
)
On my Banias Pentium M the first unit finished (changed to new beta app at 49% crunched). time is slightly higher but still within the usual variation of runtime.
CU
H-BE
RE: So 12% longer time
)
Now I have two unmixed results from my Quad Q6600 and three from my Duo E6600.
All five of these results are in a very tight cluster of increased CPU time required compared to closely comparable results computed on the same hosts using the production 4.33 ap.
The slow-down on these hosts, which I'll predict is going to be typical for Core 2 hosts running Win XP, is right about 14%.
In seven mixed-application and five all-new results returned so far, I've got no self-detected errors, and have successful validation for five on the E6600 and two on the Q6600.
Bernd, is there anything specific we can do to provide you useful feedback on this beta? With the exception of errors I generated in switching from beta to production 4.33, my machines have not been generating errors for weeks--since I got the CPU voltages up high enough to fully handle my overclock (and since your code releases removed some of the more common code-related problems)
If you'd like to see the error-trap code operate, and possibly are interested in what may be a typical signature for a Core 2 part running this application just slightly faster than its capability, I could slightly drop the CPU voltage on my machines to a level that will probably error within a few hours, but not right away.
If that is not interesting to you, I think these two machines may have done their bit for the beta, and might best return to the stock ap. I'll leave my Pentium III Win98 Coppermine relic and my Pentium M Banias WinXP laptop on the beta until they've each completed a pure beta result.
The first result is in from
)
The first result is in from my Xeon, and is showing the slowdown too.
With 99% of the crunching done by 4.38, the slowdown from the previous result was about 12.9%. But I was having difficulty downloading work from SETI for most of that time, so a fairer comparison might be with the bottom of the trough, which makes it about 14.1%, matching archae86.
The machine is offline for the moment while I do some beta testing for SETI optimisers, but I'll come back and finish off the 'pure' 4.38 later.
25/08/2007
)
25/08/2007 16:45:04|Einstein@Home|Reason: Unrecoverable error for result h1_0506.25_S5R2__105_S5R2c_1 ( - exit code 99 (0x63))
http://einsteinathome.org/task/86540103
edit:
I am runing a Sempron 3000+, win xp, BOINC 5.8.8
I think I was unpacking a dvd with winrar around this time. I checked the disk space on c: before I started, so hopefully it shouldn’t be lack of disk space that was the problem.
Then you're really interested in a subject, there is no way to avoid it. You have to read the Manual.
RE: 25/08/2007
)
Hummm... some juicy looking stuff at the end of your stderr.txt:
[CRITICAL]: non-finite Dphi_alpha: -1.#IND00e+000, spind#:0, fkdot:5.063516e+002, Tas:-1.#IND00e+000, inv_fact[s]:1.000000e+000, inv_fact[s+1]:1.000000e+000, phi_alpha:-1.#IND00e+000. DT_al:1.115666e+007
XLAL Error - LocalXLALComputeFaFb (LocalComputeFstat.c:516): Input domain error
LocalXALComputeFaFb() failed
Level 0: $Id: HierarchicalSearch.c,v 1.179 2007/08/22 11:16:04 badri Exp $
Function call `COMPUTEFSTATFREQBAND ( &status, fstatVector.data + k, &thisPoint, stackMultiSFT.data[k], stackMultiNoiseWeights.data[k], stackMultiDetStates.data[k], &CFparams)' failed.
file HierarchicalSearch.c, line 1091
2007-08-25 16:45:00.5781 [normal]:
Level 1: $Id: LocalComputeFstat.c,v 1.49 2007/08/21 14:25:26 bema Exp $
2007-08-25 16:45:00.5781 [normal]: Status code -1: Recursive error
2007-08-25 16:45:00.5781 [normal]: function LocalComputeFStatFreqBand, file LocalComputeFstat.c, line 210
2007-08-25 16:45:00.5781 [normal]:
Level 2: $Id: LocalComputeFstat.c,v 1.49 2007/08/21 14:25:26 bema Exp $
2007-08-25 16:45:00.5781 [normal]: Status code 5: XLAL function call failed
2007-08-25 16:45:00.5781 [normal]: function LocalComputeFStat, file LocalComputeFstat.c, line 345
2007-08-25 16:45:00.5781 [CRITICAL]: BOINC_LAL_ErrHand(): now calling boinc_finish()
Interesting: The initial
)
Interesting: The initial Wingman crashed as well, but in a different phase of the computation. Maybe there's something wrong with the input data. Bernd will be interested in this one, I guess.
CU
H-B