Single CPU Intel P4 3.0GHz with Hyperthreading on, Windows XP Pro, 2GB RAM.
x86 Family 15 Model 2 Stepping 9
If I read my decoder ring correctly, that is a Northwood, or thereabouts.
I sincerely suggest that running any member of the Willamette line (Willamette, Northwood, Prescott, Cedar Mill) these days is unwise unless your particular need is space heating. The main Northwood virtue for computing is that it generally burns less power than Prescotts, but if space heating is your need, even that is not a virtue.
Oh, and turning on HT probably does enhance your total output, and also output per unit power, but it drives the reported CPU time way up, so if generating embarrassingly long execution times is your goal, that was a good configuration choice.
Since SETI doesn't zip the files, but Einstein does, my guess is that it's the science app whiich does the zipping.
That's right. For the next run S5R5 we're thinking of letting the BOINC Core Client do the compression (gzip) then. It would make the science App easier and possibly more reliable. However it only works with newer Core Clients (>= 5.8?), for older Clients this would be a penalty (bandwidth and storage) both for the Clients and our server. The current validator already can handle all three types (zip, gzip & plain text).
Oh, and turning on HT probably does enhance your total output, and also output per unit power, but it drives the reported CPU time way up, so if generating embarrassingly long execution times is your goal, that was a good configuration choice.
Actually, it doesn't seem to matter. The AMD beat the Intel hands down on Orbit as well; you know how long those tasks are. ;-)
As for heat, as i said earlier in this thread, if anything but Einstein runs, it's under 60C (55-57), but when Einstein does run (be it SSE or SSE2) add 4-5C. And that doesn't matter if I use HT or not (tested that as well). So if it's heat concerns (you have for me ;-)), I'll leave the HT on.
Since SETI doesn't zip the files, but Einstein does, my guess is that it's the science app whiich does the zipping.
That's right. For the next run S5R5 we're thinking of letting the BOINC Core Client do the compression (gzip) then. It would make the science App easier and possibly more reliable. However it only works with newer Core Clients (>= 5.8?), for older Clients this would be a penalty (bandwidth and storage) both for the Clients and our server. The current validator already can handle all three types (zip, gzip & plain text).
BM
Where I was going with my line of questioning was the feasibility of an "integrity check" on the zip file before deleting the result file, implemented either in the science app or through the BOINC components. Don't know what kind of overhead that might add, both on the server side and on the host side (disk space, slot folders, etc...)
Since I installed the 6.05 app on one machine I have noticed the following message in the results. It may mean nothing, but just in case it doesn't...
836, 837, 838, 839, c
840, 841, done. FPU status flags: COND_2 PRECISION
2008-10-11 02:24:39.7500 [normal]: done. calling boinc_finish(0).
called boinc_finish
The result in question is here. All the 6.05 app results have it and the recent 6.04 apps don't.
This is normal (you'll also find this in Linux and OS X results). The app prints a textual representation of the bitfield in the FPU status register. PRECISION means that the result that was computed last is not exact and is rounded to fit into a floating point register. This is normal, even 1 / 10 gives a result that has no exact binary representation as a floating point number. COND_2 is the outcome of the last FPU comparision function.
Things to worry about would be a status "STACK_FAULT" etc.
... It may be the case that the percentage improvement in the code which varies in amount of use between peak and valley is less than the improvement in the code which is used a nearly constant amount across the cycle. ...
Excellent observation, because now that you say it, it makes a lot of sense from the source code perspective. The new app was not only compiled with a different compiler (and with different optimization/codeset options), AFAIK it also includes the latest Akos inspired optimizations that were already part of the Linux and OS X builds, but are not yet in the Win stock app. These new optimizations concern the part of the code where improvements are most visible in WUs near the runtime minimum.
I've decided I'm going to convert my dual-boot Linux/XP Pro cruncher to run BOINC on the XP Pro side with the new power app.
The SETI AK-V8 opt app for Linux appears to run about 5% slower than the Windows version. Now that the E@H 6.05 power app is available, it'll give me a chance to see the relative performance of it vs the E@H Linux science app on an AMD X2 system. I suspect others may be interested as well. I'll be running 32-bit XP on it instead of 64-bit because that's what it's licensed for, even though it's capable of 64-bit.
The system I'm draining is this one. It should show up as this system once I've relocated BOINC to XP Pro.
I've had a very odd episode on my Q6600 WinXP host running 6.05. I actually doubt it is caused by the 6.05 ap, but report it as it is a major anomaly and I wish to encourage any other seeing such a thing to report it, just in case someone here can diagnose and help avoid repetition.
It appears that for a period of something approaching half a day that Einstein tasks computed useful results far more slowly than normal, reporting far longer CPU time than in trend.
As I had seen a previous oddity (a single faulty result zipping--causing a validation failure) on this host running 6.05, I took the precaution of rebooting yesterday--so the system had only been running a few hours since reboot when the anomaly began.
Here is a timeline, using local time (U.S. Mountain Daylight Time UTC-6)
11 October 06:54 reboot
Einstein sequence numbers resumed 181,180,179, 177 all of which eventually completed in normal time
7:01 the usual DLL initialization error on first attempted project communication after a reboot
18:07 startup of seq 170--the last "good" task before the bad patch
21:12 startup of seq 169--the first, and worst "bad task"
23:48 completion of seq 172--a good task
23:48 startup of seq 167--second bad task
12 October 02:30 completion of seq 171--a good task
02:30 startup of seq 166--third bad task
03:08 completion of seq 170--last good task before bad patch
03:08 startup of seq 165--fourth and last bad task
03:37 error message in BOINC about state file access and renaming
03:42 another
04:14 another
04:16 another
04:16 three Einstein tasks exit with DLL initialization error and restart (169, 167, 166)
06:12 all four running Einstein tasks exit with DLL initialization error and restart (169,167,166,165)
07:18 error message in BOINC about state file access and renaming
07:23 another
13:46 seq 167 complete (bad)
13:46 seq 164 startup (a good task)
13:51 seq 166 complete (bad task)
14:07 seq 169 complete (bad)
15:46 seq 165 complete (bad)[/code]
Some possible factors:
1. I rule out simple timing reporting error--clearly the start to finish elapsed times for the bad results are far longer than the norm (of about 8 hours)
2. I'm a newish user of Google Chrome, and I left a copy open overnight with about six tabs, three of which were displaying large pdf files--typically 100 pages, though mostly text
3. The apparent onset time range of perhaps 02:30 is an hour or so after the scheduled startup time of a nightly backup I run using XXCOPY. This nightly backup has been completing before I wake and check at about 06:45 recently, but today it was not far along at all--either it was slowed by the same issue, or it is an active participant--perhaps it and BOINC collided at the state files?
The general system performance when I used it in the 07:00 to 09:00 time range for normal web browsing was astonishingly bad. Yet Process Explorer did not reveal an obvious "hogging" task.
The only previous time I saw such a behavior (many hours of considerably slowed Einstein progress, with drastically longer than normal CPU time reports) I associated it with a web page open in Firefox, offering most of the available actual movie footage of Gandhi. That time Firefox did show as using substantial time in Process Explorer--but I did not see that symptom on any unexpected ap this time. This time, moreover, I did not actually quit the suspect pdf displays until hours after the anomaly was over.
RE: Single CPU Intel P4
)
x86 Family 15 Model 2 Stepping 9
If I read my decoder ring correctly, that is a Northwood, or thereabouts.
I sincerely suggest that running any member of the Willamette line (Willamette, Northwood, Prescott, Cedar Mill) these days is unwise unless your particular need is space heating. The main Northwood virtue for computing is that it generally burns less power than Prescotts, but if space heating is your need, even that is not a virtue.
Oh, and turning on HT probably does enhance your total output, and also output per unit power, but it drives the reported CPU time way up, so if generating embarrassingly long execution times is your goal, that was a good configuration choice.
RE: Since SETI doesn't zip
)
That's right. For the next run S5R5 we're thinking of letting the BOINC Core Client do the compression (gzip) then. It would make the science App easier and possibly more reliable. However it only works with newer Core Clients (>= 5.8?), for older Clients this would be a penalty (bandwidth and storage) both for the Clients and our server. The current validator already can handle all three types (zip, gzip & plain text).
BM
BM
RE: Oh, and turning on HT
)
Actually, it doesn't seem to matter. The AMD beat the Intel hands down on Orbit as well; you know how long those tasks are. ;-)
As for heat, as i said earlier in this thread, if anything but Einstein runs, it's under 60C (55-57), but when Einstein does run (be it SSE or SSE2) add 4-5C. And that doesn't matter if I use HT or not (tested that as well). So if it's heat concerns (you have for me ;-)), I'll leave the HT on.
RE: RE: Since SETI
)
Where I was going with my line of questioning was the feasibility of an "integrity check" on the zip file before deleting the result file, implemented either in the science app or through the BOINC components. Don't know what kind of overhead that might add, both on the server side and on the host side (disk space, slot folders, etc...)
Since I installed the 6.05
)
Since I installed the 6.05 app on one machine I have noticed the following message in the results. It may mean nothing, but just in case it doesn't...
836, 837, 838, 839, c
840, 841, done.
FPU status flags: COND_2 PRECISION
2008-10-11 02:24:39.7500 [normal]: done. calling boinc_finish(0).
called boinc_finish
The result in question is here. All the 6.05 app results have it and the recent 6.04 apps don't.
BOINC blog
RE: Since I installed the
)
This is normal (you'll also find this in Linux and OS X results). The app prints a textual representation of the bitfield in the FPU status register. PRECISION means that the result that was computed last is not exact and is rounded to fit into a floating point register. This is normal, even 1 / 10 gives a result that has no exact binary representation as a floating point number. COND_2 is the outcome of the last FPU comparision function.
Things to worry about would be a status "STACK_FAULT" etc.
So nothing to worry about
CU
Bikeman
RE: ... It may be the case
)
Excellent observation, because now that you say it, it makes a lot of sense from the source code perspective. The new app was not only compiled with a different compiler (and with different optimization/codeset options), AFAIK it also includes the latest Akos inspired optimizations that were already part of the Linux and OS X builds, but are not yet in the Win stock app. These new optimizations concern the part of the code where improvements are most visible in WUs near the runtime minimum.
CU
Bikeman
I've decided I'm going to
)
I've decided I'm going to convert my dual-boot Linux/XP Pro cruncher to run BOINC on the XP Pro side with the new power app.
The SETI AK-V8 opt app for Linux appears to run about 5% slower than the Windows version. Now that the E@H 6.05 power app is available, it'll give me a chance to see the relative performance of it vs the E@H Linux science app on an AMD X2 system. I suspect others may be interested as well. I'll be running 32-bit XP on it instead of 64-bit because that's what it's licensed for, even though it's capable of 64-bit.
The system I'm draining is this one. It should show up as this system once I've relocated BOINC to XP Pro.
Seti Classic Final Total: 11446 WU.
I've had a very odd episode
)
I've had a very odd episode on my Q6600 WinXP host running 6.05. I actually doubt it is caused by the 6.05 ap, but report it as it is a major anomaly and I wish to encourage any other seeing such a thing to report it, just in case someone here can diagnose and help avoid repetition.
It appears that for a period of something approaching half a day that Einstein tasks computed useful results far more slowly than normal, reporting far longer CPU time than in trend.
Here is some data showing the transient:
As I had seen a previous oddity (a single faulty result zipping--causing a validation failure) on this host running 6.05, I took the precaution of rebooting yesterday--so the system had only been running a few hours since reboot when the anomaly began.
Here is a timeline, using local time (U.S. Mountain Daylight Time UTC-6)
11 October 06:54 reboot
Einstein sequence numbers resumed 181,180,179, 177 all of which eventually completed in normal time
7:01 the usual DLL initialization error on first attempted project communication after a reboot
18:07 startup of seq 170--the last "good" task before the bad patch
21:12 startup of seq 169--the first, and worst "bad task"
23:48 completion of seq 172--a good task
23:48 startup of seq 167--second bad task
12 October 02:30 completion of seq 171--a good task
02:30 startup of seq 166--third bad task
03:08 completion of seq 170--last good task before bad patch
03:08 startup of seq 165--fourth and last bad task
03:37 error message in BOINC about state file access and renaming
03:42 another
04:14 another
04:16 another
04:16 three Einstein tasks exit with DLL initialization error and restart (169, 167, 166)
06:12 all four running Einstein tasks exit with DLL initialization error and restart (169,167,166,165)
07:18 error message in BOINC about state file access and renaming
07:23 another
13:46 seq 167 complete (bad)
13:46 seq 164 startup (a good task)
13:51 seq 166 complete (bad task)
14:07 seq 169 complete (bad)
15:46 seq 165 complete (bad)[/code]
Some possible factors:
1. I rule out simple timing reporting error--clearly the start to finish elapsed times for the bad results are far longer than the norm (of about 8 hours)
2. I'm a newish user of Google Chrome, and I left a copy open overnight with about six tabs, three of which were displaying large pdf files--typically 100 pages, though mostly text
3. The apparent onset time range of perhaps 02:30 is an hour or so after the scheduled startup time of a nightly backup I run using XXCOPY. This nightly backup has been completing before I wake and check at about 06:45 recently, but today it was not far along at all--either it was slowed by the same issue, or it is an active participant--perhaps it and BOINC collided at the state files?
The general system performance when I used it in the 07:00 to 09:00 time range for normal web browsing was astonishingly bad. Yet Process Explorer did not reveal an obvious "hogging" task.
The only previous time I saw such a behavior (many hours of considerably slowed Einstein progress, with drastically longer than normal CPU time reports) I associated it with a web page open in Firefox, offering most of the available actual movie footage of Gandhi. That time Firefox did show as using substantial time in Process Explorer--but I did not see that symptom on any unexpected ap this time. This time, moreover, I did not actually quit the suspect pdf displays until hours after the anomaly was over.
Hrrrmmmfff! FWIW - RR_7F
)
Hrrrmmmfff! FWIW - RR_7F refuses to comment/predict ( same either way, if 167/169 are in or out of the set ) on this 18/61.9 ~ 1/4 of a cycle.
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal