Windows S5R4 SSE2 power App 6.05 available

hotze33
hotze33
Joined: 10 Nov 04
Posts: 100
Credit: 368387400
RAC: 1355

I have noticed quite a

I have noticed quite a difference in the speedup between the conroe and the penryn architecture on intel cpus.
(fastest result so far)
Q6600 @ 3.6GHz
einstein 6.04 ca. 22000s
einstein 6.05 ca. 19200s
->speedup 14%

E8400 @ 4GHz
einstein 6.04 ca. 19500s
einstein 6.05 ca. 15400s (wait for wingman)
->speedup 26%

Yes, I know it´s to early to make a conclusion, but did somebody else have the same amount of increase on penryn cpus?

edit: now I have some new results for the q6600 in the 17800s and hence the same type of speed increase. I haven´t realized, that the linux app was this much faster than the win app.
Keep up the good work.

Holmis
Joined: 4 Jan 05
Posts: 1118
Credit: 1055935564
RAC: 0

archae86

Message 86591 in response to message 86578

archae86 wrote:

Quote:

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

...

I had a look at the task details and found what I believe to be a problem with renaming the temporary checkpoint file, after that the task restarted from the beginning. I think the time before and after the error is added and can explain why these tasks took longer than usual to complete.

Here's one of them, about half way down the page it restarts.

/Holmis

archae86
archae86
Joined: 6 Dec 05
Posts: 3145
Credit: 7024574931
RAC: 1810459

RE: I had a look at the

Message 86592 in response to message 86591

Quote:

I had a look at the task details and found what I believe to be a problem with renaming the temporary checkpoint file, after that the task restarted from the beginning. I think the time before and after the error is added and can explain why these tasks took longer than usual to complete.

Here's one of them, about half way down the page it restarts.

/Holmis

Agreed. Thanks.
Those correspond in time to the BOINC level error messages I summarized as:

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


Bernd Machenschalk
Bernd Machenschalk
Moderator
Administrator
Joined: 15 Oct 04
Posts: 4267
Credit: 244931831
RAC: 16380

RE: RE: I had a look at

Message 86593 in response to message 86592

Quote:
Quote:

I had a look at the task details and found what I believe to be a problem with renaming the temporary checkpoint file, after that the task restarted from the beginning. I think the time before and after the error is added and can explain why these tasks took longer than usual to complete.

Here's one of them, about half way down the page it restarts.

/Holmis

Agreed. Thanks.
Those correspond in time to the BOINC level error messages I summarized as:
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

This is really surprising for a number of reasons

* The checkpoint is written successfully a lot of times and fails only occasionally, it looks like a race condition or similar - was there much disk activity from other programs (virus scanners, indexers) at the time of the errors?
* The program never fails to write the checkpoint to a temporary file, it just couldn't be renamed then to overwrite the older checkpoint a few times
* In case the new temporary file couldn't be renamed, at least the old file should still be there which, however, the App clearly couldn't find on restart.

This isn't a problem in our code, it could, however, be a problem in the BOINC library, or how it is compiled now.

Could you run a filesystem check on the partition where the BOINC directory is located? Just to be sure...

BM

BM

archae86
archae86
Joined: 6 Dec 05
Posts: 3145
Credit: 7024574931
RAC: 1810459

RE: This is really

Message 86594 in response to message 86593

Quote:

This is really surprising for a number of reasons

* The checkpoint is written successfully a lot of times and fails only occasionally, it looks like a race condition or similar - was there much disk activity from other programs (virus scanners, indexers) at the time of the errors?
* The program never fails to write the checkpoint to a temporary file, it just couldn't be renamed then to overwrite the older checkpoint a few times
* In case the new temporary file couldn't be renamed, at least the old file should still be there which, however, the App clearly couldn't find on restart.

This isn't a problem in our code, it could, however, be a problem in the BOINC library, or how it is compiled now.

Could you run a filesystem check on the partition where the BOINC directory is located? Just to be sure...

BM

