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.
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.
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.
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.
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
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.
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...
* 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.
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.
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
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'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]
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.
archae86
)
archae86 wrote:
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
RE: I had a look at the
)
Agreed. Thanks.
Those correspond in time to the BOINC level error messages I summarized as:
RE: RE: I had a look at
)
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
RE: This is really
)
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.
RE: Could you run a
)
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.
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?
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
RE: I've decided I'm going
)
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...
RE: RE: I've decided I'm
)
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.