Re: [boinc_dev] Software development and branches, was Re: [boinc_projects] keywords
On 2017-08-08 11:55, Steffen Möller wrote: People on this thread take one of two positions: a) have it the way we always had it in BOINC, mostly in ignorance of what git could do for BOINC b) have it the same way that git is used in any other larger Open Source project git by itself is just an SCM that supports easy branching and merging. This doesn't enforce a particular branch model or branch properties. Thee are quite a few projects even on github that use git without following e.g. gitflow or any other model specifically supported by github. git, however, was developed to support a distributed, collaborative development process as used for the Linux kernel. This development model requires a stable 'master' branch. Most software developers involved in this discussion here (including me) have been developing software this way for, say, the past 10y - I don't really think that it's "impossible". So the real decision to make would be whether to move from a centralized development model (1.) that hinders effective collaboration (e.g. by throwing everything into master without review, discussion, tests or anything) and distribution (everyone being constantly affected by what anyone else throws into master) to a model that allows distributed collaborative development (2.). The important thing to note is that these models of development are incompatible. A developer following 1. will inevitably ruin every effort of anyone else to do 2., that's why we need a decision. The branching model to use in (2.) is really just details and can be decided later. This decision is to be made by the PCM (https://boinc.berkeley.edu/trac/wiki/ProjectGovernance). Depending on the outcome, people wanting to develop BOINC in their own style may do so by forking it. But before that official decision has been made, it doesn't make sense to split the community, resulting in doubling effort and halving the resources. Bernd ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] Software development and branches, was Re: [boinc_projects] keywords
On 08.08.17 14:47, Oliver Bock wrote: https://boinc.berkeley.edu/trac/wiki/DevMethodologies as well, at least in two key sentences or the apparent conclusions derived from them: - "Once we let go of the idea that master should be stable (which is impossible for reasons given here, there is no reason to require that developers use any particular methodology." I think that becomes correct in reverse: Once we let go of any particular methodology (or model, ruleset), it is impossible to keep master stable. Bernd ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] Software development and branches, was Re: [boinc_projects] keywords
On 2017-08-08 08:23, David Anderson wrote: Please read https://boinc.berkeley.edu/trac/wiki/SoftwareTesting Yes, I did a number of times. What exactly are you referring to? - I am referring to development in BOINC in general, not restricted to the server software. - The fact that you don't know to do something as a whole doesn't mean it's impossible even in parts and should not be attempted Bernd -- David On 8/7/2017 10:28 PM, Bernd Machenschalk wrote: On 07.08.17 21:40, David Anderson wrote: I've proposed creating server release branches, similar to the exiting client release branches. Hopefully this will satisfy everyone's needs. What I (and others) need is a "stable" branch (whatever named) I can - branch off my own development to work without being affected by others - compare and test my changes against, which requires that the original branch is "stable" - merge my development (branch) into when I'm done and I and others are convinced that my development does what it should and doesn't destabilize the branch. I don't see how server release branches would do that. Bernd ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] Software development and branches, was Re: [boinc_projects] keywords
On 07.08.17 21:40, David Anderson wrote: I've proposed creating server release branches, similar to the exiting client release branches. Hopefully this will satisfy everyone's needs. What I (and others) need is a "stable" branch (whatever named) I can - branch off my own development to work without being affected by others - compare and test my changes against, which requires that the original branch is "stable" - merge my development (branch) into when I'm done and I and others are convinced that my development does what it should and doesn't destabilize the branch. I don't see how server release branches would do that. Bernd ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] Software development and branches, was Re: [boinc_projects] keywords
On 2017-08-06 22:40, David Anderson wrote:
Please read https://boinc.berkeley.edu/trac/wiki/SoftwareTesting
in particular the definition of "stable".
[...]
Testing a feature in isolation is not the same as testing the system.
Indeed.
But that doesn't mean that "testing in isolation" shouldn't happen, in
particular as you wrote on the wiki page: "we currently have no way of
testing server software [as a system (my addition)]". The server
software is indeed way too complex to be tested as a whole, thus one
should (at least) test the components ("isolated"). These are tests that
- unlike stated in the Wiki page - _can_ be done by developers (or by
continuous integration for them automatically). This might not catch all
problems, but more than enough, before exposing these to the projects
and the public.
Again: writing and performing the test that can be performed isolated
and automatically will actually save us (here: first and foremost the
projects, ultimately the developers, too) work, even if it looks like
more work (for the developer) at first.
No one is advocating committing untested or buggy code into master.
Ok - then how do you prevent this from happening if everything,
including unfinished and untested development, is committed into "master"?
However, feature testing doesn't mean that master is stable.
No, this is not sufficient, but nevertheless necessary and helps a lot.
IMO an unstable "master" or "trunk" is a no-go for distributed,
collaborative software development. Thus we should strive to stabilize
"master" as much as possible by writing tests that can be executed
automatically, and by peer-reviewing every change made to it. If we
can't agree on that, I'm afraid you are - and will continue to be - on
your own.
Bernd
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
Re: [boinc_dev] Software development and branches, was Re: [boinc_projects] keywords
On 04.08.17 23:17, David Anderson wrote: On 7/21/2017 5:47 AM, Bernd Machenschalk wrote: This might be one of the fundamental (pun intended) misunderstandings here. It is the opposite of everything I ever heard or read, and I think I know why: How can one (expect to) fork a 'stable' branch from an 'unstable' one? How can one grow a tree (of branches) from an unstable foundation and expect it to be stable? It's simple: 1) fork master, e.g. to client_release_xxx. It's not stable at this point. 2) test client_release_xxx (e.g. using Alpha testers) fix bugs, repeat. Now it's stable. 3) only backport bug fixes to client_release_xxx. It remains stable. This is like stabilizing a tree with an unstable trunk by supporting every branch with numerous tree props. The problem with that is not that it's impossible; it's just highly inefficient. In the early times of CVS, where branching was a pain and merging was impossible, this once was the only feasible (yet not optimal) model. However already at that time there were people thinking of ways to stabilize the trunk, i.e. by introducing tests that should be ran locally (and pass) before committing anything into trunk. There is one big lesson that has been learned from various small and large (software) projects: the later a problem is discovered, the more work is required to fix it. Thus a major effort in software engineering is to develop methods and tools to discover errors as early as possible. This is not for academic discussion, it is there to save everyone who develops software as much work as possible (The best work is one that you don't have to do at all). Examples of what we arrived at can be seen at github: Static code analysis and continuous integration (or continuous testing), integrated with flexible source code management systems. All of this is there to work for you so you don't have to do that work yourself. If the trunk is completely unstable, problems pile up and even start to interact there. Disentangling these to later stabilize a branch might be difficult up to impossible, and it's certainly work that can be saved by testing each feature/development.commit separately, and only commit/push/merge it back to trunk if it works by itself. The model of a completely unstable single development trunk may work for a small group of closely connected developers. It fails badly if there are multiple developers working on different features in parallel. One will always feel that the own development is ruined by the commits of someone else. Avoiding that requires a level of coordination that would be difficult to achieve among multiple developers spread over different timezones; at least it would slow down the actual development quite significantly. Consequently I know of no (other) software project that still sticks to that model, in particular not in the distributed Open Source community. I may be wrong, though, corrections are welcome. We've always used this approach for the client, and it's worked perfectly. We can use the same approach for server if we create a distributed testing system based on Beta projects (analogous to the client Alpha test) The server is much more complex than the client, with all its components (that are project-specific to a large part) and options. What might have worked for the client will not work effectively for the server. Starting testing only at pre-release stage and then trying to fix the bugs that come up then is so inefficient that it wouldn't work at all for such a complex system. Having learned and benefited from modern methods of software development I am no longer willing to waste my time on work that can be avoided altogether, and I know that quite a few BOINC developers feel the same. I think if BOINC is willing to survive (with its currently limited resources) its software development process needs to become much more efficient by adopting modern methods. This will also help to increase the resources in terms of volunteer software developers. If that's not going to happen, BOINC will die. Bernd ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] [boinc_projects] keywords
Hi David!
On 2017-07-21 00:50, David Anderson wrote:
This discussion comes down to two contrasting models for software
development:
1) The "waterfall model":
...
2) The "agile model":
https://en.wikipedia.org/wiki/Agile_software_development
New features are divided into smaller self-contained pieces,
which are completed and merged with master frequently.
Requirements and design can change on the fly.
Development need not be done in a separate branch.
The "agile model" (as referenced by you) doesn't say anything about SCM
or branches. However, collaborative agile development requires and
implies doing basically all development (bugfixes, features, etc.) in
branches (see e.g. https://www.atlassian.com/agile/branching) to isolate
development, until a development is complete and merged back into a
'master' branch (that may or may not be called like that).
Master is unstable in both models; releases are done from stable branches.
Where do you get that from?
2) I often work on several things at once.
If I do each one in a separate branch,
I inevitably commit code to the wrong branch,
and it's hard to untangle things later.
When working on many things in parallel, working in branches even helps
me to stay structured and focused. There are tools to keep track of
which branch you are currently on, and ways to move commits from one
branch to another, if you accidentally committed to the wrong one.
3) I want my code reviewed and tested by others ASAP.
I have only Win7 and Linux computers.
If my code doesn't work on other platforms, I want to know this ASAP.
I want to commit to master in small-size, frequent units.
That doesn't require using a single branch ('master' or other).
Continuous Integration (like Travis on github) can and does test
(virtually) every branch on every configured platform. Everyone can
check out any branch and test this, without being affected by any
problems introduced by other development (in master) he doesn't care about.
4) It's worked extremely well so far.
BOINC has evolved rapidly and continuously over 15 years.
It's still very malleable and well-structured, making it easy to
change and add.
Apparently it worked for you quite well. However the way BOINC has been
developed in the past years is causing a lot of volunteer developers
quite some headache and trouble, up to the point where they quit
contributing. This is exactly why it needs to be improved.
Best,
Bernd
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
Re: [boinc_dev] [boinc_projects] keywords
On 2017-07-20 10:09, David Anderson wrote: On 7/20/2017 12:37 AM, Oliver Bock wrote: Sorry, but this isn't a sustainable model. Well, it's sustained us this far. I'm not so sure about that, at least if "us" should cover more than SETI. Most major projects that I know of use BOINC server code that is as outdated as their requirements allow, and do their own development based on that old version. Ours (E@H) dates back to early 2012, Rosetta's is way older (2009?), WCG uses the first git migration (late 2012). Projects are worried first about stability and reliability, then about features they may need. You certainly don't want to build your project code - that should reliably manage some 100k machines of some 10k users that you don't want to alienate - from a branch that every intermediate half-baked commit of a handful of features that is worked on in parallel gets committed to. That's what's driving GPUgrid away, and that shows that - in my understanding of 'sustain' - it DOESN'T sustain. We could have a server stable branch, as you've suggested, if we could figure out how to test the server software. A system as complex as BOINC can only be trusted as a whole by building up trust from the ground up, i;e; by building trust to its components. This means that testing the "server software" means and requires testing its components. Testing, of course, can only mean testing the behavior compared to a specification (even if the specification isn't written down explicitly; then the test defines the specification). This, in turn, means you would better have a specification, at least for each module and interface, which first should be verified on its own for correctness and completeness. Then you can write a test case/program/whatever for this module. Then you can test this module to conform to your specification. Basically there is no point in testing a module or a system as long its (desired) behavior isn't specified. Best, Bernd ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] Condor-B
Thanks, David, that's helpful! I'll talk to our local Condor gurus first and see how far we get. Thanks again, Bernd David Anderson wrote on 18.05.16 21:44: Condor-B was an effort to add a BOINC back end to Open Science Grid. The development was completed and tested, but it was never deployed. Condor has a plug-in architecture for adding different back ends. The Condor job router talks to the plugins using a protocol called GAHP. The BOINC plugin is in boinc/samples/condor. I'm not sure how you configure Condor to route jobs to BOINC, or whether this is part of their standard release. The person who would know is Jamie Frey; I can give you his contact info if needed. -- David On 5/17/2016 8:20 AM, Bernd Machenschalk wrote: Hi David! Recently on Einstein@Home the need (or: wish) occurred to integrate a BOINC application into a Pegasus-WMS workflow, and we came across "Condor-B" (as outlined in https://boinc.berkeley.edu/trac/wiki/CondorBoinc). Could you please tell me about the status of this project, and possibly some further documentation? Thanks in advance, Bernd ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] automatic filename extension in windows wrapper
Bernd Machenschalk wrote on 26.02.16 07:00:
Speaking about wrapper: would it hurt anyone if the "macros"
(NTHREADS, GPU_DEVICE and in particular PROJECT_DIR) would be replaced
in the complete command-line passed to the worker _after_ the
arguments to the wrapper have been added ()?
This way one could pass "resolved" file names to the "worker
application". One possibly needs to circumvent the shell
interpretation of '$', e.g. by using '%' ('"%PROJECT_DIR") on the
command-line.
Thinking more about that I think it would even be better to have a
possibility to boinc-resolve files in the command-line (or in an
environment variable setting), in cases where the resolved name is not
known when the command-line is built. Say a phrase like
"boinc_resolve()" on the command-line is replaced by the
"boinc_resolve"d .
Currently you can only tell the wrapper to copy a input or output file,
which is a bad choice for large files, or to pack/unpack it in a zip
file, which unnecessarily complicates e.g. validation assimilation etc.
Best,
Bernd
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
Re: [boinc_dev] automatic filename extension in windows wrapper
Speaking about wrapper: would it hurt anyone if the "macros" (NTHREADS,
GPU_DEVICE and in particular PROJECT_DIR) would be replaced in the
complete command-line passed to the worker _after_ the arguments to the
wrapper have been added ()? This way one could
pass "resolved" file names to the "worker application". One possibly
needs to circumvent the shell interpretation of '$', e.g. by using '%'
('"%PROJECT_DIR") on the command-line.
Bernd
Christian Beer wrote on 25.02.16 21:09:
Hi,
we have a use case where we want to use the wrapper to deploy a legacy
application. The application is bundled in a zip archive that is
extracted by the wrapper into the slot directory. This application is
called "LegacyApp" and "LegacyApp.exe" on Linux and Windows
respectively. Now comes the problem. We want t include the job.xml file
as part of the workunit not the appversion. This way we can only set one
name "LegacyApp" which causes problems because for an unknown reason
Windows 7 will not start a file without the .exe extension.
I looked through the code and found a place
(https://github.com/BOINC/boinc/blob/master/samples/wrapper/wrapper.cpp#L633)
where we could add some more logic to detect such a case and add the
".exe" extension. Something like: if on windows and app_path does not
exist try app_path+".exe"
Another possibility would be to also add the .exe extension to the linux
executable but who want's to do that? And remember it later when we
wonder why we fixed a Windows Problem on Linux.
Any thoughts on that?
Regards
Christian
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
Re: [boinc_dev] [boinc_projects] change scheduler URL
On 08.10.14 17:30, Bernd Machenschalk wrote: On 08.10.14 17:16, Bernd Machenschalk wrote: Hi! We needed to change the scheduler URL (the one in schedulers.txt). This now appears in the correct place in the front page. The question is how we should configure apache on the old site to force clients to re-fetch the scheduler list from the (changed) master page. Currently the http error at the old URL is a 404 (not found). Apparently this doesn't help, as we don't get much traffic on the new scheduler. FWIW a Redirect doesn't help, as the POST data gets lost. Apparently the Client will re-fetch the scheduler list from the master URL after 10 consecutive failures to get work. If I'm not mistaken about the backoff time scheme this could actually take several days, depending on the work cache of the Client. An explicit permanent redirect from the web server should IMHO be a clear sign that the Client contacts an outdated URL and thus should update its information (here re-fetch the scheduler list) _immediately_. Could this be added to the BOINC Client, i.e. explicit Redirects be handled not as a communications error, but as a special case which triggers a new master file fetch? Best, Bernd ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] [boinc_projects] change scheduler URL
Thanks a lot! I have to admit that I indeed did miss the Permanent flag. A RedirectPermanent seems to work! However this leaves the scheduler URL in the client at the old URL, i.e. the client doesn't really take notice, just the underlying curl(?). I vaguely remember that the master file will be re-fetched periodically in any case? Is this so, and if so, what period? 1 week? Best, Bernd On 09.10.14 11:59, Tomi Juhani Asp wrote: Hi! Not sure if this will solve your issue but we were struggling a bit with redirects as well but solved it by giving the rewrite rule a [R=301] flag. 301 code means that the resource has been moved permanently and all the following requests should be made to the new address. By default, if using just R flag, apache issues different status code. Cheers, Tomi From: boinc_projects [boinc_projects-boun...@ssl.berkeley.edu] on behalf of Bernd Machenschalk [bernd.machensch...@aei.mpg.de] Sent: 09 October 2014 11:38 To: BOINC Developers Mailing List Cc: Boinc Projects Subject: Re: [boinc_projects] [boinc_dev] change scheduler URL On 08.10.14 17:30, Bernd Machenschalk wrote: On 08.10.14 17:16, Bernd Machenschalk wrote: Hi! We needed to change the scheduler URL (the one in schedulers.txt). This now appears in the correct place in the front page. The question is how we should configure apache on the old site to force clients to re-fetch the scheduler list from the (changed) master page. Currently the http error at the old URL is a 404 (not found). Apparently this doesn't help, as we don't get much traffic on the new scheduler. FWIW a Redirect doesn't help, as the POST data gets lost. Apparently the Client will re-fetch the scheduler list from the master URL after 10 consecutive failures to get work. If I'm not mistaken about the backoff time scheme this could actually take several days, depending on the work cache of the Client. An explicit permanent redirect from the web server should IMHO be a clear sign that the Client contacts an outdated URL and thus should update its information (here re-fetch the scheduler list) _immediately_. Could this be added to the BOINC Client, i.e. explicit Redirects be handled not as a communications error, but as a special case which triggers a new master file fetch? Best, Bernd ___ boinc_projects mailing list boinc_proje...@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_projects To unsubscribe, visit the above URL and (near bottom of page) enter your email address. ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
[boinc_dev] change scheduler URL
Hi! We needed to change the scheduler URL (the one in schedulers.txt). This now appears in the correct place in the front page. The question is how we should configure apache on the old site to force clients to re-fetch the scheduler list from the (changed) master page. Currently the http error at the old URL is a 404 (not found). Apparently this doesn't help, as we don't get much traffic on the new scheduler. Best, Bernd ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] [boinc_projects] change scheduler URL
On 08.10.14 17:16, Bernd Machenschalk wrote: Hi! We needed to change the scheduler URL (the one in schedulers.txt). This now appears in the correct place in the front page. The question is how we should configure apache on the old site to force clients to re-fetch the scheduler list from the (changed) master page. Currently the http error at the old URL is a 404 (not found). Apparently this doesn't help, as we don't get much traffic on the new scheduler. FWIW a Redirect doesn't help, as the POST data gets lost. Bernd ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] [boinc_projects] Credit revisited
Hi David! On 12.08.14 08:48, David Anderson wrote: Please review and comment. What is your preferred way of commenting? Private mail, boinc_projects, boinc_dev, in the Wiki (for those who have write access), Boinc Forums? Best, Bernd ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] Feature request: Preference for graphics apps or fastapps.
Out of curiosity: would it be possible with reasonable effort to configure the client to have exactly one graphical task running for the graphics and the faster version running on the other CPU cores? Bernd On 6. August 2014 01:08:37 MESZ, Bernd Machenschalk bernd.machensch...@aei.mpg.de wrote: Add a project-specific prefs setting. The name of the tag and value to be used depends on e.g. what the default should be. Set up a plan class for the non-graphical app version. Use project_prefs_tag and project_prefs_regex in plan class specification to disable that plan class depending on the project prefs setting. hth, Bernd Eric J Korpela wrote, On 05.08.14 18:53: There's lot of copies of data to and from shared arrays. Even when the screen saver is off, the check to see if data needs to be copied is a non-zero overhead. There are optimizations that become difficult when the graphics code is enable. The lab is having network problems, so I can't currently get you a speed ratio of the no-graphics to graphics versions. It would be difficult to add graphics back into the versions that don't currently have it. On Tue, Aug 5, 2014 at 9:29 AM, Rom Walton r...@romwnet.org wrote: What overhead is left for the regular app with regards to graphics? I thought all the major overhead is in the graphics app itself. - Rom -Original Message- From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of Eric J Korpela Sent: Tuesday, August 05, 2014 11:49 AM To: boinc_dev@ssl.berkeley.edu; David Anderson Subject: [boinc_dev] Feature request: Preference for graphics apps or fastapps. Hi David, Starting with Astropulse 7 we're going to have both a standard app with graphics code for the screen saver and a faster version without the graphics overhead. If I just release them as is, the non-graphical version will quickly become dominant. There are still people out there who like to see the screensaver graphics. I haven't come up with a way (apart from custom code) to allow people to choose to get a slower version with graphics over a faster version without. Any ideas on whether such a thing could be done? -- Eric ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address. ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address. ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address. ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] Feature request: Preference for graphics apps or fastapps.
Hi David! Given that you look into the PSP (project-specific preferences) code anyway, probably with the result that projects that want or need to use the resulting web code need to rewrite their PSP code, may I (again) suggest to consider implementing PSP read from a (XML) config file? I think the config file approach has shown its benefit to numerous projects that use config files to set up their plan classes. It would offer the additional possibility of displaying and even editing PSPs in account managers and client managers. Oliver has already mentioned that we use this approach in the BOINC-Drupal project and has pointed out the XML specification that was developed there. I think it would save time and effort for all of us to use this as a basis. We certainly would be willing to help implementing this approach. Best, Bernd On 06.08.14 01:32, David Anderson wrote: Yes, that's the way to do it. I'll look into updating the project-specific-prefs code to use the same object-oriented framework as general prefs. -- David On 05-Aug-2014 4:08 PM, Bernd Machenschalk wrote: Add a project-specific prefs setting. The name of the tag and value to be used depends on e.g. what the default should be. Set up a plan class for the non-graphical app version. Use project_prefs_tag and project_prefs_regex in plan class specification to disable that plan class depending on the project prefs setting. hth, Bernd Eric J Korpela wrote, On 05.08.14 18:53: There's lot of copies of data to and from shared arrays. Even when the screen saver is off, the check to see if data needs to be copied is a non-zero overhead. There are optimizations that become difficult when the graphics code is enable. The lab is having network problems, so I can't currently get you a speed ratio of the no-graphics to graphics versions. It would be difficult to add graphics back into the versions that don't currently have it. On Tue, Aug 5, 2014 at 9:29 AM, Rom Walton r...@romwnet.org wrote: What overhead is left for the regular app with regards to graphics? I thought all the major overhead is in the graphics app itself. - Rom -Original Message- From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of Eric J Korpela Sent: Tuesday, August 05, 2014 11:49 AM To: boinc_dev@ssl.berkeley.edu; David Anderson Subject: [boinc_dev] Feature request: Preference for graphics apps or fastapps. Hi David, Starting with Astropulse 7 we're going to have both a standard app with graphics code for the screen saver and a faster version without the graphics overhead. If I just release them as is, the non-graphical version will quickly become dominant. There are still people out there who like to see the screensaver graphics. I haven't come up with a way (apart from custom code) to allow people to choose to get a slower version with graphics over a faster version without. Any ideas on whether such a thing could be done? -- Eric ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address. ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address. ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address. ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address. ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] Feature request: Preference for graphics apps or fastapps.
Bernd Machenschalk wrote, On 06.08.14 22:08: - build an application version bundle that contains both application versions and a small wrapper program - the wrapper gets started by the BOINC Client - on start, the wrapper tries to create and lock a file in the project(!) directory + if acquiring the lock fails, it means that there is already a graphical version running, so start the faster, non-graphical version + if acquiring the lock succeeds, start the graphical version and remove the lock file after the graphical program terminated Implementation note: the app versions and the wrapper don't need to be three separate programs / executables, but actually different main() functions (main() (wrapper) calling main_graphical() or main_fast()) linked into the same binary. This would relieve us of the necessity to forward signals from the wrapper process to the actual application, which in the above model runs as a separate process. OTOH requiring that different objects (functions, variables) have different names the one-program approach might seriously complicate code, building linking. Best, Bernd ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] Feature request: Preference for graphics apps or fastapps.
Bernd Machenschalk wrote, On 06.08.14 08:30: Out of curiosity: would it be possible with reasonable effort to configure the client to have exactly one graphical task running for the graphics and the faster version running on the other CPU cores? One more thought: Is there a way to tell the screensaver whether it should show the progress of non-graphical tasks in standard progress bars or skip such tasks altogether and show only graphical ones? Best, Bernd ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] Deleting your project account
Actually deleting a user account (row in user table) would harm the consistency of the database, these are referenced everywhere. As BOINC (web) code is not really good in handling unexpected results of DB queries this would cause visible problems all over the place. However a standard procedure (function) for invalidating accounts that is made known to users as well as project admins would certainly be of value, and nowadays would actually be required by the laws of an increasing number of countries. I would add a button delete account that sets the name to the predefined string (account deleted),.does.something similar with the email address and modifies the authenticator such that it becomes invalid, but the original value can still be derived if necessary (e.g. append _deleted). A project admin then can still restore (access to) the account when he gets mailed the original authenticator for verification. Best, Bernd On 7. August 2014 06:30:08 MESZ, David Anderson da...@ssl.berkeley.edu wrote: I'm not sure a delete account function is needed. A use can effectively remove his account by setting the name and email address to random strings. -- David On 06-Aug-2014 3:14 PM, Jord van der Elst wrote: Hi developers, I've taken a longer look at deleting the account at BOINC projects. The option is there in the code, but it's at present disabled, as it isn't fool proof. Now, I'm not saying I can make it fool proof, but... What if when I wanted to delete my account, I press the key to do so, I get the warning pop-up asking me if I really want to do so, I click Yes. That at that time, all that really happens is that the account's authentication key gets removed from the database, that the authentication key is emailed to me --the deleting user-- and to the project administrator (special email address?) but that the account is still in the database just not accessible by me? The email to the project administrator will hold the date and time of removal, the authentication key, my email address, my IP address (?) and my (nick)name. Then if I think the next day or week that I want to have my account back, that I can email the administrator, give him the details on the account and the authenticator key, and that all he has to do is add it back in the database, and presto everything works again? Of course, by also (silently) sending this to the project administrator, we make sure that if someone malicious managed to get his hands on my account, and deleted it, that the project administrator is able to put it back without much trouble. -- Jord van der Elst. ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address. ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address. ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] Feature request: Preference for graphics apps or fastapps.
Add a project-specific prefs setting. The name of the tag and value to be used depends on e.g. what the default should be. Set up a plan class for the non-graphical app version. Use project_prefs_tag and project_prefs_regex in plan class specification to disable that plan class depending on the project prefs setting. hth, Bernd Eric J Korpela wrote, On 05.08.14 18:53: There's lot of copies of data to and from shared arrays. Even when the screen saver is off, the check to see if data needs to be copied is a non-zero overhead. There are optimizations that become difficult when the graphics code is enable. The lab is having network problems, so I can't currently get you a speed ratio of the no-graphics to graphics versions. It would be difficult to add graphics back into the versions that don't currently have it. On Tue, Aug 5, 2014 at 9:29 AM, Rom Walton r...@romwnet.org wrote: What overhead is left for the regular app with regards to graphics? I thought all the major overhead is in the graphics app itself. - Rom -Original Message- From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of Eric J Korpela Sent: Tuesday, August 05, 2014 11:49 AM To: boinc_dev@ssl.berkeley.edu; David Anderson Subject: [boinc_dev] Feature request: Preference for graphics apps or fastapps. Hi David, Starting with Astropulse 7 we're going to have both a standard app with graphics code for the screen saver and a faster version without the graphics overhead. If I just release them as is, the non-graphical version will quickly become dominant. There are still people out there who like to see the screensaver graphics. I haven't come up with a way (apart from custom code) to allow people to choose to get a slower version with graphics over a faster version without. Any ideas on whether such a thing could be done? -- Eric ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address. ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address. ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] How much will this -- or any upcoming EU bans on personal data -- affect BOINC project databases ... that don't really store but a fragment ...
At first glance I find the article pretty ambiguous in its attempt to translate the Russian law into English. E.g. it first speaks of Internet companies (which BOINC or BOINC projects certainly aren't), and later about Websites. personal date is also unspecified. Does someone on this list has access to the actual law text and can provide a more precise translation? Best, Bernd On 07.07.14 12:13, Max Power wrote: How much will this -- or any upcoming EU ban on personal data -- affect BOINC project databases ... that don't really store but a fragment ... This probably has to do with the Snoden Files, that have revealed that storing data in a US or EU cloud is as good as giving the data to the NSA or GCHQ. http://rt.com/politics/170604-russia-personal-data-servers/ ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] EXIT_TIME_LIMIT_EXCEEDED (sorry, yes me again, but please read)
On 11.06.14 15:57, Charles Elliott wrote: Wasn't the fundamental problem being attacked the constant credit inflation due to architectural improvements in CPUs and GPUs? AFAIK this wasn't a (primary) concern. See http://boinc.berkeley.edu/trac/wiki/CreditNew . The original goal was to produce a system that is as automatic as possible, i.e. relieves projects of the work required to manually adjust credit / application (version) properties, and is robust against client-side cheating. I remember that the question to inflate or not to inflate credit _in_ the new system was discussed numerous times and at length, also on this list. Best, Bernd ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] EXIT_TIME_LIMIT_EXCEEDED (sorry, yes me again, but please read)
On 10.06.14 22:03, Eric J Korpela wrote: The only thought I've had recently is to have a calibration plan class that has a non-SIMD non-threaded unoptimized CPU-only app_version that gets sent out once out of every N (~100,000) results. This (as the least efficient app_version) could set the pfc_scale. Again, it would require project participation, so it wouldn't work. That reminds me of the idea of pilot applications that would test a particular host for the feasibility of a particular app (version), e.g. hardware properties (motion sensors?) or installed software (versions) (like libc version on Linux) that the Client doesn't detect and report. Such applications also could run project application specific benchmarks, that are (presumably) much closer to the actual performance of project applications on a given host. However setting up these applications would require rather more work from the projects, than less (which was the original intention). Best, Bernd ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] EXIT_TIME_LIMIT_EXCEEDED (sorry, yes me again, but please read)
Credit is a difficult thing, different people expect different things from credit and from how it is granted. I suggest we focus on discussing and possibly develop a way to fix runtime estimation / work assignment problems, and maybe re-think credit granting later. Best, Bernd On 10.06.14 20:34, David Anderson wrote: For credit purposes, the standard is peak FLOPS, i.e. we give credit for what the device could do, rather than what it actually did. Among other things, this encourages projects to develop more efficient apps. Currently we're not measuring this well for x86 CPUs, since our Whetstone benchmark isn't optimized. Ideally the BOINC client should include variants for the most common CPU features, as we do for ARM. -- D On 10-Jun-2014 2:09 AM, Richard Haselgrove wrote: Before anybody leaps into making any changes on the basis of that observation, I think we ought to pause and consider why we have a benchmark, and what we use it for. I'd suggest that in an ideal world, we would be measuring the actual running speed of (each project's) science applications on that particular host, optimisations and all. We gradually do this through the runtime averages anyway, but it's hard to gather a priori data on a new host. Instead of (initially) measuring science application performance, we measure hardware performance as a surrogate. We now have (at least) three ways of doing that: x86: minimum, most conservative, estimate, no optimisations allowed for. Android: allows for optimised hardware pathways with vfp or neon, but doesn't relate back to science app capability. GPU: maximum theoretical 'peak flops', calculated from card parameters, then scaled back by rule of thumb. Maybe we should standardise on just one standard? ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] upgrade_db bug
Hm, might well be our pretty outdated OS / mysql / PHP on that machine ... Sorry for bothering you. Bernd On 09.06.14 05:03, David Anderson wrote: Bernd: I can't repro this; when I use an invalid DB user name the script prints and error msg and exits before trying to do queries. I'm using this MySQL version: mysql Ver 14.14 Distrib 5.1.73, for redhat-linux-gnu (x86_64) using readline 5.1 On 05-Jun-2014 11:20 PM, Bernd Machenschalk wrote: Trying to update the DB I just got: PHP Warning: mysql_pconnect(): Access denied for user 'db_user'@'192.168.0.1' (using password: YES) in /raida/BOINC/projects/EinsteinAtHome/html/inc/util_ops.inc on line 112 Warning: mysql_pconnect(): Access denied for user 'db_user'@'192.168.0.1' (using password: YES) in /raida/BOINC/projects/EinsteinAtHome/html/inc/util_ops.inc on line 112 performing update update_6_5_2014 Doing query: alter table app_version add beta tinyint not null Success. All done. I.e. the update was marked as done although access was denied. This certainly shouldn't happen. While at it, would it be possible that the script reads the DB information from config.xml? This would avoid having to type the password in plain view. Best, Bernd ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] Feature request: resend
Thanks! Bernd On 09.06.14 05:20, David Anderson wrote: I made these changes. -- David On 05-Jun-2014 5:19 AM, Bernd Machenschalk wrote: Hi! Digging through the app selection stuff in current server code I cam across something I intended to implement but couldn't right away: Don't resend a task if (after the tasks was first sent) the application has been deprecated by the project or de-selected by the participant. At least the latter requires the respective task to error out (probably as no reply), and I didn't know from scratch how to do this from within resend_lost_work(). Can anyone else have a look? Best, Bernd ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address. ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address. ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
[boinc_dev] upgrade_db bug
Trying to update the DB I just got: PHP Warning: mysql_pconnect(): Access denied for user 'db_user'@'192.168.0.1' (using password: YES) in /raida/BOINC/projects/EinsteinAtHome/html/inc/util_ops.inc on line 112 Warning: mysql_pconnect(): Access denied for user 'db_user'@'192.168.0.1' (using password: YES) in /raida/BOINC/projects/EinsteinAtHome/html/inc/util_ops.inc on line 112 performing update update_6_5_2014 Doing query: alter table app_version add beta tinyint not null Success. All done. I.e. the update was marked as done although access was denied. This certainly shouldn't happen. While at it, would it be possible that the script reads the DB information from config.xml? This would avoid having to type the password in plain view. Best, Bernd ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] upgrade_db bug
On 06.06.14 08:20, Bernd Machenschalk wrote: While at it, would it be possible that the script reads the DB information from config.xml? This would avoid having to type the password in plain view. On a related note, wouldn't it be _much_ better (i.e. avoid inconsistencies) if the boinc db revision was kept in the DB itself (e.g. in an own table) instead of a file that has no necessary relation to the actual DB state. For transition the upgrade_db script could use max(file,db). Best, Bernd ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] build fail in sched_locality.cpp
Sorry for that. Here's what went wrong: I did not expect the interface of the function app_not_selected() to be changed in a commit commit 52bd196c4f95b4317b38afb2dfed61256d5ce6bb Author: David Anderson da...@ssl.berkeley.edu Date: Mon May 26 21:07:07 2014 -0700 scheduler: fix bugs in sending non-compute-intensive jobs Best, Bernd On 05.06.14 22:05, Bernd Machenschalk wrote: Sorry, I thought I tested at least for compilation, it should even be running on our server. Don't know what went wrong and cannot find out now. Feel free to revert the commit; I'll fix that tomorrow. Sorry again, Bernd On 5. Juni 2014 21:09:52 MESZ, Juha juha.sointus...@gmail.com wrote: Hi sched_locality.cpp: In function ‘int possibly_send_result(SCHED_DB_RESULT)’: sched_locality.cpp:296:28: error: cannot convert ‘DB_WORKUNIT’ to ‘int’ for argument ‘1’ to ‘bool app_not_selected(int)’ Perhaps you were thinking of something like if (app_not_selected(wu.appid)) return ERR_NO_APP_VERSION; (.appid added) -Juha ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address. ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
[boinc_dev] Feature request: resend
Hi! Digging through the app selection stuff in current server code I cam across something I intended to implement but couldn't right away: Don't resend a task if (after the tasks was first sent) the application has been deprecated by the project or de-selected by the participant. At least the latter requires the respective task to error out (probably as no reply), and I didn't know from scratch how to do this from within resend_lost_work(). Can anyone else have a look? Best, Bernd ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] build fail in sched_locality.cpp
Sorry, I thought I tested at least for compilation, it should even be running on our server. Don't know what went wrong and cannot find out now. Feel free to revert the commit; I'll fix that tomorrow. Sorry again, Bernd On 5. Juni 2014 21:09:52 MESZ, Juha juha.sointus...@gmail.com wrote: Hi sched_locality.cpp: In function ‘int possibly_send_result(SCHED_DB_RESULT)’: sched_locality.cpp:296:28: error: cannot convert ‘DB_WORKUNIT’ to ‘int’ for argument ‘1’ to ‘bool app_not_selected(int)’ Perhaps you were thinking of something like if (app_not_selected(wu.appid)) return ERR_NO_APP_VERSION; (.appid added) -Juha ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] may hosts
On 31.01.14 10:30, Rytis Slatkevičius wrote: We had pretty much the same problem. If the cluster nodes retain their network card MAC addresses, version 7.2.33 or newer generates host cpid from MAC address and therefore the scheduler should always match the new host to the old record in the database. Thanks for the note. However, I'm afraid this doesn't work for us: Other clusters run one client per slot (more or less continuously), i.e. CPU core. Therefore we enabled multiple_clients_per_host in the project config, which (as far as I understand the code) prevents the scheduler from searching for matching hosts when attaching a new client. I am also not sure how the VMs of the cluster and their MAC addresses are managed. In case the number of possible MAC adresses is limited, it might be worth to add some custom code to determine the hostid from the MAC address (or CPID in case of recent clients) for specific user accounts (possibly only for single-CPU hosts). I'm still not sure, though, what happens when one task is shifted to a different VM, then the VM that first downloaded it starts another client (and attaches another host). There would be two clients running with the same hostid but different sequence numbers, which would likely lead to a problem e.g. when reporting. One might tackle this special case by adding additional, even more special custom code that only re-uses the id of hosts that have no tasks in progress. Best, Bernd ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] android -- boinc not storing cpu features (/proc/cpuinfo features)
BOINC definitely detects and reports NEON and vfp. Not showing this on
the Einstein@Home web page might be an issue of outdated web code.
Best,
Bernd
Carl Christensen wrote, On 22.08.13 19:52:
Hi, I may be late to this party, but am I right in thinking boinc isn't parsing out the
cpu features on Android? for example my phone supports vfp, vfpv3, and neon, but on my
Einstein@home record it says No coprocessor
should this be a trac item? it seems easy to implement, in the
boinc/client/hostinfo_unix.cpp (I assume that's what android is using), add to
the kFeatures e.g.
static const char *kFeatures[35] = {
fpu, vme, de, pse,
tsc, msr, pae, mce,
cx8, apic, NULL, sep,
mtrr, pge, mca, cmov,
pat, pse36, psnum, clflush,
NULL, ds, acpi, mmx,
fxsr, sse, sse2, ss,
htt, tm, ia64, pbe,
neon, vfpv3, vfp,
};
(and bump up the loops to 35, or maybe have a constant we can just change once)
I would like to know these features at runtime (of course I can just grep
/proc/cpuinfo) as I am working on the benchmarks with vfp neon (if the device
supports it)
I guess an odd thing is fpu should be set on boinc, but you also need vfp,
vfpv3, and neon to figure out which fpu you have!
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
Re: [boinc_dev] OS X apps
This is not a real error message, but merely a warning. As an OpenCL App this probably doesn't depend on other libs in the project- or slot directory, so ignoring DYLD path shouldn't lead to loader errors either. Any hint on what the actual error might be? Best, Bernd Jon Sonntag j...@thesonntags.com schrieb: OS X 10.8.4 reported as Darwin 12.4.0 with BOINC 7.2.5, the user is getting the following error when running an opencl_nvidia plan class workunit: dyld: DYLD_ environment variables being ignored because main executable (/Library/Application Support/BOINC Data/slots/10/../../switcher/switcher) is setuid or setgid The same app works fine using BOINC 7.0.28 with the nVidia 304.00.05f02 drivers for OS X installed on my machine. I am also running OS X 10.8.4. So, has anything changed in the way that apps are launched in recent BOINC versions? Jon Sonntag ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address. ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] Transitioner Error
Your DB schema seems broken. mod_time is an automatic column that should be set by the DB itself, apparently that doesn't happen in your configuration. How did you create the new database? Best, Bernd Kevin Vinsen kevin.vin...@uwa.edu.au schrieb: Folks I've just migrated the POGS project to a new VPC environment in the AWS cloud. Everything started - I could added work units, the transitioner was running, but now it's failing with the following error. [2013/07/18 00:35:01] Executing command: transitioner -d 3 2013-07-18 00:35:02.1015 Starting 2013-07-18 00:35:02.1086 [debug] doing a pass 2013-07-18 00:35:02.1121 [debug] [WU#1903944 IC1339_area1956929] 2 results: unsent 0, in_progress 1, over 1 (success 0, error 0, couldnt_send 0, no_reply 1, didnt_need 0) 2013-07-18 00:35:02.1121 [WU#1903944 IC1339_area1956929] Generating 1 more results (2 target - 0 unsent - 1 in progress - 0 success) Database error: Column 'mod_time' cannot be null query=insert into result values (0, 1374107702, 1903944, 2, 0, 0, 0, 0, 0, 0, 0, 'IC1339_area1956929_2', 0.000e+00, 'file_info nameIC1339_area1956929_2_0/name generated_locally/ upload_when_present/ max_nbytes500/max_nbytes urlhttp://pogs.theskynet.org/pogs_cgi/file_upload_handler/url gzip_when_done/ /file_info result file_ref file_nameIC1339_area1956929_2_0/file_name open_nameoutput.fit/open_name copy_file/ /file_ref /result', '', '', 0, 0, 0, 0.000e+00, 0.000e+00, 0.000e+00, 103216494, 0, 1, 0, 0, 5, null, 0, 0, 0, 0, -1) Anyone any ideas why this is happening? Regards Kevin ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address. ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] CPU throttling and GPU apps
On 04.07.13 13:15, Heinz-Bernd Eggenstein wrote: I guess there are several pros and cons, e.g.: cons: - one one hand, GPU apps (depending on the CPU share?) get a higher OS prio (in terms of niceness) to prevent the GPU being starved. Throttling the CPU might very well cause this starvation - if a GPU app has a rather low CPU runtime share in the first place, further CPU throttling does not seem too useful. - in order to avoid GPU load to interfere with the user doing non-BOINC related stuff, there is already the setting Suspend GPU work while computer is in use. Here's one more: When not synchronized with GPU-CPU communication (kernel launches, data transfer) throtteling an App can break any running GPU task. I'm not sure whether the throtteling implementations of all BOINC Clients that are being used properly honor critical sections, nor am I that all GPU apps of all projects make proper use of these. pros: I can't think about many Actually I can't think about any. Best, Bernd ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] problem/bug in manage_app_versions.php
Jon Sonntag wrote, On 27.06.13 15:48: Why not have the manage app versions page work the same as the manage special users page with an update button per app version? Could work. In principle I would be fine with any solution that could deal with an arbitrary large app_versions table. However in contrast to the manage special users page, for the manage app versions page it's not enough to modify the database table. The changes need to be communicated to the feeder to get into the shared memory. For older versions of the server code touching the reread_db file was enough, in newer versions the manage app versions page recommend to stop and start the whole project for every change (*). I'm not sure you would want to do this for every change you do to every single app version. The current mechanism at least allows to make many changes at once, before making the feeder read the changes. Best, Bernd (*) I'm not sure if that is really necessary, though; I can hardly imagine what should be required beyond stopping the scheduler, restarting the feeder and allowing the scheduler again. But it might be that for most projects restarting the project (including restarting all daemons) is easier and not much slower than just restarting the feeder. Jon Sonntag On Thu, Jun 27, 2013 at 4:48 AM, Bernd Machenschalk bernd.machensch...@aei.mpg.de mailto:bernd.machensch...@aei.mpg.de wrote: Hi! Recently the manage_app_versions.php suddenly messed up our app_version table. All 'deprecated' flags together with all min and max client version specifications were gone (i.e. set to 0). Work was sent out with app versions it was never meant to be. The damage couldn't be repaired using this same page. I spent half a night to manually fix the table in the DB. This could happen to every unsuspecting project at an unforeseeable time, leaving no obvious way to fix it. Here's why: - the form in the page builds a POST string containing elements for ALL rows in the app_versions table, i.e. the size of the POST string grows with the table length - of course the length of the POST buffer is limited (in the Apache configuration IIRC) - the current way the POST string is interpreted has no way to distinguish between a value of zero and a value not being given at all. Consequently all values that are missing e.g. because of a truncated POST string are assumed to be 0 and entered in the DB as such. As there is no way to shorten the POST string, there is not even a way to correct such errors using that page. For us this happened with 436 app versions in the table, but this number is really arbitrary. The length of the (resulting) POST string e.g. depends on how many of these versions are (already) deprecated. Most of our app versions relate to older apps that are now deprecated. So for us and for now the quick workaround was to skip the versions of deprecated apps (patch 0001), both when showing the list and when processing the form. This, however, is dangerous: It relies on the 'deprecated' status not changing between these two queries: when the list to be shown is built and when the updates are performed. In order to prevent the page from completely messing up the table, I added a small check for 'completeness' of the POST string (patch 0002). This adds a hidden element (presumably) at the end of the POST string and prevents any updates from being executed when this end tag didn't make it through. All of these measurements, however, don't really fix the root problem. To do that one would need to rewrite the whole mechanism how the information which updates are to be performed is passed. I don't really have time for this now, maybe someone else has. Best, Bernd ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu mailto:boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address. ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
[boinc_dev] problem/bug in manage_app_versions.php
Hi!
Recently the manage_app_versions.php suddenly messed up our app_version table. All 'deprecated' flags together with all min and max client version
specifications were gone (i.e. set to 0). Work was sent out with app versions it was never meant to be. The damage couldn't be repaired using this
same page. I spent half a night to manually fix the table in the DB.
This could happen to every unsuspecting project at an unforeseeable time,
leaving no obvious way to fix it.
Here's why:
- the form in the page builds a POST string containing elements for ALL rows in the app_versions table, i.e. the size of the POST string grows with
the table length
- of course the length of the POST buffer is limited (in the Apache
configuration IIRC)
- the current way the POST string is interpreted has no way to distinguish
between a value of zero and a value not being given at all.
Consequently all values that are missing e.g. because of a truncated POST string are assumed to be 0 and entered in the DB as such. As there is no way
to shorten the POST string, there is not even a way to correct such errors using that page.
For us this happened with 436 app versions in the table, but this number is really arbitrary. The length of the (resulting) POST string e.g. depends
on how many of these versions are (already) deprecated.
Most of our app versions relate to older apps that are now deprecated. So for us and for now the quick workaround was to skip the versions of
deprecated apps (patch 0001), both when showing the list and when processing the form. This, however, is dangerous: It relies on the 'deprecated'
status not changing between these two queries: when the list to be shown is built and when the updates are performed.
In order to prevent the page from completely messing up the table, I added a small check for 'completeness' of the POST string (patch 0002). This adds
a hidden element (presumably) at the end of the POST string and prevents any updates from being executed when this end tag didn't make it through.
All of these measurements, however, don't really fix the root problem. To do that one would need to rewrite the whole mechanism how the information
which updates are to be performed is passed. I don't really have time for this now, maybe someone else has.
Best,
Bernd
From ef89a6574f59137ce8c863e78e4e045c9a0d81fb Mon Sep 17 00:00:00 2001
From: Bernd Machenschalk bernd.machensch...@ligo.org
Date: Wed, 26 Jun 2013 13:28:45 +
Subject: [PATCH 1/2] manage_app_versions.php: only manage versions of
non-deprecated apps
---
ops/manage_app_versions.php | 6 ++
1 file changed, 6 insertions(+)
diff --git a/ops/manage_app_versions.php b/ops/manage_app_versions.php
index 6244438..09df571 100644
--- a/ops/manage_app_versions.php
+++ b/ops/manage_app_versions.php
@@ -81,6 +81,9 @@ if( !empty($_POST) ) {
$item=mysql_fetch_object($result);
$id=$item-id;
+// skip versions of deprecated apps
+if($app_off[$item-appid]) continue;
+
/* Delete this entry? */
$field=delete_.$id;
if ($_POST[$field]=='DELETE' ) {
@@ -165,6 +168,9 @@ for($j=1;$j=$Nrow;$j++){
$item=mysql_fetch_object($result);
$id=$item-id;
+// skip versions of deprecated apps
+if($app_off[$item-appid]) continue;
+
// grey-out deprecated versions
$f1=$f2='';
if($item-deprecated==1) {
--
1.8.2.3
From b2f351aeaf97b8babd95f2f116c953cefd275922 Mon Sep 17 00:00:00 2001
From: Bernd Machenschalk bernd.machensch...@ligo.org
Date: Thu, 27 Jun 2013 08:52:58 +
Subject: [PATCH 2/2] manage_app_versions.php: added a check for the POST
string not being truncated
---
ops/manage_app_versions.php | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/ops/manage_app_versions.php b/ops/manage_app_versions.php
index 09df571..908317c 100644
--- a/ops/manage_app_versions.php
+++ b/ops/manage_app_versions.php
@@ -74,6 +74,8 @@ $commands=;
if( !empty($_POST) ) {
+ if ( isset($_POST[content]) ($_POST[content]==complete) ) {
+
$result = mysql_query(SELECT * FROM app_version);
$Nrow=mysql_num_rows($result);
@@ -130,6 +132,13 @@ if( !empty($_POST) ) {
} else {
$commands .= Pprecouldn't touch $cwd/../../reread_db/pre/P\n;
}
+
+ } else {
+
+$commands = \nERROR: POST string has been truncated, no action
performed\n;
+$commands .= Increase the POST buffer size, deprecate unused apps or
delete rows from the app_versin table\n\n;
+
+ }
}
@@ -225,7 +234,7 @@ echo trtd colspan=7font color='RED'sup*/sup
end_table();
-
+echo input type=\hidden\ name=\content\ value=\complete\\n;
echo /formP\n;
admin_page_tail();
--
1.8.2.3
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
[boinc_dev] OpenCL on NVidia and device enumeration
Hi! We recently issued our first OpenCL App for NVidia devices and ran into a problem with device assignment. When there are two NVidia devices capable of OpenCL in the system, a (recent) Client (correctly) starts two such tasks, but both end up actually running on the same devices while the other being idle. Here are some details that may or may not help to track down the problem: - BOINC Client version 7.0.28 - the two tasks correctly get additional command-line arguments --device 0 and --device 1 respectively. - init_data.xml of the two tasks contain gpu_typeNVIDIA/gpu_type gpu_device_num0/gpu_device_num gpu_opencl_dev_index0/gpu_opencl_dev_index and gpu_typeNVIDIA/gpu_type gpu_device_num1/gpu_device_num gpu_opencl_dev_index1/gpu_opencl_dev_index respectively - the App was built with BOINC 9bef2edbf0fd6b9da2c282735935ce1b27727ddc (in current git-v2 repo, last commit was Charlie's Fix file permissions of Jan 11) - we have OpenCL Apps for ATI/AMD out there for years without such problems. Did any other project observe something similar? Any idea what the problem is and how to solve it? When we (Einstein@Home BOINC) developed OpenCL support in BOINC, we found that device detection and particularly device enumeration is highly difficult and fragile, possibly even non-deterministic, especially when it comes to OpenCL (*). Therefore we agreed on the following scheme: - the Client compiles and maintains a canonical (enumerated!) list of devices, (e.g. in a shared memory) - the apps are communicated an index to that list (e.g. via --device CLA) - there will be API functions that get the relevant device properties (device_ids or whatever) FROM THAT LIST based on the communicated index - this way no App should ever attempt or be required to try a device enumeration itself, as it might end up with a very different list than what the Client has Looking into boinc_get_opencl_ids_aux() in boinc_opencl.cpp I see that this agreement has apparently been completely ignored at least in the current implementation. Had there ever been an implementation of this agreement? If so, why and when was is dropped? If not, why not? Best, Bernd (*) The (IMHO horrible) truth is that according to OpenCL standard not even two subsequent calls to clGetDeviceIDs() in the same process necessarily return the OpenCL devices in the same order. In most implementations they might, but I could also imagine a driver that instead of traversing the whole PCI/PCI-bridge/Thunderbolt/USB/whatever tree (which also isn't as static as the author of the driver might think) in a deterministic way it just broadcasts a call and returns the devices in the order of arrival of replies. ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] OpenCL on NVidia and device enumeration
Hi Charlie!
On 25.04.13 12:46, Charlie Fenton wrote:
How is your application determining the cl_platform_id and cl_device_id of the
GPU assigned by the client?
It calls boinc_get_opencl_ids(cl_device_id* device, cl_platform_id* platform). As we allow OpenCL Apps only for Clients = 7.0.24, this shouldn't make
any difference to the newer function that adds support for Clients older than 7.0.12. Ultimately both functions call boinc_get_opencl_ids_aux() with
the info they got from init_data anyway.
You should be using the api/boinc_opencl.cpp from March 4 (boinc 7.0.45) or
later. The version of api/boinc_opencl.cpp from January 11 is deprecated.
The complete diff from current master HEAD and the version we were using
(tagged current_fgrp_apps) is:
git diff current_fgrp_apps ./api/boinc_opencl.cpp
diff --git a/api/boinc_opencl.cpp b/api/boinc_opencl.cpp
index 80b87a8..a2763fc 100644
--- a/api/boinc_opencl.cpp
+++ b/api/boinc_opencl.cpp
@@ -59,8 +59,9 @@ int get_vendor(cl_device_id device_id, char* vendor, int len)
{
retval = clGetDeviceInfo(
device_id, CL_DEVICE_VENDOR, len, vendor, NULL
);
-if ((retval != CL_SUCCESS) || (strlen(vendor)==0)) return retval;
-
+if (retval != CL_SUCCESS) return retval;
+if (!strlen(vendor)) return CL_INVALID_DEVICE_TYPE;
+
if ((strstr(vendor, AMD)) ||
(strstr(vendor, Advanced Micro Devices, Inc.))
) {
@@ -75,7 +76,6 @@ int get_vendor(cl_device_id device_id, char* vendor, int len)
{
strcpy(vendor, GPU_TYPE_INTEL); // intel_gpu
}
-if (!strlen(vendor)) return CL_INVALID_DEVICE_TYPE;
return 0;
}
I don't see any change in there that could have any effect on the issue in question. We certainly can rebuild the App with current master HEAD,
publish it and see if it fixes the problem, but that's another day of work wasted if this doesn't help.
We discovered some time ago that the use of a single device number is overly
simplistic and problematic, because not all CUDA GPUs are recognized by OpenCL
on the Mac, and not all CAL-capable GPUs support openCL. All BOINC GPU apps
must use api/boinc_opencl.cpp to get the cl_platform_id and cl_device_id of the
GPU assigned by the client.
Yep, but our currrent problem happens neither on a Mac nor with ATI, and we do use the API function and don't handle --device on out own (for OpenCL
Apps).
Does this answer your questions?
I'm afraid it doesn't solve the problem.
We _do_ use the API function in question and init_data.xml _does_ contain reasonable values for the GPU tags; however for one device
boinc_get_opencl_ids() appears to return the wrong cl_device_id. The only thing that IMHO can go wrong there is the device enumeration in the API
function.
Best,
Bernd
Footnote: Could you name the sha1 of the commit you are referring to?
The tag current_fgrp_apps actually sits on commit
9bef2edbf0fd6b9da2c282735935ce1b27727ddc
This commit is a merge commit that Oliver rebuild on March 4 from the original merge commit c43ee0869234f400b99f8a16dff276017ba0b480 in the v1 repo,
which also carries the timestamp of Jan 11. If you type 'git log' and scroll down to 9bef2edbf0fd6b9da2c282735935ce1b27727ddc (which is tagged March
4), you will see other commits on top of that, beginning with 657c0f9730f0796724875433f12a3d92494b2973 from David of Jan 11. So the original merge
actually also happened on Jan 11, although the commit reconstructed for boinc-git-v2 lists Mar 4.
On Apr 25, 2013, at 12:43 AM, Bernd Machenschalk wrote:
Hi!
We recently issued our first OpenCL App for NVidia devices and ran into a
problem with device assignment.
When there are two NVidia devices capable of OpenCL in the system, a (recent)
Client (correctly) starts two such tasks, but both end up actually running on
the same devices while the other being idle.
Here are some details that may or may not help to track down the problem:
- BOINC Client version 7.0.28
- the two tasks correctly get additional command-line arguments --device 0 and
--device 1 respectively.
- init_data.xml of the two tasks contain
gpu_typeNVIDIA/gpu_type
gpu_device_num0/gpu_device_num
gpu_opencl_dev_index0/gpu_opencl_dev_index
and
gpu_typeNVIDIA/gpu_type
gpu_device_num1/gpu_device_num
gpu_opencl_dev_index1/gpu_opencl_dev_index
respectively
- the App was built with BOINC 9bef2edbf0fd6b9da2c282735935ce1b27727ddc (in current
git-v2 repo, last commit was Charlie's Fix file permissions of Jan 11)
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
[boinc_dev] schedulers
Hi! It looks like there are two different, independent places where a cgi / scheduler URL is set: - cgi_url in the project config - html/user/schedulers.txt - Digging through the code I found nothing that actually uses the URL set in the project config. Is there anything where this is being used? - The name schedulers.txt implies that is is possible to specify more than one scheduler. Is is? If so, how would you do this? How would the Client react to that? Is any project already using this? If anything is changed I would much prefer to configure the scheduler(s) in the project config than in yet another file in the html tree. Best, Bernd ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] Report on use of Berkeley Android for BOINC.
Would it be possible with reasonable effort to - have the slots directory on internal memory - (possibly) have the projects directory on external storage - copy all executables to the slot, link all other files ? Bernd David Anderson da...@ssl.berkeley.edu schrieb: In BOINC for Android, one of the goals is to dynamically download and run client applications, as on other platforms. Android external storage, by default, can't be used for executable files. So the boinc/projects/ directory must be on internal storage. Notes: - in principle we could split the project directories: one part for executables, another for data files. Data files could go on external storage. However, this would be a large rewrite. - slot directories could go on external storage, but there's no advantage because they just contain links to the project directory. On 12-Mar-2013 12:25 PM, Rom Walton wrote: IIRC, the default mode of operation for NativeBOINC is to run all applications as anonymous platform applications. From an eco-system perspective it kind of limits NativeBOINC to running applications that are OSS software. Now this is probably the result of a chicken/egg problem where projects were not quite as ready to jump on the Android bandwagon. Anonymous platform was the only route left open. Several projects use software that is not OSS software in nature. Anyways, we'll be flipping the bit that allows for external memory installs And see what happens. According to this (section: android:installLocation) http://developer.android.com/guide/topics/manifest/manifest-element.html even if the apk file is stored on the SD card, the data directory which allows for native applications to have the execute bit set, is still setup in internal memory. So it may well be that NativeBOINC and the BOINC package we are putting together have the same limitations as far as phones with smaller memory sizes goes. Or they may both be operating under a different set of constraints due to how project applications are installed with the anonymous platform mechanism. We just need to try and see what happens. - Rom -Original Message- From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of Raistmer the Sorcerer Sent: Tuesday, March 12, 2013 6:51 AM To: Jorden van der Elst Cc: BOINC Dev Mailing List Subject: Re: [boinc_dev] Report on use of Berkeley Android for BOINC. Does official BOINC supports installation on SD card instead of inner phone memory? NativeBOINC does. And w/o this feature such BOINC just useless for vast majority of smartphones (no direct access to inner memory, too low amount of inner memory and so on and so forth). Actually current NativeBOINC state is close to perfection from features point of view. User can just crunch with it, not to fight with some missings and bugs. The main issue now is lack of scientific applications ports. Вторник, 12 марта 2013, 11:37 +01:00 от Jorden van der Elst els...@gmail.com: Hi all, In http://boinc.berkeley.edu/dev/forum_thread.php?id=8246 the user NullCoding writes: Cutting to the chase: I was unable to find any information about how to run BOINC on Android - specifically, using the official Berkeley installer (.apk) on not a tablet, but a smartphone. Granted, my particular phone is often referred to as a fablet (or phablet?) i.e. phone-tablet, as it's rather large in size. The screen itself is larger than an iPhone 4S. I have an HTC Droid DNA, which is comparable to the perhaps more commonly-seen Samsung Galaxy SIII. They are like a Nikon DSLR and a Canon DSLR. When it comes to brass tacks, hard to pick a clear winner. In any case I happen to know my phone has a quad-core CPU. Granted, I'm not entirely sure there are even any apps for Android in existence which can actually address all four...but I thought that if anything could, it'd be BOINC (hopefully). I also happen to know that many, many people run / have run / continue to run BOINC on their smartphones - often models older than mine! However, I installed the BOINC package from Berkeley (which I do recognize is a development release) and attached to a few projects that I knew to support Android. All I'm getting is This project does not support computers of type arm-android-linux-gnu. hmm? That and there's no way to edit computing preferences (I will NOT root my device - afraid I can't go into the exact reasons here though) that I can see, so for all I know it IS recognizing four cores but only using one, which I believe is the default setup (use 0% of multi-core systems, i.e one core) Here is my host at SubSetSum, which was specifically recommended to me for Android. Here is another host at the same project with what appears to be an older (albeit apparently faster) CPU as well as an older OS, and it's gotten more credit than my quad-core i5-2350M 2,3GHz has in less calendar time! O_o What on earth am
Re: [boinc_dev] [boinc_alpha] Boinc switch proposal
That would better go to boinc_dev, I think. Bernd Gianfranco Costamagna wrote, On 06.03.13 14:09: Hi everybody, since some days I'm thinking about your switch to git, with the benefits that this has implied. Anyway this approach still have some problems e.g.: - there is no automatic tag at each release, with a link for the source downloading. - people cannot contribute. Sometimes I get some wrong code on my way when I package boinc, and I maybe just want to send you the patch for review, but sometimes is easier to push it debian side, with the only benefit of debian/ubuntu people. I recently became a developer of ettercap, and we switched from svn to github. The community has increased, and every people intrested forked our repository and each 2-3 days we get pull requests of minor/major bug fixes. Of course we need to review them and accept/deny them, but this is an approach that has speed up the process of development and bug fixing. My opinion is that boinc could approach a similar way, and I'm pretty sure this will come with a real big benefit of every user on this community. By the way github also gives an automatic tagging system https://github.com/Ettercap/ettercap/tags Thanks for your time Just my 0.02 $ Gianfranco ___ boinc_alpha mailing list boinc_al...@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_alpha To unsubscribe, visit the above URL and (near bottom of page) enter your email address. ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] BOINC-v2 Git Repo Updated
Hi Rom! Oliver Bock wrote, On 04.03.13 14:40: At some point (rather sooner than later) we should decide how we're going to continue in order to avoid doubling the effort. In my migration attempt so far I didn't have to manually edit any patches for the reasons you described, naturally avoiding any accidental changes of content (incl. whitespaces). My approach also doesn't linearize/flatten history or change the order of things. I prefer Olivers approach of changing the current history as little as possible. The main reason is that there might work already been done based on the current history, e.g. branches. The more changes you make to the old history, the less likely it is that in the new history you will find a point (i.e. commit) that corresponds to the state of the whole tree that your previous work refers to, e.g. the commit where your branch forks off, and which you could use to re-implant your branches to. Since we, E@H, really do care about BOINC's code base and history I could offer to continue my effort until our repo is in sync with upstream. I would vote for accepting the offer and let Oliver finish the migration. Best, Bernd ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] boinc_finish(0) crash elimination
This might or might not be related: When a (Mac OS X in this case, output is from an attached gdb) program terminates after a short time, presumably before it received the first hearbeat, apparently the timer thread crashes: 2013-02-19 16:58:53.3629 (10894) [normal]: done. calling boinc_finish(0). 16:58:53 (10894): called boinc_finish Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x1000 [Switching to process 10894 thread 0x1603] 0x000f156b in MSG_CHANNEL::get_msg () $1 = unknown type #0 0x000f156b in MSG_CHANNEL::get_msg () #1 0x000ef2a7 in handle_heartbeat_msg () #2 0x000f02a6 in timer_thread () #3 0x98886ed9 in _pthread_start () #4 0x9888a6de in thread_start () (gdb) SIGBUS: bus error Could that be that something in handle_heartbeat_msg() needs to be protected? Best, Bernd ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] MinGW boinc_zip updates
Hi Daniel! Did this use (i.e. test) the zip library in any way? Best, Bernd On 07.02.13 16:18, Daniel Carrion wrote: I've loaded it up on the test machine using project anonymous platform feature. Below is stderr output from wrapper: - daniel@SNM-WIN01 /C/ProgramData/BOINC/slots/0 $ tail -f stderr.txt wrapper: starting 02:13:04 (1712): wrapper: running ../../projects/ec2-23-23-126-96.compute-1.amazonaws.com_pogs/fit_sed (1 filters.dat observations.dat) - Seems to be working properly... We'll now for sure once the jobs complete. Cheers Daniel On Fri, Feb 8, 2013 at 2:01 AM, Bernd Machenschalk bernd.machensch...@aei.mpg.de mailto:bernd.machensch...@aei.mpg.de wrote: On 07.02.13 14:59, Daniel Carrion wrote: Great work! That's done the trick. I did a clean compile with make -f Makefile.mingw wrapper without previously building other boinc libraries. Good to know that it compiles! Next thing would be to test whether the zip library and the wrapper that were built this way actually work as they should. I never used the wrapper at all and barely know that it exists; neither did I use boinc_zip in the past ~6y or have any code at hand that uses it. Best, Bernd ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
[boinc_dev] Download App start errors
Hi! Whenever we issue a new app version we get a lot of Download errors and ERR_RESULT_START Client errors. On computer with a rather slow internet connection (Mac OS PPC, thus with an old BOINC Client 6.12) I recently noticed that the client already started a task after downloading the data files, but while the application binary was incomplete and still being downloaded. Could it be that nowadays clients still do that? Where's the code that determines whether all the files necessary to start a tasks have been downloaded? Best, Bernd ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
[boinc_dev] Feature request: glibc version in Linux os_version
In Linux Clients, put the glibc version in the os_version instead of the kernel name. If at all, the kernel name could be appended to the os_name. Currently the os_version lists the kernel name, which is completely arbitrary (e.g. it doesn't even need to contain the (correct) kernel version) and is irrelevant for building applications. The thing relevant for linking applications is instead the (g)libc version. The kernel name may give a hint at best. We currently determine the glibc version in the application and log it to stderr_out to at least get an overview, but it would be much more helpful if we could get this in the host table, e.g. to add a filter for plan classes. Here's the code that we use in the App: /* for glibc version */ #ifdef __GLIBC__ #define _GNU_SOURCE #include gnu/libc-version.h #endif #ifdef __GLIBC__ /* log the glibc version */ fprintf(stderr, glibc version/release: %s/%s\n, gnu_get_libc_version(), gnu_get_libc_release()); #endif I suppose this still works in the distros that recently dropped glibc in favor of eglibc, but can anyone confirm this? Best, Bernd ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] MinGW boinc_zip updates
Hi Daniel ( David)! On 07.02.13 04:59, Daniel Carrion wrote: Looks like it was trying to compile lib\util.cpp instead of zip\zip\util.c? Added z_util.o instead to the LIB_OBJS definition. Also noticed a bunch of zf* functions missing (e.g. zftello)...Haven't really followed how they link up... There are a couple of oddities in the linking line: 1. are you sure you want to use the standard g++ of a Linux system? Have you linked / aliased that to the correct cross-compiler? 2. This line is trying to link a static version of libstdc++, which makes sense for Linux, but not for a Windows cross-compile. FWIW I set AR=i586-mingw32msvc-ar CC=i586-mingw32msvc-gcc CXX=i586-mingw32msvc-g++ (on a debian squeeze with standard mingw32 installation) before using the Makefile. David, the previous patch was intended for Daniel to test whether it works or not because I didn't have the resources to test it myself. I would have committed it to master when I was sure it does work as it is. However it turns out it didn't. So I'll continue to send some patches to Daniel for testing (and CCing the list for comments) until we found something that works for him (and me), which could then be committed to the official BOINC repo. As the previous patch was already committed to the master branch, here's another one that must be applied on to of it. I guess the wrapper will be a rather common thing to build with whatever environment, so I added a 'wrapper' target to the Makefile for convenience. However, this looks increasingly misplaced in lib/, maybe we should move the Makefile.mingw to the win_build/ directory at some point. The second patch is not necessary for the boinc_zip or wrapper build, it is just something that makes the list of libboinc objects better readable and maintainable. So with the attached patches and the above settings 'make -f Makefile.mingw wrapper' should build you a wrapper.exe. At least it does for me without errors. Let me know how it goes. Best, Bernd From 9c25b586bdf1948c4380c8bb03b70e0117f63392 Mon Sep 17 00:00:00 2001 From: Bernd Machenschalk bernd.machensch...@ligo.org Date: Thu, 7 Feb 2013 13:01:06 +0100 Subject: [PATCH 1/2] fix Makefile.mingw for recent boinc_zip #2 --- lib/Makefile.mingw | 99 +++- 1 files changed, 59 insertions(+), 40 deletions(-) diff --git a/lib/Makefile.mingw b/lib/Makefile.mingw index b23fb80..dbc9e44 100644 --- a/lib/Makefile.mingw +++ b/lib/Makefile.mingw @@ -51,37 +51,38 @@ LIB_OBJ = util.o win_util.o app_ipc.o diagnostics.o diagnostics_win.o filesys.o hostinfo.o md5.o md5_file.o mem_usage.o mfile.o miofile.o procinfo_win.o procinfo.o proc_control.o parse.o prefs.o \ proxy_info.o str_util.o shmem.o base64.o stackwalker_win.o url.o coproc.o -ZIP_OBJ = boinc_zip.o \ - api.o \ - apihelp.o \ - crc32.o \ - explode.o \ - extract.o \ - fileio.o \ - globals.o \ - inflate.o \ - list.o \ - match.o \ - nt.o \ - process.o \ - ttyio.o \ - unreduce.o \ - unshrink.o \ - unzip.o \ - win32.o \ - zipinfo.o \ - deflate.o \ - trees.o \ - util.o \ - win32_boinc.o \ - win32i64.o \ - win32zip.o \ - z_fileio.o \ - z_globals.o \ - z_nt.o \ - zip.o \ - zipfile.o \ - zipup.o +ZIP_OBJ = zip/boinc_zip.o \ + zip/api.o \ + zip/apihelp.o \ + zip/crc32.o \ + zip/crypt.o \ + zip/explode.o \ + zip/extract.o \ + zip/fileio.o \ + zip/globals.o \ + zip/inflate.o \ + zip/list.o \ + zip/match.o \ + zip/nt.o \ + zip/process.o \ + zip/ttyio.o \ + zip/unreduce.o \ + zip/unshrink.o \ + zip/unzip.o \ + zip/zipinfo.o \ + zip/deflate.o \ + zip/trees.o \ + zip/util.o \ + zip/win32.o \ + zip/win32_boinc.o \ + zip/win32i64.o \ + zip/win32zip.o \ + zip/z_fileio.o \ + zip/z_globals.o \ + zip/z_nt.o \ + zip/zip.o \ + zip/zipfile.o \ + zip/zipup.o # libraries to build API_BIN = libboinc_api.a @@ -116,7 +117,10 @@ CCXXFLAGS = $(INCS) $(DEBUG) --include $(BOINC_SRC)/version.h -DEINSTEINATHOME_C -DNODB -D_CONSOLE -fexceptions $(OPTFLAGS) $(NOCYGWIN) # flags for compiling boinc_zip -ZIP_FLAGS = -DWIN32 -D_LIB -D_MBCS -DNO_MKTEMP $(INCS) -O2 -DDLL -DUSE_ZIPMAIN $(NOCYGWIN) +BOINC_ZIP_VCPROJ_FLAGS = -DWIN32 -D_LIB -DDLL -D_CRT_SECURE_NO_WARNINGS -DNO_MKTEMP -DUSE_ZIPMAIN -DNO_CRYPT \ + -DIZ_PWLEN=80 -DNO_ASM -DNO_UNICODE_SUPPORT -Dinflate=inflate_boinc -Ddeflate=deflate_boinc \ + -Dget_crc_table=get_crc_table_boinc -Dlongest_match=longest_match_boinc -Dinflate_codes=inflate_codes_boinc +ZIP_FLAGS = $(BOINC_ZIP_VCPROJ_FLAGS) -DUSE_MINGW_GLOBBING -DUSE_STRM_INPUT $(INCS) -O2 $(NOCYGWIN) # LDFLAGS = -lwinmm @@ -133,6 +137,11 @@ all-la
Re: [boinc_dev] MinGW boinc_zip updates
On 07.02.13 13:31, Bernd Machenschalk wrote: As the previous patch was already committed to the master branch, here's another one that must be applied on to of it. I guess the wrapper will be a rather common thing to build with whatever environment, so I added a 'wrapper' target to the Makefile for convenience. However, this looks increasingly misplaced in lib/, maybe we should move the Makefile.mingw to the win_build/ directory at some point. The second patch is not necessary for the boinc_zip or wrapper build, it is just something that makes the list of libboinc objects better readable and maintainable. Hm. The patches on the list are messed up the same way as the last one. Some MTA stumbled upon a 'From ' line in the attachments and made it 'From ' Sending again, stripped of first line. Bernd From: Bernd Machenschalk bernd.machensch...@ligo.org Date: Thu, 7 Feb 2013 13:01:06 +0100 Subject: [PATCH 1/2] fix Makefile.mingw for recent boinc_zip #2 --- lib/Makefile.mingw | 99 +++- 1 files changed, 59 insertions(+), 40 deletions(-) diff --git a/lib/Makefile.mingw b/lib/Makefile.mingw index b23fb80..dbc9e44 100644 --- a/lib/Makefile.mingw +++ b/lib/Makefile.mingw @@ -51,37 +51,38 @@ LIB_OBJ = util.o win_util.o app_ipc.o diagnostics.o diagnostics_win.o filesys.o hostinfo.o md5.o md5_file.o mem_usage.o mfile.o miofile.o procinfo_win.o procinfo.o proc_control.o parse.o prefs.o \ proxy_info.o str_util.o shmem.o base64.o stackwalker_win.o url.o coproc.o -ZIP_OBJ = boinc_zip.o \ - api.o \ - apihelp.o \ - crc32.o \ - explode.o \ - extract.o \ - fileio.o \ - globals.o \ - inflate.o \ - list.o \ - match.o \ - nt.o \ - process.o \ - ttyio.o \ - unreduce.o \ - unshrink.o \ - unzip.o \ - win32.o \ - zipinfo.o \ - deflate.o \ - trees.o \ - util.o \ - win32_boinc.o \ - win32i64.o \ - win32zip.o \ - z_fileio.o \ - z_globals.o \ - z_nt.o \ - zip.o \ - zipfile.o \ - zipup.o +ZIP_OBJ = zip/boinc_zip.o \ + zip/api.o \ + zip/apihelp.o \ + zip/crc32.o \ + zip/crypt.o \ + zip/explode.o \ + zip/extract.o \ + zip/fileio.o \ + zip/globals.o \ + zip/inflate.o \ + zip/list.o \ + zip/match.o \ + zip/nt.o \ + zip/process.o \ + zip/ttyio.o \ + zip/unreduce.o \ + zip/unshrink.o \ + zip/unzip.o \ + zip/zipinfo.o \ + zip/deflate.o \ + zip/trees.o \ + zip/util.o \ + zip/win32.o \ + zip/win32_boinc.o \ + zip/win32i64.o \ + zip/win32zip.o \ + zip/z_fileio.o \ + zip/z_globals.o \ + zip/z_nt.o \ + zip/zip.o \ + zip/zipfile.o \ + zip/zipup.o # libraries to build API_BIN = libboinc_api.a @@ -116,7 +117,10 @@ CCXXFLAGS = $(INCS) $(DEBUG) --include $(BOINC_SRC)/version.h -DEINSTEINATHOME_C -DNODB -D_CONSOLE -fexceptions $(OPTFLAGS) $(NOCYGWIN) # flags for compiling boinc_zip -ZIP_FLAGS = -DWIN32 -D_LIB -D_MBCS -DNO_MKTEMP $(INCS) -O2 -DDLL -DUSE_ZIPMAIN $(NOCYGWIN) +BOINC_ZIP_VCPROJ_FLAGS = -DWIN32 -D_LIB -DDLL -D_CRT_SECURE_NO_WARNINGS -DNO_MKTEMP -DUSE_ZIPMAIN -DNO_CRYPT \ + -DIZ_PWLEN=80 -DNO_ASM -DNO_UNICODE_SUPPORT -Dinflate=inflate_boinc -Ddeflate=deflate_boinc \ + -Dget_crc_table=get_crc_table_boinc -Dlongest_match=longest_match_boinc -Dinflate_codes=inflate_codes_boinc +ZIP_FLAGS = $(BOINC_ZIP_VCPROJ_FLAGS) -DUSE_MINGW_GLOBBING -DUSE_STRM_INPUT $(INCS) -O2 $(NOCYGWIN) # LDFLAGS = -lwinmm @@ -133,6 +137,11 @@ all-la: $(BIN) $(API_LIB) .PHONY: boinc_zip boinc_zip: $(ZIP_BIN) +.PHONY: wrapper +wrapper: wrapper.exe +wrapper.exe: wrapper.o regexp.o regsub.o regerror.o regexp_memory.o regexp_report.o $(API_BIN) $(LIB_BIN) $(ZIP_BIN) +$(CXX) $(CPPFLAGS) $(CXXFLAGS) -o $@ $^ -lpsapi + # set to the target tools when cross-compiling RANLIB ?= ranlib LIBTOOL ?= libtool @@ -148,8 +157,8 @@ $(LIB_BIN): $(LIB_OBJ) $(AR) rc $@ $^ $(GPH_BIN): $(GPH_OBJ) $(AR) rc $@ $^ -$(ZIP_BIN): $(ZIP_OBJ) - $(AR) rc $@ $^ +$(ZIP_BIN): zip $(ZIP_OBJ) + $(AR) rc $@ $(ZIP_OBJ) # standard BOINC code - .C and .cpp versions %.o: $(BOINC_SRC)/api/%.C @@ -160,27 +169,37 @@ $(ZIP_BIN): $(ZIP_OBJ) $(CXX) -c $ -o $@ $(CPPFLAGS) $(CXXFLAGS) %.o: $(BOINC_SRC)/lib/%.cpp $(CXX) -c $ -o $@ $(CPPFLAGS) $(CXXFLAGS) + +# libtool libboinc_api %.lo: $(BOINC_SRC)/api/%.cpp $(LIBTOOL) --mode=compile --tag=CXX $(CXX) -c $ -o $@ $(CPPFLAGS) $(CXXFLAGS) %.lo: $(BOINC_SRC)/lib/%.cpp $(LIBTOOL) --mode=compile --tag=CXX $(CXX) -c $ -o $@ $(CPPFLAGS) $(CXXFLAGS) +# for the wrapper +wrapper.o: $(BOINC_SRC)/samples/wrapper/wrapper.cpp + $(CXX) -c $ -o $@ $(CPPFLAGS) $(CXXFLAGS) +%.o: $(BOINC_SRC)/samples/wrapper/%.c + $(CC
Re: [boinc_dev] MinGW boinc_zip updates
On 07.02.13 14:59, Daniel Carrion wrote: Great work! That's done the trick. I did a clean compile with make -f Makefile.mingw wrapper without previously building other boinc libraries. Good to know that it compiles! Next thing would be to test whether the zip library and the wrapper that were built this way actually work as they should. I never used the wrapper at all and barely know that it exists; neither did I use boinc_zip in the past ~6y or have any code at hand that uses it. Best, Bernd ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] MinGW boinc_zip updates
Hi Daniel! Thanks. Apparently either my mailer or the list server messed up the patch attached to last mail, I had to manually delete the first line (starting with From) to make it work. Let me know the error message that you get when linking. Best, Bernd Daniel Carrion wrote, On 06.02.13 13:12: Hi Bernd Thanks for that. Sorry for the delay - been preoccupied with a few things. Couldn't apply patch automatically so had to do the changes manually. Builds zip library archive fine. Wrapper fails to build with undefined reference errors when using libboinc_zip.a. Haven't done any more than that. Will jump back onto it soon. Cheers Daniel On Tue, Feb 5, 2013 at 10:10 PM, Bernd Machenschalk bernd.machensch...@aei.mpg.de mailto:bernd.machensch...@aei.mpg.de wrote: Hi! On 27.01.13 17:07, Bernd Machenschalk wrote: I'll try to get this working myself when I find the time. I tend to believe that there is something (Makefile, batch script) in the zip tree, but it's been a long time since I last looked into it. I'll get back to you. I finally came around to do this. boinc_zip now builds cleanly for me, however I currently don't have anything ready that really links it, so there might still be something missing. Please try the attached patch, and tell me how it worked. Best, Bernd ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] MinGW boinc_zip updates
Hi! On 27.01.13 17:07, Bernd Machenschalk wrote: I'll try to get this working myself when I find the time. I tend to believe that there is something (Makefile, batch script) in the zip tree, but it's been a long time since I last looked into it. I'll get back to you. I finally came around to do this. boinc_zip now builds cleanly for me, however I currently don't have anything ready that really links it, so there might still be something missing. Please try the attached patch, and tell me how it worked. Best, Bernd From 504ff43976b992a010158e816b402a68fb7536e3 Mon Sep 17 00:00:00 2001 From: Bernd Machenschalk bernd.machensch...@ligo.org Date: Tue, 5 Feb 2013 12:05:49 +0100 Subject: [PATCH] fix Makefile.mingw for recent boinc_zip --- lib/Makefile.mingw | 39 +-- 1 files changed, 33 insertions(+), 6 deletions(-) diff --git a/lib/Makefile.mingw b/lib/Makefile.mingw index 6a1c5bc..b23fb80 100644 --- a/lib/Makefile.mingw +++ b/lib/Makefile.mingw @@ -51,11 +51,37 @@ LIB_OBJ = util.o win_util.o app_ipc.o diagnostics.o diagnostics_win.o filesys.o hostinfo.o md5.o md5_file.o mem_usage.o mfile.o miofile.o procinfo_win.o procinfo.o proc_control.o parse.o prefs.o \ proxy_info.o str_util.o shmem.o base64.o stackwalker_win.o url.o coproc.o -ZIP_OBJ = boinc_zip.o z_win32.o win32zip.o zipup.o zipfile.o zip.o z_globals.o z_fileio.o \ - z_util.o trees.o deflate.o zipinfo.o win32.o unzip.o unshrink.o unreduce.o ttyio.o \ - process.o match.o list.o inflate.o globals.o fileio.o extract.o explode.o envargs.o \ - crctab.o crc32.o apihelp.o api.o - +ZIP_OBJ = boinc_zip.o \ + api.o \ + apihelp.o \ + crc32.o \ + explode.o \ + extract.o \ + fileio.o \ + globals.o \ + inflate.o \ + list.o \ + match.o \ + nt.o \ + process.o \ + ttyio.o \ + unreduce.o \ + unshrink.o \ + unzip.o \ + win32.o \ + zipinfo.o \ + deflate.o \ + trees.o \ + util.o \ + win32_boinc.o \ + win32i64.o \ + win32zip.o \ + z_fileio.o \ + z_globals.o \ + z_nt.o \ + zip.o \ + zipfile.o \ + zipup.o # libraries to build API_BIN = libboinc_api.a @@ -90,7 +116,7 @@ CCXXFLAGS = $(INCS) $(DEBUG) --include $(BOINC_SRC)/version.h -DEINSTEINATHOME_C -DNODB -D_CONSOLE -fexceptions $(OPTFLAGS) $(NOCYGWIN) # flags for compiling boinc_zip -ZIP_FLAGS = -DWIN32 -D_LIB -D_MBCS -DNO_MKTEMP $(INCS) -O2 -DDLL $(NOCYGWIN) +ZIP_FLAGS = -DWIN32 -D_LIB -D_MBCS -DNO_MKTEMP $(INCS) -O2 -DDLL -DUSE_ZIPMAIN $(NOCYGWIN) # LDFLAGS = -lwinmm @@ -104,6 +130,7 @@ all: $(BIN) $(API_BIN) all-la: $(BIN) $(API_LIB) # zip target +.PHONY: boinc_zip boinc_zip: $(ZIP_BIN) # set to the target tools when cross-compiling -- 1.7.2.5 ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
[boinc_dev] Client's open file descriptors inherited by application?
Hi! It looks like our applications inherit the client's file descriptors that are open at the time of application launch, in particular the ones that refer to external TCP connections: http://einstein.phys.uwm.edu/forum_thread.php?id=9925 Is that really what happens, and, if so, could this be avoided? Best, Bernd ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] MinGW boinc_zip updates
Hi Daniel! Thanks for the update. The boinc_zip stuff in the Makefile.mingw is left over from an old version of boinc_zip that was removed from the boinc source tree. As nobody complained so far I think that no one (else) is actually compiling boinc_zip with MinGW. We, who originally put that in the Makefile.mingw, have by now switched to using zlib, and thus don't need it anymore. If you need it and want to adapt the Makefile to the newly added boinc_zip, I'd happily incorporate your updates or patches. Best, Bernd Daniel Carrion wrote, On 26.01.13 14:27: Just a quick one just to check if lib/Makefile.mingw is due for an update to accommodate recent zip changes? No issues compiling the main libraries, just boinc_zip. I'm working through it now to get it working and noticed a few things. E.g. ZIP_OBJ doesn't reflect what exists, error finding zipmain def in boinc_zip.cpp. End result is undefined reference errors when going to compile boinc_zip. Not a biggie as I can get around it but thought I should give a heads up in case someone wants to update it for the mingw users that want to compile boinc_zip lib. -- Daniel ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address. ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] MultiHost
Hi David! On 15.12.12 21:09, David Anderson wrote: Bernd: Thanks; I checked in these changes. However, I don't really understand them (e.g. the need for aproject_dir element in config.xml). When you get a chance, can you please update the documentation on this? http://boinc.berkeley.edu/trac/wiki/MultiHost#Runserverdaemonsandtasksonmultiplehosts Assume the following setup: The main project server myserver keeps the project directory in /nfs/export/boinc/projects/MyProject and exports /nfs/export/boinc Secondary project servers (auto)mount that directory to the local path /auto/myserver/boinc You would usually put symlinks to the paths on the servers, like /boinc - /nfs/export/boinc or /boinc - /auto/myserver/boinc respectively, to get a consistent path on all servers The problem that occurred with the previous code was that in the Python start script and the server status page the project (or bin directory) path was determined by getcwd() or similar, which on myserver above yielded /nfs/export/boinc/projects/MyProject, a path that didn't exist on the secondary servers. However this path was used to construct e.g. the command-line for ssh command executed on the remote servers, which didn't work. You can now add project_dir to the config file to force both the server status page and the start script to use a common path that exists on all servers (here /boinc/projects/MyProject) even if the physical path may not be identical. I'm not sure how this would blend into that page, though. Best, Bernd -- David On 03-Dec-2012 4:20 AM, Bernd Machenschalk wrote: Hi! I wonder whether any project has gotten a multi-server setup to work based on the current code and documentation (http://boinc.berkeley.edu/trac/wiki/MultiHost), and how. What I found is that the current stuff silently assumes that there is a (NFS) shared project directory mounted on all project servers on the very same physical path, which at least for us isn't the case. We do have a project directory path that is common on all servers, but set up with symlinks. The physical path varies (for good reasons), and the project directory (including subdirectories like the pid directories) isn't shared (because some remote servers are far away). In addition the hardcoded ssh command used in the start/stop/status script is completely independent of the ssh configuration for the server status page (SSP), which is at least confusing. The attached series of patches is meant to fix that: - the project path to use on all servers can now be configured asproject_dir. For backwards compatibility the defaults in server_status.php and start are chosen in a way that the old behavior is unchanged (../.. in SSP, os.getcwd() in start). - the start scrip now uses thessh_exec path for ssh if configured. The default ssh in the start script is now '/usr/bin/ssh' (as already in the SSP) - the pid of a daemon is now looked up in the pid directory on the _remote_ host via ssh, thus not requiring a shared project directory. Actually determining the pid and runing ps to find out whether the daemon is running is done by a script (pshelper) executed on the remote host, requiring only one command to be executed remotely via ssh. Still one ssh connection is required for every daemon on a remote host, which could be a significant slowdown. I'd rather handle all daemons running on one host in a single connection, but I couldn't get this finished now. If my current solution is to be used, pshelper must be put into the bin/ directory of the project on the remote server (make_project should be updated to do this). The 'ps' command used on remote hosts must be edited there. - if a daemons is disabled, daemons_status() returns immediately without looking up the PID and checking whether the daemon is actually running (which wouldn't change the return value anyway). - the ssh command that is executed on the remote host by the start script is only printed when the start script is ran in verbose mode. In particular this avoids unnecessary output and thus mails when ran by cron (start --cron). Best, Bernd ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address. ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address. ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] is_file(), is_project_dir()
On 27.11.12 19:50, David Anderson wrote: On 27-Nov-2012 5:45 AM, Bernd Machenschalk wrote: Is there any particular reason why is_file() doesn't allow for using symlinks, Yes. Out of curiosity: which reason? But I checked in a change that allows config.xml to be a symlink. Thanks. I recently stumbled upon a similar issue with is_dir(). To rephrase the original question: Is there any particular reason why files or directories referenced anywhere in the _server_ code (sched/ and parts of lib/) should not be allowed to be symlinks? Best, Bernd ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
[boinc_dev] result_template problem
Hi! I have a strange problem with uploading multiple result files. The XML doc in of the result (incarnated from the result_template) is (upload URL manually removed): file_info nameh1_0445.45_S6GC1__S6BucketLVEa_445.563682292Hz_2832_0_0/name generated_locally/ gzip_when_done/ upload_when_present/ max_nbytes600/max_nbytes urlUPLOAD_URL/url /file_info file_info nameh1_0445.45_S6GC1__S6BucketLVEa_445.563682292Hz_2832_0_1/name generated_locally/ gzip_when_done/ upload_when_present/ max_nbytes600/max_nbytes urlUPLOAD_URL/url /file_info result file_ref file_nameh1_0445.45_S6GC1__S6BucketLVEa_445.563682292Hz_2832_0_0/file_name open_nameGCT.out/open_name /file_ref /result result file_ref file_nameh1_0445.45_S6GC1__S6BucketLVEa_445.563682292Hz_2832_0_1/file_name open_nameGCT.out-LV/open_name /file_ref /result The Application only boinc_resolve()s the file GCT.out. It then writes the (resolved) file h1_0445.45_S6GC1__S6BucketLVEa_445.563682292Hz_2832_0_0 and a second one h1_0445.45_S6GC1__S6BucketLVEa_445.563682292Hz_2832_0_0-2nd, which it then renames to h1_0445.45_S6GC1__S6BucketLVEa_445.563682292Hz_2832_0_1 (all in the project directory) However after uploading, the second file h1_0445.45_S6GC1__S6BucketLVEa_445.563682292Hz_2832_0_1 is still in the project directory, and the result in the DB has only the first file recorded: XML doc out: file_infonameh1_0445.45_S6GC1__S6BucketLVEa_445.563682292Hz_2832_0_0/name nbytes141870.00/nbytes max_nbytes600.00/max_nbytes md5_cksum40e631d7bc8929f6a0e48d0a5e0eea36/md5_cksum urlhttp://einstein4.aei.uni-hannover.de/AlbertAtHome/cgi-bin/file_upload_handler/url/file_info Any idea what's wrong? Does boinc_resolve() do anything else than just resolving the softlink in the slot directory to the file in the project directory? Best, Bernd ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] result_template problem
Never mind - I found the problem when I saw my own mail on the list. There should be only one result covering both file_refs Bernd Bernd Machenschalk wrote, On 05.12.12 13:00: I have a strange problem with uploading multiple result files. The XML doc in of the result (incarnated from the result_template) is (upload URL manually removed): file_info nameh1_0445.45_S6GC1__S6BucketLVEa_445.563682292Hz_2832_0_0/name generated_locally/ gzip_when_done/ upload_when_present/ max_nbytes600/max_nbytes urlUPLOAD_URL/url /file_info file_info nameh1_0445.45_S6GC1__S6BucketLVEa_445.563682292Hz_2832_0_1/name generated_locally/ gzip_when_done/ upload_when_present/ max_nbytes600/max_nbytes urlUPLOAD_URL/url /file_info result file_ref file_nameh1_0445.45_S6GC1__S6BucketLVEa_445.563682292Hz_2832_0_0/file_name open_nameGCT.out/open_name /file_ref /result result file_ref file_nameh1_0445.45_S6GC1__S6BucketLVEa_445.563682292Hz_2832_0_1/file_name open_nameGCT.out-LV/open_name /file_ref /result ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
[boinc_dev] MultiHost
Hi!
I wonder whether any project has gotten a multi-server setup to work based on the current code and documentation
(http://boinc.berkeley.edu/trac/wiki/MultiHost), and how.
What I found is that the current stuff silently assumes that there is a (NFS) shared project directory mounted on all project servers on the very same
physical path, which at least for us isn't the case. We do have a project directory path that is common on all servers, but set up with symlinks. The
physical path varies (for good reasons), and the project directory (including subdirectories like the pid directories) isn't shared (because some
remote servers are far away).
In addition the hardcoded ssh command used in the start/stop/status script is completely independent of the ssh configuration for the server status
page (SSP), which is at least confusing.
The attached series of patches is meant to fix that:
- the project path to use on all servers can now be configured as project_dir. For backwards compatibility the defaults in server_status.php and
start are chosen in a way that the old behavior is unchanged (../.. in SSP, os.getcwd() in start).
- the start scrip now uses the ssh_exec path for ssh if configured. The
default ssh in the start script is now '/usr/bin/ssh' (as already in the SSP)
- the pid of a daemon is now looked up in the pid directory on the _remote_ host via ssh, thus not requiring a shared project directory. Actually
determining the pid and runing ps to find out whether the daemon is running is done by a script (pshelper) executed on the remote host, requiring only
one command to be executed remotely via ssh. Still one ssh connection is required for every daemon on a remote host, which could be a significant
slowdown. I'd rather handle all daemons running on one host in a single connection, but I couldn't get this finished now. If my current solution is to
be used, pshelper must be put into the bin/ directory of the project on the remote server (make_project should be updated to do this). The 'ps'
command used on remote hosts must be edited there.
- if a daemons is disabled, daemons_status() returns immediately without looking up the PID and checking whether the daemon is actually running (which
wouldn't change the return value anyway).
- the ssh command that is executed on the remote host by the start script is only printed when the start script is ran in verbose mode. In particular
this avoids unnecessary output and thus mails when ran by cron (start --cron).
Best,
Bernd
From 281b9ef3c3d29a0cb6c2a26d725557ffb1af17a3 Mon Sep 17 00:00:00 2001
From: Bernd Machenschalk bernd.machensch...@aei.mpg.de
Date: Mon, 3 Dec 2012 10:07:54 +
Subject: [PATCH 1/5] only print remote command in verbose mode
(in particular not when ran with --cron)
---
sched/start | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sched/start b/sched/start
index fb01cc1..98ffc93 100755
--- a/sched/start
+++ b/sched/start
@@ -745,7 +745,7 @@ if is_main_host:
remote_cmd = [ 'ssh', host, 'cd', cwd, ' ' ] + sys.argv
if verbose:
remote_cmd += [ '-v' ]
-print 'running ', ' '.join(remote_cmd)
+print 'running ', ' '.join(remote_cmd)
os.spawnvp(wait_mode, remote_cmd[0], remote_cmd)
os.unlink(start_lockfile)
--
1.7.12.2
From dca59f85a1aa07b85b046bd40bda344b76700577 Mon Sep 17 00:00:00 2001
From: Bernd Machenschalk bernd.machensch...@aei.mpg.de
Date: Mon, 3 Dec 2012 10:09:54 +
Subject: [PATCH 2/5] sync configuration of remote server management with PHP
(server status page)
- configure ssh executable to use with ssh_exec
- configure a project directory common to all hosts with project_dir
---
sched/start | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/sched/start b/sched/start
index 98ffc93..962b385 100755
--- a/sched/start
+++ b/sched/start
@@ -611,7 +611,6 @@ def command_show_config():
local_hostname = socket.gethostname()
local_hostname = local_hostname.split('.')[0]
# print 'local hostname: ', local_hostname
-cwd = os.getcwd()
program_name = os.path.basename(sys.argv[0])
if program_name == 'start':
command = command_enable_start
@@ -709,6 +708,18 @@ if not command:
config = configxml.ConfigFile(config_filename).read()
run_state = configxml.RunStateFile(run_state_filename).read(failopen_ok = True)
+if 'ssh_exec' in config.config.__dict__:
+ssh = config.config.ssh_exec
+else:
+ssh = '/usr/bin/ssh'
+
+if 'project_dir' in config.config.__dict__:
+cwd = config.config.project_dir + '/bin'
+cmd = './' + program_name
+else:
+cwd = os.getcwd()
+cmd = sys.argv[0]
+
os.chdir(boinc_project_path.project_path())
bin_dir = get_dir('bin')
cgi_bin_dir = get_dir('cgi_bin')
@@ -742,7 +753,7 @@ if is_main_host:
for host in other_hosts:
if host == local_hostname:
continue
-remote_cmd = [ 'ssh', host, 'cd', cwd, ' ' ] + sys.argv
Re: [boinc_dev] Git commits: message formatting and atomicity
On 22.10.12 20:41, Rom Walton wrote: I suppose the next obstacle will be when we really are ready to do a complete merge. But that is for another day... On 22.10.12 20:28, Nicolás Alvarez wrote: (ugh, they are still using that stupid checkin_notes file?) Yes they do. Hopefully only until they realize that this _must_ unavoidably cause conflicts in every merge or cherry-pick they try. Seriously: drop that file. The information meant to be in it is redundant at best, in reality less reliable than what's available int the SCM (that's what an SCM tool is made for, right?) and it generates unnecessary dependencies between commits that every SCM guideline I came across recommends to avoid. Best, Bernd ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] Slideshow screen saver
Might make a good example code in the boinc tree. Someone interested in doing this at the London hackfest? Best, Bernd Yeah, I think I will. Thanks for the input everyone. From: McLeod, John [mailto:john.mcl...@sap.com] Sent: Friday, September 14, 2012 8:56 AM To: Richard Haselgrove; Coss, David; boinc_dev@ssl.berkeley.edu Subject: RE: [boinc_dev] Slideshow screen saver Probably easier to start over. Forgot about that. From: Richard Haselgrove [mailto:r.haselgr...@btopenworld.com] Sent: Friday, September 14, 2012 9:14 AM To: McLeod, John; Coss, David; boinc_dev@ssl.berkeley.edu Subject: Re: [boinc_dev] Slideshow screen saver Used being the operative word. Neither the current 'LHC classic project, nor (unsurprisingly) T4T, has a BOINC v6 graphics_app that could be used for a screensaver, and I'm not sure whether the current administrators would have access to the old monolithic code - which would need adapting to the standalone format anyway. From: McLeod, Johnjohn.mcl...@sap.com To: Coss, Daviddavid.c...@stjude.org; boinc_dev@ssl.berkeley.eduboinc_dev@ssl.berkeley.edu Sent: Friday, 14 September 2012, 13:42 Subject: Re: [boinc_dev] Slideshow screen saver I believe that the screen saver that CERN used had a cycling movie. That may be the closest that you will come. -Original Message- From: boinc_dev-boun...@ssl.berkeley.edumailto:boinc_dev-boun...@ssl.berkeley.edu [mailto:boinc_dev-boun...@ssl.berkeley.edumailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of Coss, David Sent: Thursday, September 13, 2012 3:56 PM To: boinc_dev@ssl.berkeley.edumailto:boinc_dev@ssl.berkeley.edu Subject: [boinc_dev] Slideshow screen saver For my project, I wanted a boinc screen saver that would cycle through images like a slide show. That seemed simple and likely to have already been done. Before I reinvented the wheel, I thought I'd see if such a thing is already available as a boinc graphics app to go along with an application. Thanks, David Coss Email Disclaimer: www.stjude.org/emaildisclaimerhttp://www.stjude.org/emaildisclaimer Consultation Disclaimer: www.stjude.org/consultationdisclaimerhttp://www.stjude.org/consultationdisclaimer ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edumailto:boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address. ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edumailto:boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address. ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address. ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] Slideshow screen saver
Might make a good example code in the boinc tree. Someone interested in doing this at the London hackfest? Some ideas: - images distributed as project_files (http://boinc.berkeley.edu/trac/wiki/ProjectSkin) - Ken Burns effect (http://en.wikipedia.org/wiki/Ken_Burns_Effect) Bernd ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] file upload problem
On 02.08.12 15:07, Bernd Machenschalk wrote: On 02.08.12 09:51, Bernd Machenschalk wrote: On 25.07.12 14:49, john.mcl...@sybase.com wrote: Have the validator mark the files as read only as the first step in what it does. Implemented (in our own validator only so far). There is one case where this behavior worries me a bit: While tasks are in progress, a Client's BOINC data directory is backed up somewhere. The Client finishes the tasks, uploads and reports them. Validation is performed. Assume that the validation is inconclusive. The result files stay in the upload directory on the server, but locked (read-only). Then, for some reason, the backup is restored. The Client finishes the same tasks again, but can't successfully upload the result files as long as the old ones are there, which may be for weeks or even months. How would the Client react on tasks that can not be uploaded for several weeks? A possible relief would be in the validator to mark the result file writable again in case of an inconclusive validation, but I'm still thinking whether this may cause other problems. Also, too, the file_upload_handler uses advisory locks to lock files that are currently uploaded. I'm not sure whether and how the validator should be made aware of this, e.g. avoid validating (and mark read-only) files that are currently locked. And in addition int the case that originally pointed me to this problem, the locking apparently didn't prevent the Client from doing seven uploads in a single second (we're not using FCGI, so it could hardly be the same instance). Well, admittedly, this happened on an NFS filesystem, where locking may not work reliably. Best, Bernd ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] Feature proposal: Safeguards against excessive checkpointing?
On 10.08.12 14:26, Heinz-Bernd Eggenstein wrote: So what are the opinions here? Would it make sense to have something either at BOINC API compile time (e.g. -DBOINC_APP_MIN_CPT_INTERVAL=10) or on the C API level to enforce a minimum checkpoint interval ? If this is really meant to be application specific, I wouldn't fix this at BOINC compile time. This would work for Einstein@Home as we currently build our Apps, but might not work so well for others. Instead I would keep this in boinc_api as a static variable (int min_checkpoint_period) and have a new API function (boinc_set_min_checkpoint_period(int)) to set it from the app. Best, Bernd ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] file upload problem
On 25.07.12 14:49, john.mcl...@sybase.com wrote: Have the validator mark the files as read only as the first step in what it does. Hm. If that would work, it would also prevent the file_deleter from deleting the file later. Then either the assimilator needs to make the file writeable again after assimilation, or the file_deleter needs to use more 'force' to delete the file. And what would the (current) file_upload_handler do if it finds it can't write the file? I prefer fixing the root cause of problems over treating symptoms. IMHO the root cause here is that the file_upload_handler accepts any file any time, overwriting whatever may be already there (and e.g. already validated). FWIW we found a few more assimilated files (for a different application) that could never have made it through the validator that was running at that time. There is a slight chance of a hardware defect on our server RAID that keeps the assimilated results, but there is no other indication for that - no other files are broken, no SMART errors etc. Unfortunately the file_upload_handler logs of that time were already deleted (we keep these only for 200d). Best, Bernd Hi Kevin! On 24.07.12 23:38, Kevin Reed wrote: I think that the result file record includes a md5sum that you could check during validation and assimilation to confirm that it is the same file. This would prevent improper assimilation. Ok, I'll check this. I'm a bit worried, though, about the additional I/O load. Our current assimilator doesn't even read the result files, it just manipulates metadata (hardlinks). And I would prefer a solution that _prevents_ the file to be modified after validation over something that just _detects_ a possible modification. What should the assimilator do if it finds the file has been modified since validation? How often have you seen this? There is one case where we noticed it, because it happened in the canonical results of a certain application. I'm still digging through the logs to find cases where this might have gone unnoticed. This particular case involved a client behaving really mad, initiating an upload of a file with the same name (but four different reported file sizes) 221 times in total, up to 7 times in a single second, and apparently even after reporting the result. (Uploading a result file after the result was reported (once) is probably not uncommon - imagine a BOINC directory restored from a backup.) I don't expect to find many such cases, but the number of these is rather irrelevant. To me it shows a serious (design) problem that this could happen at all. Every possible check for scientific validity should be done in the validator, under _no_ circumstances should the server allow _any_ client to modify a result _after_ validation, no matter how stupid or rogue the client behaves. Best, Bernd ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address. ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] file upload problem
On 02.08.12 09:51, Bernd Machenschalk wrote: On 25.07.12 14:49, john.mcl...@sybase.com wrote: Have the validator mark the files as read only as the first step in what it does. After some more thinking, this doesn't sound like such a bad idea after all. I'll try this. Best, Bernd ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] file upload problem
Hi Kevin! On 24.07.12 23:38, Kevin Reed wrote: I think that the result file record includes a md5sum that you could check during validation and assimilation to confirm that it is the same file. This would prevent improper assimilation. Ok, I'll check this. I'm a bit worried, though, about the additional I/O load. Our current assimilator doesn't even read the result files, it just manipulates metadata (hardlinks). And I would prefer a solution that _prevents_ the file to be modified after validation over something that just _detects_ a possible modification. What should the assimilator do if it finds the file has been modified since validation? How often have you seen this? There is one case where we noticed it, because it happened in the canonical results of a certain application. I'm still digging through the logs to find cases where this might have gone unnoticed. This particular case involved a client behaving really mad, initiating an upload of a file with the same name (but four different reported file sizes) 221 times in total, up to 7 times in a single second, and apparently even after reporting the result. (Uploading a result file after the result was reported (once) is probably not uncommon - imagine a BOINC directory restored from a backup.) I don't expect to find many such cases, but the number of these is rather irrelevant. To me it shows a serious (design) problem that this could happen at all. Every possible check for scientific validity should be done in the validator, under _no_ circumstances should the server allow _any_ client to modify a result _after_ validation, no matter how stupid or rogue the client behaves. Best, Bernd ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
[boinc_dev] file upload problem
Hi! We recently had a case where a result file was uploaded multiple times over and over again, even after the result was reported. One of the uploads happened between validation and assimilation, resulting in assimilation of a 'canonical' result that has never been validated (and was actually broken). Certainly this one incident is mainly the result of a misbehaving Client (7.0.3 IIRC), but in any case I think the server code should be robust against such clients. I can think of a couple of options to prevent this from happening again in the future: - Move the result files from the upload directory when the result is reported; validate and assimilate it from this new location (scheduler would need to touch (move) result files) - Make the file upload handler check the result status in the DB (fuh needs DB access, additional DB load) - My current favorite: While receiving a file, the file upload handler appends .part to the filename. Only when the upload was successfully completed, the file is renamed to the result file name, but only if there is not already a file with that desired name yet. (the antique_file_deleter will eventually clean up partial uploads, too). Anything that still could go wrong with that behavior? Best, Bernd ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] plan_class_spec
Hi Eric! As the original author of that plan_class_spec code I have to admit that the flops scaling etc. is still something of a mystery to me, and although I changed it a few times I am pretty sure I didn't get this right. Apparently the latest rework by David didn't fix it either, although the latest version should use the functions provided in sched_customize.cpp and thus have more code in common with it. Could you send me (or point me to) SETIs sched_customize.cpp? I hope it could help me to understand and fix the problem. Best, Bernd On 14.07.12 18:32, Eric J Korpela wrote: I've spent a few weeks in the SETI@home beta trying to move from some highly customized plan classes to the plan_class_spec mechanism for some OpenCL apps. It's not working, and at this point I'm going to go back to the highly customized plan classes even though they are difficult the keep synced with changes to the source tree. The best I can figure out is that a lot of the scheduling and credit mechanisms are having problems. Many of the problems seem to have something to do with flop scaling. In sched_customize.cpp where customizable GPU plan classes live, a flops scale is applied to the GPUs processing rate. In plan_class_sched, it's applied to the CPUs processing rate even for GPU plans. The sample plan_class_spec.xml file has values that would be suitable for the sched_customize method do not work for plan_class_spec at all. The scheduler itself is very confused about what it means. If you put a value of 10 for flops_scale in plan_class_spec.xml, it will multiply the cpu benchmarks by 10 to get the processing rate, but then it does an incorrect calculation of processing rate based on PFC. Most GPUs seem to get estimated at about 100MFLOP from the bad PFC calculation. Credits granted for GPU work done come in about 1/500th of what they should be. Even beta testers get annoyed when the see 0.86 credits for something that should have been 700. Unfortunately there's not a a lot of source commonality between the two mechanisms, so anything I learned writing plan classes is lost in plan_class_spec. So I'm giving up on fixing it myself. If you're planning to use the plan_class_spec mechanism, I would hold off until it's fixed. ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address. ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] Proposal for Development BOINC
On 07.06.12 09:50, Oliver Bock wrote: On 6/6/12 20:42 , David Anderson wrote: I'm forwarding this to the boinc_dev email list. I don't really understand what's being proposed. Can someone clarify it? Sounds like a proposal for a hierarchical team structure, i.e. a team-tree...? There have been a couple of such proposals over the years (first one I remember from the INRIA BOINC WS), all were rejected. I don't think that BOINC should add technical support for anything like it. But as apparently Team / Stats sites are already handling this their own way, maybe they can coordinate to develop a standard for themselves? Probably the BOINC trac wiki could be of help. Best, Bernd ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] (no subject)
On 6/5/12 9:59 PM, Jon Sonntag wrote: The server_stable branch compiles without errors doesn't have plan_class_spec.h so I assume it doesn't support the XML plan classes configuration. I'm pretty sure that the plan class spec stuff is broken in current trunk: r25675 | davea | 2012-05-14 19:49:12 + (Mon, 14 May 2012) | 4 lines - scheduler: revision of app_plan_spec mechanism. Not debugged, but it compiles now. I didn't yet find the time to fully review, test and fix this version. If you intend to use the plan class from config file stuff, use a trunk version before r25675. Best, Bernd ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] IPV6 support?
Did anyone ever try to run a BOINC server in a clean IPv6 environment? IPv4 addresses are used in a number of places in the server code, I suspect a couple of things going wrong when that info is missing or inconsistent. Best, Bernd Rom Walton wrote: I just looked at libcurl's latest build files for Windows. It appears like we can now build it so that it'll support IPv6 with VS2005. It also looks like they upped their prereq to Winsock 2.x. After the initial release of 7.0.x we will have to give this another go. - Rom -Original Message- From: boinc_dev-boun...@ssl.berkeley.edu [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of Nicolás Alvarez Sent: Wednesday, April 04, 2012 6:07 PM To: john.mcl...@sybase.com Cc: BOINC_DEV Mailing List Subject: Re: [boinc_dev] IPV6 support? 2012/4/4, john.mcl...@sybase.comjohn.mcl...@sybase.com: I seem to recall the IPV6 was added sometime in the past, and then removed because of bugs in the library we are using. What is the status of this? jm7 BOINC doesn't have or need any support for IPv6 in project requests, that's handled transparently by libcurl. The question is if the precompiled libcurl we ship with the BOINC binaries for the various platforms has IPv6 enabled; I vaguely remember it did differ between platforms. In the BOINC packages shipped by Linux distributions, which use the system's libcurl, this is a non-issue. -- Nicolás ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address. ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address. ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] How to determine AMD's Catalyst driver version?
On 06.12.11 13:15, Richard Haselgrove wrote:
I don't know of any official list, but a SETI volunteer has compiled an
unofficial one:
http://www.hal6000.com/seti/boinc_ati_gpu_cheat_sheet.htm
Thanks.
If this list is correct, ATI has CAL release numbers 1000, which makes the
numeric encoding of the CAL version (version_num in COPROC_ATI) kind
of inadequate:
coproc.h:
struct COPROC_ATI : public COPROC {
...
char version[50];
int version_num;
// based on CAL version (not driver version)
// encoded as 100*major + 1000*minor + release
coproc.cpp:
int COPROC_ATI::parse(XML_PARSER xp) {
...
sscanf(version, %d.%d.%d, major, minor, release);
version_num = major*100 + minor*1000 + release;
Best,
Bernd
Hi,
The current BOINC client is able to determine the CAL version of the
installed AMD/ATI driver. Is there any way to find out (and communicate
to the server) the actual driver version, too? I checked the CAL API but
couldn't find any means. We would need something platform-independent of
course.
Alternatively, is there any direct official mapping between CAL version
(e.g. 1.4.1607 and driver version (e.g. 11.11 or 8.911 respectively) one
can look up somewhere?
Eventually this is supposed to end up in the plan class mechanism in
order to require a minimum/maximum AMD driver version to work around
certain known bugs in the drivers. This works just fine for NVIDIA/CUDA
but now we need the same important capability also for AMD/OpenCL.
Cheers,
Oliver
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
Re: [boinc_dev] OpenCL memory error in scheduler? Also: Generic OpenCL plan class
The MEGA issue is actually a bug in the current Client that Oliver found and
reported a few days ago. It is fixed in current trunk, but we didn't get any
information about when a Client which has this fixed will be publicly available.
Bernd
Timo Strunk timo.str...@kit.edu schrieb:
Hi everybody,
I implemented a generic OpenCL plan class. We talked about it on the
projects mailing list here:
http://lists.ssl.berkeley.edu/mailman/private/boinc_projects/2011-November/009132.html
The diff is quite short and below the mail. I encountered two problems,
which I can't fix without more input (one of those could also be a user
error on my side).
The first one is marked in the diff with //CAUTION, CHECK THIS BEFORE
CHECKIN
In all the other opencl_checks or cuda_checks memory is always
multiplied with a MEGA constant. The ATI opencl_check however reports
memory in megabyte already (cp.opencl_prop.global_mem_size is in Mega
for me) . Therefore I skipped the multiplication with MEGA. There could
be an inconsistency between ati and nvidia here. It would be nice if
someone with a recent nvidia card could check
cp.opencl_prop.global_mem_size in the opencl_check function and decide
if it's already given in MB too.
The second thing I encountered, which I couldn't fix is the need_ati
function.
inline bool need_ati() {
return (ati_req_secs0) || (ati_req_instances0);
}
Somehow this always returns false. I did not really understand where
ati_req_secs and instances are set. For now I just return true here, as
we have separate applications for opencl and cpu (hence a gpu is always
needed).
The whole modified file is here:
http://www.timo-strunk.de/data/boinc/sched_customize.cpp
Thanks for your help,
Timo
--- sched_customize.cpp (revision 24689)
+++ sched_customize.cpp (working copy)
@@ -464,7 +464,44 @@
static inline bool app_plan_opencl(
SCHEDULER_REQUEST sreq, const char* plan_class, HOST_USAGE hu
) {
- if (strstr(plan_class, nvidia)) {
+ //The plan class is called opencl_generic_101.
+ if (strstr(plan_class,generic_101))
+ {
+ //Generic class for 256Meg OpenCL accelerators with OpenCL = 1.1
+ COPROC_NVIDIA cn = sreq.coprocs.nvidia;
+ COPROC_ATI ca = sreq.coprocs.ati;
+ bool result = false;
+ //First we check nvidia, if it's true, we shortcut out
+ if (cn.count != 0) {
+ if (cn.have_opencl) {
+ result = opencl_check(cn,hu,
+ 101,
+ //CAUTION, CHECK THIS BEFORE CHECKIN: 256.0 without Mega. The ati
framework reports 1024Meg memory. Nvidia unknown.
+ 256.0,
+ 1,
+ .1,
+ .2
+ );
+ }
+ }
+ //Shortcut here
+ if (result) return true;
+
+ if (ca.count != 0) {
+ if (ca.have_opencl) {
+ result = opencl_check(ca,hu,
+ 101,
+ //CAUTION, CHECK THIS BEFORE CHECKIN: 256.0 without Mega. The ati
framework reports 1024Meg memory. Nvidia unknown.
+ 256.0,
+ 1,
+ .1,
+ .2
+ );
+ }
+ }
+ return result;
+ }
+ else if (strstr(plan_class, nvidia)) {
COPROC_NVIDIA c = sreq.coprocs.nvidia;
if (!c.count) return false;
if (!c.have_opencl) return false;
- end of diff
--
(0x2b |~ 0x2b)^2 == 1 (Shakespeare)
--
Karlsruhe Institute of Technology (KIT)
Institute of Nanotechnology
Timo Strunk
Physicist
Hermann-von-Helmholtz-Platz 1
Building 640, Room 0-215
76344 Eggenstein-Leopoldshafen, Germany
Phone: +49 721 6082-8954
Fax: +49 721 6082-6368
Email: timo.str...@kit.edu
http://www.int.kit.edu/
KIT – University of the State of Baden-Wuerttemberg and
National Laboratory of the Helmholtz Association
_
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
Re: [boinc_dev] What is a proper way to have persistent file written by project's app?
David Anderson wrote, On 02.12.11 00:37: That's probably the best approach (although the files would never get deleted). Make sure you include a version# in the filename. Hm - what should the version number include? For precompiled OpenCL kernels I would think of: - instead of using a version number that e.g. corresponds to the application version, I would consider comparing the timestamps of the current application binary and of the precompiled kernel. If the kernel file is older, rebuild it. Or else you may end up with many possibly large files that will not get deleted. Note: this will only work if you can ensure that you have only one application version at a time, which is usually the case on anonymous platform (app_info.xml), but not with automatically updated project apps. - when writing the kernel file, write it locally in the slot diretory, then move (boinc_rename) it into the final file. Or else you may end up with a broken kernel file if for some reason BOINC started two instances of the application. Best, Bernd ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
[boinc_dev] app selection problem
Hi! We just stumbled upon a major problem with the app selection mechanism in BOINC: - when a user edits his project preferences to e.g. opt-out of an application, all applications that he wants to run and that are known AT THAT TIME are added to the project preferences - when a new application is added to the project, this appid is not automatically added to the project settings of any user/venue - this means that the user will not get any work for new applications until he edits his preferences again For projects that regularly phase applications in and out this means that sooner or later no user that ever opted out of an application will ever get work from the project, without knowing why, withot being notified of it and possibly without recognizing it. My idea to work around this was: when adding a new application, modify the preferences of all users/venues that have an appid tag (i.e. that edited the settings once) adding and appid tag of the new application. 1. I think BOINC should provide at least a script or sth. to do this, preferably automatically when adding an application (OPS page manage applications). 2. That doesn't help, however, with existing applications, as there is no way to tell whether the appid isn't listed because the app has been added after the last edit or the user has purposefully opted out. I'm inclined to just add the current apps and let the users opt out again if they really want to, but I certainly don't like this very much. Best, Bernd ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] app selection problem
On 03.11.11 13:24, Peter Slacik wrote: Few (or many?) of projects, which allow to selectively opt-in/out for each single applications, have one more optional checkbox to automatically opt-in for each new application, which will be added by the project at some later time for a particular venue. This way the user is guaranteed to get some work, even if his presently opted-in apps will be phased out. (I have no idea, whether this checkbox' code comes from BOINC trunk, or is being individually added by these projects.) I don't see this on our test project, which runs BOINC trunk web code of SVN rev 24406, of roughly two weeks ago. I don't think that this is because of our customizations, but can't exclude this right now. Could you point me to a project which has this? Could anyone point me to the code which does this? I still find it overly complicated for both the participant and the BOINC server to have yet another setting to cover this case which I don't think is a special one, but if other projects got people used to that, I'd give in and adopt it. And the notification does indeed work using notices - No work is available for the apps you've chosen. Please check your project setttings on its web page. Many thanks for the reminder! I have to admit that I have seen this message in so many cases where the server couldn't find a suitable App for all other kinds of reasons that I forgot about it possibly having an actual purpose for this case. Best, Bernd ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] app selection problem
On 03.11.11 16:15, Peter Slacik wrote: OK, my apology, you've got me. The majority of the projects actually tell something different from what I wrote, e.g.: PrimeGrid project prefs (http://www.primegrid.com/prefs.php?subset=projectcols=0 http://www.primegrid.com/prefs.php?subset=projectcols=0): /Send work from any subproject if selected projects have no work/. Subprojects - OK, I now understand why occasionally people in our forums confuse apps and projects. Unfortunate wording IMHO. Collatz Conjecture prefs (http://boinc.thesonntags.com/collatz/prefs.php?subset=project): /If no work for selected applications is available, accept work from other applications?/ Both examples would behave differently from my original idea, and I'm not even sure this solves the original problem. These _could_ mean that work is accepted for applications people explicitly opted-out from (at the time of editing preferences), it doesn't say anything about future apps. And these refer only to the situation when there is no work available for the selected applications. If there really was a setting Automatically send work for future applications not yet mentioned here I would probably like it (if the default is yes). Any hints on implementing it to become a BOINC standard? I remember that at least the World Community Grid (https://secure.worldcommunitygrid.org/ms/viewMyProjects.do) suports the application opt-in, in addition to the previously mentioned task opt-in: /Please opt me in to new projects as they become available/, but I suspect the preferences code has less in common with BOINC trunk :-( Literally nothing, that's their own custom code. I still find it overly complicated for both the participant and the BOINC server to have yet another setting to cover this case which I don't think is a special one, but if other projects got people used to that, I'd give in and adopt it. Personally I'm glad to have such explicit options. When I'm connecting a recent powerful (and always-on) machine, and an old weaky (or mostly switched-off) machine, to the same project, I may allow the project to send just any tasks to the former one, but have to carefully choose applications (according to their crunch time and deadline) to be sent to the latter one - surely with no automatic opt-in. Doesn't sound like the average participant, though. Best, Bernd ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] app selection problem
I know, but a checkbox is easy to add. Is there any support in BOINC (sched_send etc.) for this behavior? Bernd David Anderson da...@ssl.berkeley.edu schrieb: This checkbox, AFAIK, is not part of the BOINC source code. -- David On 03-Nov-2011 5:24 AM, Peter Slacik wrote: Few (or many?) of projects, which allow to selectively opt-in/out for each single applications, have one more optional checkbox to automatically opt-in for each new application, which will be added by the project at some later time for a particular venue. This way the user is guaranteed to get some work, even if his presently opted-in apps will be phased out. (I have no idea, whether this checkbox' code comes from BOINC trunk, or is being individually added by these projects.) _ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address. ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] app selection problem
It looks ok to me to be a preference setting. What I am more concerned about are contributors that attached to the project once, edited their preferences to opt out an App they had problems with, and then forgot. They even run Clients too old to support notices. Bernd Jon Sonntag j...@thesonntags.com schrieb: If I choose to run only certain apps for a project and I choose not to accept work from other apps when those apps cannot get work, I would be very unhappy if the project ignored my preferences and decided I should run some new app without my approval. I chose those preferences for a reason. If I choose to run only 1 out of 5 apps on a project, I certainly don't want to get app #6 automatically added when it is released. If I want it, I'll add it to my preferences. If the project announces the new app and sends a reminder (isn't that what the new notices are for?) to users to check their preferences, that is all that is needed. It shouldn't be forced upon anyone, especially those who chose specifically not to run all apps and not to select work from any other apps when their selected apps are out of work. Here's a real life example: PrimeGrid's LLR apps run very hot and, as such, are sensitive to overclocking. In the past, they have caused a couple of my low profile case machines that have very poor airflow to overheat. I still want to contribute to PG, so I avoid all the LLR apps by deselecting them in my project preferences. If your suggestion were implemented, then if a new LLR app is released by PrimeGrid, I would get it added even though it would crash my machines. That's certainly not something for which I'd vote. I'd want PrimeGrid to honor my preferences and only send the apps I have chosen. Period. That includes new apps. Jon Sonntag -Original Message- From: boinc_dev-boun...@ssl.berkeley.edu [mailto:boinc_dev- boun...@ssl.berkeley.edu] On Behalf Of Bernd Machenschalk Sent: Thursday, November 03, 2011 10:32 AM To: Peter Slacik Cc: BOINC Developers Mailing List Subject: Re: [boinc_dev] app selection problem On 03.11.11 16:15, Peter Slacik wrote: OK, my apology, you've got me. The majority of the projects actually tell something different from what I wrote, e.g.: PrimeGrid project prefs (http://www.primegrid.com/prefs.php?subset=projectcols=0 http://www.primegrid.com/prefs.php?subset=projectcols=0;): /Send work from any subproject if selected projects have no work/. Subprojects - OK, I now understand why occasionally people in our forums confuse apps and projects. Unfortunate wording IMHO. Collatz Conjecture prefs (http://boinc.thesonntags.com/collatz/prefs.php?subset=project): /If no work for selected applications is available, accept work from other applications?/ Both examples would behave differently from my original idea, and I'm not even sure this solves the original problem. These _could_ mean that work is accepted for applications people explicitly opted-out from (at the time of editing preferences), it doesn't say anything about future apps. And these refer only to the situation when there is no work available for the selected applications. If there really was a setting Automatically send work for future applications not yet mentioned here I would probably like it (if the default is yes). Any hints on implementing it to become a BOINC standard? I remember that at least the World Community Grid (https://secure.worldcommunitygrid.org/ms/viewMyProjects.do) suports the application opt-in, in addition to the previously mentioned task opt-in: /Please opt me in to new projects as they become available/, but I suspect the preferences code has less in common with BOINC trunk :-( Literally nothing, that's their own custom code. I still find it overly complicated for both the participant and the BOINC server to have yet another setting to cover this case which I don't think is a special one, but if other projects got people used to that, I'd give in and adopt it. Personally I'm glad to have such explicit options. When I'm connecting a recent powerful (and always-on) machine, and an old weaky (or mostly switched-off) machine, to the same project, I may allow the project to send just any tasks to the former one, but have to carefully choose applications (according to their crunch time and deadline) to be sent to the latter one - surely with no automatic opt-in. Doesn't sound like the average participant, though. Best, Bernd _ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address. _ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page
Re: [boinc_dev] Locality scheduling
Max Dmitrichenko wrote, On 21.10.11 19:22: Well... when I create project and addlocality_scheduling/ to the config.xml I read errors in scheduler log... query: SELECT fs.id, fs.name, t.id, t.fileset_id, t.need_work, t.work_available, t.no_work_available, t.working_set_removal FROM fileset fs INNER JOIN sched_trigger t ON fs.id = t.fileset_id WHERE work_available = 1 Database error: Table 'test_project.fileset' doesn't exist I guess that the DB for locality scheduled projects must be created with some specific way. Can you tell the right way? Not from scratch. The commit Oliver made to the BOINC repo should have included the necessary database changes / updates. Oliver? Best, Bernd ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] Locality scheduling
The code is being rewritten by Einstein@home, although this is on hold at the very moment due to more urgent matters. For the time being I think the description in the Wiki is still correct, except for the triggers being handled in a DB table now instead of being files. Best, Bernd -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. Max Dmitrichenko dmitr...@gmail.com schrieb: BOINC wiki contains following info on the topic. NOTE: THE FOLLOWING IS MOSTLY DEPRECATED; THE LOCALITY SCHEDULING SYSTEM HAS BEEN REWRITTEN. CONTACT US FOR MORE INFO. So is there any way to figure out the current state of how it works? -- Max _ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address. ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] ARM project port
On 04.07.11 07:37, robert miles wrote: I've found a reference to where to get the source code for Einstein@Home applications: http://einstein.phys.uwm.edu/license.php This requires compiling gsl, fftw and the whole lalsuite for ARM, which I suspect to be a pain to get working. Also too, the resulting application (gravitational wave search) requires a significant amount of disk space to run, and the tasks would (initially) cause quite some download traffic. I don't think that this application is well suited for mobile devices. Is there a reasonably fast FFT(W) implementation for ARM? We might be able to find some different application. Best, Bernd ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
[boinc_dev] Aborted (by user)?
HI! I recently learned that newer clients automatically abort tasks that have not been started and are already past the deadline. I like this better than the previous ... consider aborting it message. However this is something the user has no control about. So the text aborted by user at various places (at least in the web code) is outdated and somewhat misleading. Additionally I, as a project manager, would really like to know whether a task was aborted by the client because it passed the deadline (which might suggest an extension of the deadlines), or whether it was aborted manually for other reasons. Is there a way to distinguish these two cases? If not, could there be made one e.g. by using a different exit status? The way the web code should be updated / fixed would clearly depends on whether these cases can be distinguished. Best, Bernd ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
[boinc_dev] flops / benchmark platforms
Hi! I recently observed that my Intel Mac got a PPC application. I think it is quite ok for the client to report multiple platforms, but I think it's not that it reports (or the server expects) the same (benchmarked) flops for all platforms as in the given case. Not sure how to handle this, though. Best, Bernd ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] OpenCL device selection
Just my 2ct: In a (possibly heterogenous) OpenCL environment there will be three different, inconsistent devive enumeration systems (ATI CAL, CUDA, OpenCL). AFAIK the OpenCL standard doesn't even ensure that the order of OpenCL devices returned by two subsequent calls to clGetDeviceIDs() return the devices in the same order (though in practice on current systems they usually will). Therefore I think we need a central instance that would keep track of the OpenCL devices and their allocation. This would be the client, as it has to keep track of CUDA and ATI devices anyway, an would need to map the OpenCL devices to the ATI and CUDA device IDs anyway at some point, at least in order to schedule devices. I propose that the client should actually keep the canonical list of OpenCL devices, and a BOINC API function (e.g. boinc_get_opencl_device_id(int,...)) should be called in the application to map the --device argument to the actual OpenCL device id. Best, Bernd ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] OpenCL device selection
On 12.04.11 12:36, Oliver Bock wrote: On 4/12/11 12:23 , Bernd Machenschalk wrote: I propose that the client should actually keep the canonical list of OpenCL devices, and a BOINC API function (e.g. boinc_get_opencl_device_id(int,...)) should be called in the application to map the --device argument to the actual OpenCL device id. That should solve the how to pass the non-integer OpenCL device ID to the science app question. Now we just need to figure out how to get to the consistent mapping across frameworks. Maybe we should post a feature request for CUDA like Rom did for OpenCL. Both frameworks should return a unique vendor-independent device ordinal, e.g. the PCI ID... To have that supported by the vendors will surely help, but I'm not sure whether and when support will be added. There might be a workaround to identify ATI CAL / CUDA devices in the OpneCL device list, e.g. setting a flag or writing / reading a specific register or memory address. Might OpenGL be of help? Bernd ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
[boinc_dev] #GPUs #cores
Hi! We're experimenting with running BOINC on a cluster of GPU nodes. Our application takes a full core per NVidia GPU (avg_ncpus = 1.0). The BOINC Client is told to use only one CPU core (for now), i.e. ncpus1/ncpus in cc_config.xml. However the Client starts as many tasks as there are GPUs on that node. When scheduling GPU tasks, does the Client ignore the number of available cores, expecting that there will always be more cores than GPUs? If so I'd consider this a bug. Best, Bernd ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] OpenCL plan class
I think that for NVidia you still need a special development driver, at least to run OpenCL 1.1, and I'm even less sure about ATI. I don't think that OpenCL capability can be detected from the CUDA capabilities or just display driver version. Does the client detect and report whether the system is capable of running OpenCL apps somewhere in the coproc capabilities? Am I correct in assuming that defining an OpenCL plan class in sched_customize.cpp should be enough for clients that use anonymous platform and declare an application with the same plan class name in an app_info specification? Or does the plan class name have to actually occur somewhere in the database? Best, Bernd ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] Linux driver detection
David Anderson wrote, On 23.02.11 07:16: The NVIDIA Linux drivers don't return driver version for some reason. But they return CUDA version, which is the important part anyway. Well, our code triggers a bug in the NVIdia driver that is fixed from a certain version (270) on. Luckily enough this driver version bumps up the CUDA version (in this case to 4.0), so checking that is good enough in this particular case. But that need not be in all future cases. Do you happen to know why exactly the driver version can't be determined by BOINC on Linux? If the problem is in the driver or API of NVidia, has a bug report been filed? Best, Bernd On 22-Feb-2011 4:34 AM, Bernd Machenschalk wrote: Hi! It looks like the NVidia driver version detection in the BOINC doesn't work at least for the new Linux Beta driver version 270 from NVidia. (http://einstein.phys.uwm.edu/forum_thread.php?id=8761#110707) Is this limited to certain versions of the BOINC Core Client, and is there something (workaround?) a project could do about this? Best, Bernd ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address. ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address. ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] Environment variables : suggestions
Nicolás Alvarez wrote, On 22.02.11 04:19: Huh? Linux passes environment variables to setuid-root processes too. [...] The security comes from the fact that LD_LIBRARY_PATH and LD_PRELOAD are ignored by the dynamic loader (regardless of who set them) if the binary has the setuid or setgid bits on. Thanks for the clarification. I remember hving seen some code that filters the environment for variables like LD_LIBRARY_PATH, possibly in BSD Unix, maybe pretty old. Anyway, the point remains that passing LD_LIBRARY_PATH and DYLD_LIBRARY_PATH to setuid root programs on Mac OS X doesn't have the desired effect, and this is not a bug, but an intentional security feature of the OS. Best, Bernd ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] Environment variables : suggestions
Charlie Fenton wrote, On 22.02.11 01:37: The code is repeated here because the LD_LIBRARY_PATH and DYLD_LIBRARY_PATH are not passed in to switcher (though I don't understand why not.) FWIW I wouldn't trust an OS that passes environment variables to a 'setuid root' program called from a non-privileged user process. No Unix-style OS I know of does this. Best, Bernd ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] Environment variables : suggestions
The slot and project directory should be added to DYLD_LIBRARY_PATH by Mac BOINC clients automatically. There had been a couple of problems with that in the past, but all should have been fixed about a year ago (see commits of Dec 2009 Jan 2010). If this does not work, it means that there (still or again) is a bug in the client that should be fixed, as other projects rely on that, too. I agree it could be a useful feature to add a general mechanism to set environment variables by the client before lauching the application, especially for legacy applications you don't have a source code for. Having to use a shell script wrapper is possible but not desirable, were it only for security reasons. Best, Bernd ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] Random segfaults in libraries on Linux?
On 19.12.10 21:11, Bernd Machenschalk wrote: David Anderson wrote, On 12/17/10 8:09 PM: I checked in a small change to boinc_api.cpp that may help narrow down the source of the problem. I hope to publish new Apps incorporating this tomorrow. Interesting. The segfaults have almost gone away with this change, in particular on the machines that run a gdb. No further stackdumps regarding this. With the previous code (trunk rev 22825) we also get bus errors in pthread_create / start_timer_thread that I've not seen before Still no clue, but I don't think this is severe. Possibly a libpthread problem on the machines. However it's striking that this usually happens on multi-core machines when these try to start two (or more) tasks at the very same second, and thus reach the pthread_create() at the same time. Then both tasks show this. Best, Bernd ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] Random segfaults in libraries on Linux?
The new Apps built from latest BOINC API code clearly have about 50% fewer segfaults than before. However the few stackdumps we get from segfaults of these apps still point to the same place; in current code that is boinc/api/boinc_api.cpp:1017 Any idea what still could go wrong there? Still a corrupted buffer from boinc_msg_prefix()? The worker thread closing the stderr stream while the timer thread tries to write there? Best, Bernd ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] Random segfaults in libraries on Linux?
The new Apps built from latest BOINC API code clearly have about 50% fewer segfaults than before. However the few stackdumps we get from segfaults of these apps still point to the same place; in current code that is boinc/api/boinc_api.cpp:1017 Any idea what still could go wrong there? Still a corrupted buffer from boinc_msg_prefix()? The worker thread closing the stderr stream while the timer thread tries to write there? FWIW here is a complete stacktrace: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xbb90 (LWP 7738)] 0x7e41 in ?? () #0 0x7e41 in ?? () #1 0xd57e in ?? () #2 0x002e0bd4 in write () from /lib/libc.so.6 #3 0x00280d14 in _IO_new_file_write () from /lib/libc.so.6 #4 0x002809d5 in new_do_write () from /lib/libc.so.6 #5 0x00280c8f in _IO_new_file_xsputn () from /lib/libc.so.6 #6 0x0025eebc in buffered_vfprintf () from /lib/libc.so.6 #7 0x00259e6f in vfprintf () from /lib/libc.so.6 #8 0x00263e42 in fprintf () from /lib/libc.so.6 #9 0x08196ca1 in timer_thread () at /home/boinc/EinsteinAtHome/EinsteinAtHome/source/boinc/api/boinc_api.cpp:1017 #10 0x00385832 in start_thread () from /lib/libpthread.so.0 #11 0x002eff6e in clone () from /lib/libc.so.6 Best, Bernd ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address. ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] plan classes and platforms
On 08.12.10 18:28, David Anderson wrote: 1) plan class is purely a server mechanism; it's relevant to all client versions. If an app_plan function references info that's only reported by certain clients (e.g., GPU list or CPU capabilities) then it will return false (i.e. that app version won't be sent). Thanks. But what then does a server log message client version 51013 lacks plan class capability mean? Doesn't this mean that plan-class applications aren't sent to such clients? Best, Bernd ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
