Windows S5R4 SSE2 power App 6.05 available

archae86
archae86
Joined: 6 Dec 05
Posts: 3161
Credit: 7277085050
RAC: 1947899

RE: Single CPU Intel P4

Message 86570 in response to message 86569

Quote:
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.

Bernd Machenschalk
Bernd Machenschalk
Moderator
Administrator
Joined: 15 Oct 04
Posts: 4332
Credit: 251712077
RAC: 35326

RE: Since SETI doesn't zip

Message 86571 in response to message 86567

Quote:
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

BM

Jord
Joined: 26 Jan 05
Posts: 2952
Credit: 5893653
RAC: 3

RE: Oh, and turning on HT

Message 86572 in response to message 86570

Quote:
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.

Brian Silvers
Brian Silvers
Joined: 26 Aug 05
Posts: 772
Credit: 282700
RAC: 0

RE: RE: Since SETI

Message 86573 in response to message 86571

Quote:
Quote:
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...)

MarkJ
MarkJ
Joined: 28 Feb 08
Posts: 437
Credit: 139002861
RAC: 0

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.

Bikeman (Heinz-Bernd Eggenstein)
Bikeman (Heinz-...
Moderator
Joined: 28 Aug 06
Posts: 3522
Credit: 762908933
RAC: 1051690

RE: Since I installed the

Message 86575 in response to message 86574

Quote:

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.

So nothing to worry about
CU
Bikeman

Bikeman (Heinz-Bernd Eggenstein)
Bikeman (Heinz-...
Moderator
Joined: 28 Aug 06
Posts: 3522
Credit: 762908933
RAC: 1051690

RE: ... It may be the case

Message 86576 in response to message 86568

Quote:
... 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.

CU
Bikeman

RandyC
RandyC
Joined: 18 Jan 05
Posts: 6696
Credit: 111139797
RAC: 0

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.

archae86
archae86
Joined: 6 Dec 05
Posts: 3161
Credit: 7277085050
RAC: 1947899

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:

_freq_ seq _CPU_
541.95	181	30960
541.95	180	30563
541.95	179	30876
541.95	177	30186
541.95	176	30071
541.95	175	29709
541.95	174	29272
541.95	172	28926
541.95	171	28646
541.95	170	28600
541.95	169	55204
541.95	167	49156
541.95	166	39407
541.95	165	37621
541.95	163	27246

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.

Mike Hewson
Mike Hewson
Moderator
Joined: 1 Dec 05
Posts: 6591
Credit: 325233344
RAC: 210452

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

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.