S5GC1HF x.06 Apps
Bernd Machenschalk
Moderator
Administrator
Joined: 15 Oct 04
Posts: 4312
Credit: 250273632
RAC: 35836
8 Dec 2010 13:04:00 UTC
Topic 195498
(moderation:
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
S5GC1HF x.06 Apps
)
Any chance of doing that for Windows too, because of the Domain Controller installation problem with v6 BOINCs?
RE: RE: * We will soon
)
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
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
RE: The problem is that
)
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 ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
RE: RE: The problem is
)
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
RE: The main feature common
)
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.
RE: Thinking more about
)
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.
RE: * All Apps will use a
)
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.
RE: Any chance of doing
)
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
RE: RE: * I did revive
)
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