it is perfectly clear that the state of the system when I woke up and used it about 6:30 AM that morning was profoundly abnormal. I have a pretty standard litany of visiting various websites and checking various things, mostly using the browser, and all of them were incredibly slow. As I have mentioned before, a backup procedures which I run every night using the commandline utility XXCOPY had made far less progressthan normal when I woke up and looked at the system. I assume all three of these issues (BOINC file rename problem, slow browser response, slow progress of backup copying) were related to the same root cause, but I don't have much of an idea of what the root cause was.

One other oddity happened a few hours later, which I hope is unrelated. My ISP, Comcast, sent me a message saying that spam had been sent out from one of my computers. I immediately ran a full virus scan on this particular host and found nothing at all. The virus scanner I use (Eset's NOD32) has a pretty good reputation, so I have good hope that I am not infected with a conventional virus. But perhaps if someone has somehow Zomba flied my computer in an unconventional way, the affected period may have been a burst of activity. Of course, even if Comcast is right, it may have been one of my other four systems which was the culprit--but if so it was not likely related to the subject of these posts.

I don't know how to do a filesystem integrity check on a specific portion (can anyone suggest a third-part tool good for NTFS volumes under Windows XP?), so I'll just run what Windows XP offers me. As its built in error checker requires a reboot before operation if any files are open on the volume, and my BOINC files are on my boot volume, I'll only be able to report any findings after reboot, so I'll send this message first.

archae86
archae86
Joined: 6 Dec 05
Posts: 3145
Credit: 7024574931
RAC: 1810459

RE: Could you run a

Message 86595 in response to message 86593

Quote:
Could you run a filesystem check on the partition where the BOINC directory is located? Just to be sure...


I did the WinXP thing available (click on the drive, go to "Tools" and ask for checking on next reboot). It did not report any problems.

My one guess, rather vague, is that something about the XXcopy copying process I use for backup puts some sort of "lock" on a file, which then made it unavailable for renaming by BOINC. How this degenerated into a multi-hour huge slowdown is mysterious to me. The one thing I can do, is to use an exclusion facility available to me in XXcopy to exclude copying of the BOINC directory. If my conflict guess has some slight coincidence with the truth, that should avoid the problem.

And I do doubt this has to do with the new ap. The episode does not, however, seem to have happened in the past, which was the reason to bring up the matter in this thread, just in case others saw the same thing, for the first time.

Novasen169
Novasen169
Joined: 14 May 06
Posts: 43
Credit: 2767204
RAC: 0

yay gave me a ~20% speedup

yay gave me a ~20% speedup :)

Any chance of a sse3 or higher application will be written soon? or won't that be useful?

ulenz
ulenz
Joined: 22 Jan 05
Posts: 27
Credit: 17897764
RAC: 0

I followed the installation

I followed the installation instructions of Bikeman in posting 89790. Everything works fine. The first uploads using version 605 and the "anonymous platform" were successful. Good work, guys!

Intel Q9300 Quadcore, 2500 Mhz, 4096 MB RAM, GeForce 9800 GT, Vista Ultimate 64-bit, Ubuntu 10.10 64 bit

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

RE: I've decided I'm going

Message 86598 in response to message 86577

Quote:

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.

Just a rough guess, considering the frequencies being processed are different, but the claim is the same, I think that the Linux app still has around a 6-10% advantage...at least with AMD. I'm not as positive about that guess as I was about the difference between the Linux app and the Windows 6.04 app... IOW, I could be mistaken... Not enough data, IMO...

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

RE: RE: I've decided I'm

Message 86599 in response to message 86598

Quote:
Quote:

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.

Just a rough guess, considering the frequencies being processed are different, but the claim is the same, I think that the Linux app still has around a 6-10% advantage...at least with AMD. I'm not as positive about that guess as I was about the difference between the Linux app and the Windows 6.04 app... IOW, I could be mistaken... Not enough data, IMO...

I think the jury is still out on this one...need to try and run thru a full cycle on this data pack as best as possible.

It DOES seem to be marginally slower than Linux, but time will tell.

[edit]I'm running SETI and E@H at a 50-50 resource level. It seems to be fairly steady at each project using one cpu a piece.

Later on I might try running E@H only or S@H only and log some times on them that way to judge L1/L2 cache conflicts (AMD doesn't have a whole lot of either).[/edit]

Seti Classic Final Total: 11446 WU.

Comment viewing options

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