S5GC1HF x.06 Apps

Bernd Machenschalk
Bernd Machenschalk
Moderator
Administrator
Joined: 15 Oct 04
Posts: 3,936
Credit: 198,924,698
RAC: 37,517
Topic 195498

In the next days a new generation of S5GC1HF Apps will be sent out. The main feature common to all of these is a new data ("SFT") file reading code that is meant to reduce the number of I/O operations during app start ("Reading input data ..." in stderr log) quite a bit. Other features are platform-dependent:

* All Apps will use a recent revision of the BOINC library and API. This should fix the random segfault issue on Linux, and also a minor problem on Mac OS 10.5 PPC.

* I did revive the old FStat AltiVec code. Once I have set up a plan class participants that run Mac OS 10.4 or 10.5 on a G4 or G5 (and a 6.x BOINC Client) should see a significant speedup in computation.

* We will soon raise the minimum required BOINC Core Client version for Einstein@Home. But apparently due to certain requirements of LSC Clusters these contributors can't use a Core Client version new enough that it supports plan classes. In order to still harvest the CPU power of these clusters the "basic" Linux App (no plan class) will again be a "bundle" with a "switcher" that detects CPU capabilities and selects the actual App based on the detected features.

BM

BM

Richard Haselgrove
Richard Haselgrove
Joined: 10 Dec 05
Posts: 1,935
Credit: 259,904,735
RAC: 238,786

S5GC1HF x.06 Apps

Quote:
* We will soon raise the minimum required BOINC Core Client version for Einstein@Home. But apparently due to certain requirements of LSC Clusters these contributors can't use a Core Client version new enough that it supports plan classes. In order to still harvest the CPU power of these clusters the "basic" Linux App (no plan class) will again be a "bundle" with a "switcher" that detects CPU capabilities and selects the actual App based on the detected features.


Any chance of doing that for Windows too, because of the Domain Controller installation problem with v6 BOINCs?

Bernd Machenschalk
Bernd Machenschalk
Moderator
Administrator
Joined: 15 Oct 04
Posts: 3,936
Credit: 198,924,698
RAC: 37,517

RE: RE: * We will soon

Quote:
Quote:
* We will soon raise the minimum required BOINC Core Client version for Einstein@Home. But apparently due to certain requirements of LSC Clusters these contributors can't use a Core Client version new enough that it supports plan classes. In order to still harvest the CPU power of these clusters the "basic" Linux App (no plan class) will again be a "bundle" with a "switcher" that detects CPU capabilities and selects the actual App based on the detected features.

Any chance of doing that for Windows too, because of the Domain Controller installation problem with v6 BOINCs?

The problem is that Windows doesn't have this Unix concept of "exec", i.e. completely replacing a running process with a new binary. On Windows, the switcher is started by the BOINC Client, it in turn starts the actual application, but keeps running as an additional process. Furthermore the process that the BOINC Client knows about and monitors is the switcher, while the process it communicates with via messages is the application.

The issues arising from these inconsistencies were the reason that we started to use plan classes for SSE/SSE2 Apps.

Bottom line: I think using this on Windows again would bring (back) more problems than it would solve.

BM

BM

Bernd Machenschalk
Bernd Machenschalk
Moderator
Administrator
Joined: 15 Oct 04
Posts: 3,936
Credit: 198,924,698
RAC: 37,517

Thinking more about that:

Thinking more about that: Could you describe the issues on a domain controller a bit more detailed, or point me to a forum thread? It might be possible to set up an own plan class or something for this special case.

BM

BM

Mike Hewson
Mike Hewson
Moderator
Joined: 1 Dec 05
Posts: 6,124
Credit: 126,479,473
RAC: 19,791

RE: The problem is that

Quote:
The problem is that Windows doesn't have this Unix concept of "exec", i.e. completely replacing a running process with a new binary.


So that's the fork/copy, test for child process ID, then load/overwrite sequence?

Cheers, Mike.

I have made this letter longer than usual because I lack the time to make it shorter. Blaise Pascal

Bernd Machenschalk
Bernd Machenschalk
Moderator
Administrator
Joined: 15 Oct 04
Posts: 3,936
Credit: 198,924,698
RAC: 37,517

RE: RE: The problem is

