Is the problem the speed with which E@H validates wu, for linux, slower than windows? I noticed that I completed and reported Workunit 33627468 ~one (1) hr. before the WU was sent to the third computer, a windows box. My computer completed the wu second in time, about 19 hr. before third computer.
@Bernd: Is there hope, that the performance problem for AMD/Win systems gets fixed?
It definitely will. However my first quick shots addressing this (e.g. compiling the relevant code for Windows with the same compiler I used for Linux) didn't yield anything useful (i.e. linking in the above example) yet. I'll continue to work on this.
BM
Bernd,
If you haven't already seen it, take a look at this message I wrote recently. It documents the fact that the 4.21 linux app is at least 30% faster on PIII and AMD architectures, compared with the 4.17 Windows app. There appears to be very little difference between the two for early P4 although I've only tested this on one Williamette machine so far. I have no knowledge of what happens on more modern hardware, although Annika's experience seems to show that Core Duo (Yonah) may also benefit.
It is time consuming to change over a large number of boxes from Windows to Linux so I'd be silly to do that if you were about to release a new Windows app that cures the current difference for PIII/AMD. Do you have any thoughts on the possible timeframe for a new Windows app for trial? If a new version is not going to happen anytime soon, I'll start converting to Linux, machines that will benefit right now.
It is time consuming to change over a large number of boxes from Windows to Linux so I'd be silly to do that if you were about to release a new Windows app that cures the current difference for PIII/AMD. Do you have any thoughts on the possible timeframe for a new Windows app for trial? If a new version is not going to happen anytime soon, I'll start converting to Linux, machines that will benefit right now.
While not particularly practical, a quick band-aid would be to run a Live-CD and mount a partition (as long as it's not NTFS) for BOINC. If you are using the NTFS file system you could try USB keys for BOINC.
Like I said its not really all that realistic, but it at least doesn't involve wiping all your Windows installs.
There are 10^11 stars in the galaxy. That used to be a huge number. But it's only a hundred billion. It's less than the national deficit! We used to call them astronomical numbers. Now we should call them economical numbers. - Richard Feynman
While not particularly practical, a quick band-aid would be to run a Live-CD and mount a partition (as long as it's not NTFS) for BOINC. If you are using the NTFS file system you could try USB keys for BOINC.
Like I said its not really all that realistic, but it at least doesn't involve wiping all your Windows installs.
Thanks for the input, all comments are appreciated.
The vast bulk of my boxes are doing nothing but crunch 24/7. Virtually all are WinXP/NTFS with nothing much else but BOINC installed. I have no problem blowing away the current setup. During the Linux install from a liveCD, I've been either installing in an available separate partition or shrinking the Windows partition to create enough space. All machines so far converted are thus dual booting which I think is good insurance against future situations where one or other OS has a (hopefully temporary) superiority. The only real problem is the time it will take to do this conversion for all machines in the fleet.
Well, by the looks of your RAC I'd guess you've got between 50-100 boxes to install... I wish you the best of luck! :-)
Dual booting really is the best way to go, you get the best of both worlds. There have been a few times I've switched OS's depending on which app is faster.
And remember, when you feel like pulling out your hair it's time for sleep!
There are 10^11 stars in the galaxy. That used to be a huge number. But it's only a hundred billion. It's less than the national deficit! We used to call them astronomical numbers. Now we should call them economical numbers. - Richard Feynman
@Bernd: Is there hope, that the performance problem for AMD/Win systems gets fixed?
It definitely will. However my first quick shots addressing this (e.g. compiling the relevant code for Windows with the same compiler I used for Linux) didn't yield anything useful (i.e. linking in the above example) yet. I'll continue to work on this.
BM
@Bernd : I think Annika, Michael and myself have found the reason for the AMD/Windows weakness, please have a look at our discussion in the "Information on new S5 workunits" thread. The problem is located in the rather dubious way the math library performs CPU identification and a rather slow non-SSE2 codepath implementation of modf, which explains why compiling the science source code with a different compiler didn't help.
Any plans for a new Windows app? Even with CPU identification rectified, the older AMDs (XPs) and Pentium I, II and IIIs would still be significantly slower under Windows than under Linux as the code in the library's non-SSE2 codepath is rather slow compared to the Linux variant. So an alternative lib would be preferable to a mere patch of the CPU detection routine (which might be illegal under teh EULA for the lib anyway).
Another 4.21 WU failed. Seems to finish completely but project sends to third machine on return of result by linux machine. I can send all of the points if needed or of interest.
Result ID 84449641
Name h1_0397.90_S5R2__147_S5R2c_1
Workunit 33747657
Created 20 May 2007 4:59:19 UTC
Sent 20 May 2007 6:04:13 UTC
Received 27 May 2007 20:13:37 UTC
Server state Over
Outcome Success
Client state Done
Exit status 0 (0x0)
Computer ID 912076
Report deadline 3 Jun 2007 6:04:13 UTC
CPU time 167158.258735
stderr out
5.8.16
.
.
.
38892, 38893, 38894, 38895, 38896, c
done.
zip diagnostic: processing arguments
zip diagnostic: stating marked entries
zip diagnostic: stating new entries
zip diagnostic: fcount=1
zip diagnostic: new file=h1_0397.90_S5R2__147_S5R2c_1_0
zip diagnostic: opening zip file and creating temporary zip file
zip diagnostic: zipping up new entries, if any
zip diagnostic: fcount=1
last_lit 4096, last_dist 2233, in 26393, out ~7925(70%)
last_lit 8192, last_dist 4762, in 59844, out ~16712(73%)
last_lit 12288, last_dist 7256, in 93160, out ~25439(73%)
last_lit 16384, last_dist 9805, in 126857, out ~34273(73%)
last_lit 20480, last_dist 12399, in 161171, out ~43183(74%)
last_lit 24576, last_dist 14961, in 194883, out ~52041(74%)
last_lit 28672, last_dist 17549, in 229292, out ~60934(74%)
opt 54841(438722) stat 69339(554706) stored 262875 lit 32767 dist 20061
last_lit 4096, last_dist 2542, in 33571, out ~8804(74%)
last_lit 8192, last_dist 5058, in 67164, out ~17565(74%)
last_lit 12288, last_dist 7592, in 100776, out ~26374(74%)
last_lit 16384, last_dist 10129, in 134188, out ~35176(74%)
last_lit 20480, last_dist 12672, in 168101, out ~43974(74%)
last_lit 24576, last_dist 15175, in 201828, out ~52713(74%)
last_lit 28672, last_dist 17770, in 235838, out ~61607(74%)
opt 55441(443520) stat 69983(559860) stored 269148 lit 32767 dist 20261
opt 1973(15778) stat 2450(19596) stored 9572 lit 1135 dist 714
zip diagnostic: writing central directory
zip diagnostic: writing end of central directory
zip diagnostic: replacing old zip file with new zip file
]]>
Validate state Invalid
Claimed credit 308.842592592593
Granted credit 0
application version 4.21
Check the Problems and Bug Reports. It occurs when a WU is sent to two hosts with different OS's (XP:Linux, Vista:OSX and so on), the results may vary slightly so a third host is sent the WU for confirmation. Which either of the first two OS's is most similar to the thirds will get validation.
This is a known bug, and I can only assume the devs are working hard to sort this out.
There are 10^11 stars in the galaxy. That used to be a huge number. But it's only a hundred billion. It's less than the national deficit! We used to call them astronomical numbers. Now we should call them economical numbers. - Richard Feynman
Is the problem the speed with
)
Is the problem the speed with which E@H validates wu, for linux, slower than windows? I noticed that I completed and reported Workunit 33627468 ~one (1) hr. before the WU was sent to the third computer, a windows box. My computer completed the wu second in time, about 19 hr. before third computer.
RE: RE: @Bernd: Is there
)
Bernd,
If you haven't already seen it, take a look at this message I wrote recently. It documents the fact that the 4.21 linux app is at least 30% faster on PIII and AMD architectures, compared with the 4.17 Windows app. There appears to be very little difference between the two for early P4 although I've only tested this on one Williamette machine so far. I have no knowledge of what happens on more modern hardware, although Annika's experience seems to show that Core Duo (Yonah) may also benefit.
It is time consuming to change over a large number of boxes from Windows to Linux so I'd be silly to do that if you were about to release a new Windows app that cures the current difference for PIII/AMD. Do you have any thoughts on the possible timeframe for a new Windows app for trial? If a new version is not going to happen anytime soon, I'll start converting to Linux, machines that will benefit right now.
Cheers,
Gary.
RE: It is time consuming to
)
While not particularly practical, a quick band-aid would be to run a Live-CD and mount a partition (as long as it's not NTFS) for BOINC. If you are using the NTFS file system you could try USB keys for BOINC.
Like I said its not really all that realistic, but it at least doesn't involve wiping all your Windows installs.
There are 10^11 stars in the galaxy. That used to be a huge number. But it's only a hundred billion. It's less than the national deficit! We used to call them astronomical numbers. Now we should call them economical numbers. - Richard Feynman
RE: While not particularly
)
Thanks for the input, all comments are appreciated.
The vast bulk of my boxes are doing nothing but crunch 24/7. Virtually all are WinXP/NTFS with nothing much else but BOINC installed. I have no problem blowing away the current setup. During the Linux install from a liveCD, I've been either installing in an available separate partition or shrinking the Windows partition to create enough space. All machines so far converted are thus dual booting which I think is good insurance against future situations where one or other OS has a (hopefully temporary) superiority. The only real problem is the time it will take to do this conversion for all machines in the fleet.
Cheers,
Gary.
Well, by the looks of your
)
Well, by the looks of your RAC I'd guess you've got between 50-100 boxes to install... I wish you the best of luck! :-)
Dual booting really is the best way to go, you get the best of both worlds. There have been a few times I've switched OS's depending on which app is faster.
And remember, when you feel like pulling out your hair it's time for sleep!
There are 10^11 stars in the galaxy. That used to be a huge number. But it's only a hundred billion. It's less than the national deficit! We used to call them astronomical numbers. Now we should call them economical numbers. - Richard Feynman
RE: RE: @Bernd: Is there
)
@Bernd : I think Annika, Michael and myself have found the reason for the AMD/Windows weakness, please have a look at our discussion in the "Information on new S5 workunits" thread. The problem is located in the rather dubious way the math library performs CPU identification and a rather slow non-SSE2 codepath implementation of modf, which explains why compiling the science source code with a different compiler didn't help.
Any plans for a new Windows app? Even with CPU identification rectified, the older AMDs (XPs) and Pentium I, II and IIIs would still be significantly slower under Windows than under Linux as the code in the library's non-SSE2 codepath is rather slow compared to the Linux variant. So an alternative lib would be preferable to a mere patch of the CPU detection routine (which might be illegal under teh EULA for the lib anyway).
CU
BRM
Another 4.21 WU failed. Seems
)
Another 4.21 WU failed. Seems to finish completely but project sends to third machine on return of result by linux machine. I can send all of the points if needed or of interest.
Result ID 84449641
Name h1_0397.90_S5R2__147_S5R2c_1
Workunit 33747657
Created 20 May 2007 4:59:19 UTC
Sent 20 May 2007 6:04:13 UTC
Received 27 May 2007 20:13:37 UTC
Server state Over
Outcome Success
Client state Done
Exit status 0 (0x0)
Computer ID 912076
Report deadline 3 Jun 2007 6:04:13 UTC
CPU time 167158.258735
stderr out
5.8.16
.
.
.
38892, 38893, 38894, 38895, 38896, c
done.
zip diagnostic: processing arguments
zip diagnostic: stating marked entries
zip diagnostic: stating new entries
zip diagnostic: fcount=1
zip diagnostic: new file=h1_0397.90_S5R2__147_S5R2c_1_0
zip diagnostic: opening zip file and creating temporary zip file
zip diagnostic: zipping up new entries, if any
zip diagnostic: fcount=1
last_lit 4096, last_dist 2233, in 26393, out ~7925(70%)
last_lit 8192, last_dist 4762, in 59844, out ~16712(73%)
last_lit 12288, last_dist 7256, in 93160, out ~25439(73%)
last_lit 16384, last_dist 9805, in 126857, out ~34273(73%)
last_lit 20480, last_dist 12399, in 161171, out ~43183(74%)
last_lit 24576, last_dist 14961, in 194883, out ~52041(74%)
last_lit 28672, last_dist 17549, in 229292, out ~60934(74%)
opt 54841(438722) stat 69339(554706) stored 262875 lit 32767 dist 20061
last_lit 4096, last_dist 2542, in 33571, out ~8804(74%)
last_lit 8192, last_dist 5058, in 67164, out ~17565(74%)
last_lit 12288, last_dist 7592, in 100776, out ~26374(74%)
last_lit 16384, last_dist 10129, in 134188, out ~35176(74%)
last_lit 20480, last_dist 12672, in 168101, out ~43974(74%)
last_lit 24576, last_dist 15175, in 201828, out ~52713(74%)
last_lit 28672, last_dist 17770, in 235838, out ~61607(74%)
opt 55441(443520) stat 69983(559860) stored 269148 lit 32767 dist 20261
opt 1973(15778) stat 2450(19596) stored 9572 lit 1135 dist 714
zip diagnostic: writing central directory
zip diagnostic: writing end of central directory
zip diagnostic: replacing old zip file with new zip file
]]>
Validate state Invalid
Claimed credit 308.842592592593
Granted credit 0
application version 4.21
This is not a big with the
)
This is not a big with the 4.21 app (I think).
Check the Problems and Bug Reports. It occurs when a WU is sent to two hosts with different OS's (XP:Linux, Vista:OSX and so on), the results may vary slightly so a third host is sent the WU for confirmation. Which either of the first two OS's is most similar to the thirds will get validation.
This is a known bug, and I can only assume the devs are working hard to sort this out.
There are 10^11 stars in the galaxy. That used to be a huge number. But it's only a hundred billion. It's less than the national deficit! We used to call them astronomical numbers. Now we should call them economical numbers. - Richard Feynman
See here. BM
)
See here.
BM
BM