Linux S5R2 App 4.21 available for Beta test

leg
leg
Joined: 25 Feb 05
Posts: 7
Credit: 893821265
RAC: 523593

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.

Gary Roberts
Gary Roberts
Moderator
Joined: 9 Feb 05
Posts: 5842
Credit: 109397243354
RAC: 35762167

RE: RE: @Bernd: Is there

Message 63971 in response to message 63958

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

Cheers,
Gary.

Dave Burbank
Dave Burbank
Joined: 30 Jan 06
Posts: 275
Credit: 1548376
RAC: 0

RE: It is time consuming to

Message 63972 in response to message 63971

Quote:

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

Gary Roberts
Gary Roberts
Moderator
Joined: 9 Feb 05
Posts: 5842
Credit: 109397243354
RAC: 35762167

RE: While not particularly

Message 63973 in response to message 63972

Quote:

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.

Cheers,
Gary.

Dave Burbank
Dave Burbank
Joined: 30 Jan 06
Posts: 275
Credit: 1548376
RAC: 0

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

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

RE: RE: @Bernd: Is there

Message 63975 in response to message 63958

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

CU

BRM

leg
leg
Joined: 25 Feb 05
Posts: 7
Credit: 893821265
RAC: 523593

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

Dave Burbank
Dave Burbank
Joined: 30 Jan 06
Posts: 275
Credit: 1548376
RAC: 0

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

Bernd Machenschalk
Bernd Machenschalk
Moderator
Administrator
Joined: 15 Oct 04
Posts: 4267
Credit: 244926956
RAC: 16579

See here. BM

See here.

BM

BM

Comment viewing options

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