Quote:
Quote:
The problem is that Windows doesn't have this Unix concept of "exec", i.e. completely replacing a running process with a new binary.

So that's the fork/copy, test for child process ID, then load/overwrite sequence?

Yup, that's fork (clone) & exec (replace). Actually I find it counter-intuitive and thus stupid to expose this in an API, even if process creation is internally done that way. But for this special purpose having exec comes in handy.

BM

BM

archae86
archae86
Joined: 6 Dec 05
Posts: 2,813
Credit: 3,226,912,876
RAC: 2,603,204

RE: The main feature common

Quote:
The main feature common to all of these is a new data ("SFT") file reading code that is meant to reduce the number of I/O operations during app start ("Reading SFTs and setting up stacks" in stderr log) quite a bit.


This is extremely welcome news. Especially on multicore machines running certain antivirus applications, the startup phase has become quite long, and as it grows with frequency, the new HF work has made things yet worse.

Thanks for the news.

Richard Haselgrove
Richard Haselgrove
Joined: 10 Dec 05
Posts: 1,935
Credit: 259,904,735
RAC: 238,786

RE: Thinking more about

Quote:

Thinking more about that: Could you describe the issues on a domain controller a bit more detailed, or point me to a forum thread? It might be possible to set up an own plan class or something for this special case.

BM


Best reference is probably trac ticket [trac]#652[/trac]. It's an installer problem, not a BOINC problem per se. Ever since sandbox security was introduced at the very start of the BOINC v6 sequence, BOINC has run under its own (restricted) local user account created by the installer. Local user accounts aren't permitted by the OS on a Domain Controller, but nobody has created a DC-compatible installer to work round the problem by using a different class of BOINC account - see the list of 'punts' on that ticket.

Domain controllers aren't just enterprise-class hardware: every Microsoft "Small Business Server" comes into this category too, and can't run the installer for anything later than BOINC v5.10 - so no plan_class support is going to be available.

There has been some talk of workarounds involving replacing the executable files from a v5 installation with the equivalents from a v6 distribution. That has the complication of requiring a manual separation of the program and data folders. I have (remote) access to an SBS 2008 server I can experiment on - I'll try to test it out when things are quiet at the weekend, and let you know how I get on.

Donald A. Tevault
Donald A. Tevault
Joined: 17 Feb 06
Posts: 439
Credit: 73,516,529
RAC: 0

RE: * All Apps will use a

Quote:

* All Apps will use a recent revision of the BOINC library and API. This should fix the random segfault issue on Linux, and also a minor problem on Mac OS 10.5 PPC.

* I did revive the old FStat AltiVec code. Once I have set up a plan class participants that run Mac OS 10.4 or 10.5 on a G4 or G5 (and a 6.x BOINC Client) should see a significant speedup in computation.

BM

Definitely good news about the AltiVec app. I always wondered why performance on my 2.3 GHz G5 Mac was so poor. Now, I know.

Bernd Machenschalk
Bernd Machenschalk
Moderator
Administrator
Joined: 15 Oct 04
Posts: 3,936
Credit: 198,924,698
RAC: 37,517

RE: Any chance of doing

Quote:
Any chance of doing that for Windows too, because of the Domain Controller installation problem with v6 BOINCs?

I'm currently discussing this on the BOINC developers mailing list, but my current impression is that this problem can and should be fixed elsewhere.

BTW I'm holding back the generic 1.0 Linux App (too) until this has been sorted out.

BM

BM

Bernd Machenschalk
Bernd Machenschalk
Moderator
Administrator
Joined: 15 Oct 04
Posts: 3,936
Credit: 198,924,698
RAC: 37,517

RE: RE: * I did revive

Quote:
Quote:
* I did revive the old FStat AltiVec code. Once I have set up a plan class participants that run Mac OS 10.4 or 10.5 on a G4 or G5 (and a 6.x BOINC Client) should see a significant speedup in computation.

Definitely good news about the AltiVec app. I always wondered why performance on my 2.3 GHz G5 Mac was so poor. Now, I know.

Done.

G4 and G5 Macs running Mac OS 10.4 or 10.5 should now get the 7.06 AltiVec App with new work. Note that with Clients prior to 6.2 you need to reset the project to get the new app version.

BM

BM

Comment viewing options

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