Re: [boinc_dev] Long Term Debt and work fetch and overworked
El Jue 23 Abr 2009 13:13:05 john.mcl...@sybase.com escribió: Whether the project is overworked or not should be determined by the max(long term debt for the resource, long term debt for the resource). max(A, A) == A Was one of those supposed to be long term debt for the *project*? ___ 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] FastCGI (was: Work Scheduling pt 2)
El Jue 30 Abr 2009 12:16:00 john.mcl...@sybase.com escribió: I have the feeling that nobody ever used the FastCGI scheduler correctly, that server admins compile it with FastCGI support as if that was all that needs to be done. I don't know enough about Fast CGI to have any hope of answering this. With normal CGI, every time a client does a request, Apache starts the scheduler and gives it the data sent by the client through stdin. The scheduler gives the reply in stdout, and the webserver sends it back to the client. Then the scheduler CGI process dies, and obviously loses its DB connection. With FastCGI, you can start up a dozen scheduler instances in advance. When a client does a request, Apache passes it to one of the scheduler processes running, using a special protocol. Once it's done, Apache sends the reply to the client, and that scheduler process is ready to handle a new request. Since the scheduler processes are long-lived in the FastCGI case, they don't have to reconnect to the database every time, and they can also keep in-memory caches of stuff (such as the application list; if we didn't already have it in shared memory from the feeder, that is). However, simply recompiling the scheduler with FastCGI support won't help anything. The webserver will still start one on every request and send it the POSTed data through stdin and expect a reply through stdout (which still will work since FastCGI handles that for compatibility reasons, but won't give you any performance advantage). The webserver has to be reconfigured to start up the FastCGI processes, setup a pipe for each, etc. I think mod_fastcgi isn't even installed by default. Cross-posting to boinc_projects for the benefit of admins. ___ 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] Work Scheduling (pt 2, Cooperative Scheduling?)
El Jue 30 Abr 2009 12:19:05 john.mcl...@sybase.com escribió: And then there is CPDN trickle-based kill which is completely different. The server sends a trickle-down to that host, knowing it has that task. The application handles the trickle and quits, saying it finished processing. This only works for projects that implement trickle messages, which is, I believe, CPDN only at the moment. Yes, and it's even application-specific. There is no kill trickle in BOINC; it's the CPDN application that handles a trickle with a particular content by pretending it finished processing. ___ 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] Work Scheduling (pt 2, Cooperative Scheduling?)
El Jue 30 Abr 2009 13:06:36 Martin escribió: Even if you use multiple separate download servers, you just simply have message sockets to your WU pool allocator process(es) to report what is successfully transferred and when. Similarly so for setting what URL is to point to what WU on the web server(s). (The web server system can be arranged to automatically default to download timeout page/response for timed out URLs.) BURP uses download servers provided by volunteer users. A few projects use download servers distributed across the world. File downloads *must* work on plain old HTTP servers without having to 'call home'. ___ 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] Work Scheduling (pt 2, Cooperative Scheduling?)
El Jue 30 Abr 2009 13:39:18 Paul D. Buck escribió: Take the simplest example, The first stage of a task is the creation of the Result, which generates one or more Tasks. Neither of these are of interest or should be visible to the participant. So, why are they in the running tasks and running results table? Terminology: The project admin creates workunits, from which results are created. BOINC server has no Tasks. These are also not of interest to the core client. The client shouldn't be aware of this replication mechanism, yet the workunit/result-separation implementation detail is exposed all the way to the *GUI*. ___ 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] Work Scheduling (pt 2, Cooperative Scheduling?)
El Jue 30 Abr 2009 13:45:38 Martin escribió: Then that is an Achilles heel for gaining feedback on what was accepted by the client... Apache can report what URL downloaded whatever, so that is one means of feedback for servers under direct project control. Another means could be that that the next client request also lists what was accepted last time. Rather messy and that would leave unaccepted WUs in limbo for too long. And then there is the even more messy WU abort... S... At present, how do the download servers know to delete downloaded/expired WUs if they can't 'phone home'? That depends on the project. If it's the same server, file_deleter deletes download files from the local 'download' directory. If it's a different server on the LAN, usually it's NFS-mounted, so file_deleter also issues a normal file delete. BURP sends a request to mirror servers to tell them the file should be deleted. It's a completely custom request, and probably triggered by the mirror system, not the file deleter. I don't know what einst...@home does for its geo-distributed download servers. What is done at present about WU failed downloads? Nothing that involves the download 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] Work Scheduling (pt 2, Cooperative Scheduling?)
El Jue 30 Abr 2009 13:55:46 john.mcl...@sybase.com escribió: At present, how do the download servers know to delete downloaded/expired WUs if they can't 'phone home'? The Validator deletes the files. The validator compares files and chooses a canonical result. The assimilator does something useful for those files (in the case of SETI, parses the XML file and loads data into a DB). The file_deleter then deletes all uploaded files, except for the canonical one if there are still other results in progress (if replication min_quorum) so they can be validated, and deletes download files unless there are other unsent or in-progress results. ___ 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] Work Scheduling (pt 2, Cooperative Scheduling?)
El Jue 30 Abr 2009 13:58:27 john.mcl...@sybase.com escribió: Once a day if there was no CPU request, or with the CPU request if there is one. This is a substantially lower count than if every project is asked for a work proposal for every work request. You're adding more every words than we were suggesting. ___ 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] Work Scheduling (pt 2, Cooperative Scheduling?)
El Jue 30 Abr 2009 13:32:01 Mikus Grinbergs escribió: [ And what if the result that's returned is useless because of a bug in the project's application? ] And what if their output files are binary, a bug in the project's application causes invalid results, and sample_bitwise_validator marks it valid anyway? [more on this later; this time I want to write a patch before reporting] ___ 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] Work Scheduling (pt 2, Cooperative Scheduling?)
El Jue 30 Abr 2009 15:26:40 john.mcl...@sybase.com escribió: The two are at different layers in the protocol stack. No news to me. Using HTTP, we're *forced* to use individual requests, each sending complete information, and the server has to do eg. user/host lookup on every request. Using a stateful TCP protocol, we could authenticate once and do multiple things over the same connection. There, saved you some DB queries. And we could have server-client messages, probably useful to in-house low-latency use. ___ 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] Work Scheduling (pt 2, Cooperative Scheduling?)
El Jue 30 Abr 2009 15:35:10 Nicolás Alvarez escribió: El Jue 30 Abr 2009 15:26:40 john.mcl...@sybase.com escribió: The two are at different layers in the protocol stack. No news to me. Using HTTP, we're *forced* to use individual requests, each sending complete information, and the server has to do eg. user/host lookup on every request. Using a stateful TCP protocol, we could authenticate once and do multiple things over the same connection. There, saved you some DB queries. And we could have server-client messages, probably useful to in-house low-latency use. Looks like I had already suggested this: http://lists.ssl.berkeley.edu/pipermail/boinc_dev/2008-February/009823.html ___ 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] A strange permission error.
El 01/05/2009, a las 11:57, Eric Myers my...@spy-hill.net escribió: On Fri, 1 May 2009, Alan Sun wrote: file upload server: can't open file /opt/boinc_grid/upload/64/ sj_106_0_0: Permission denied The upload area uses directory fanout, with subdirectory names based on a hash of the filename. It is possible that the subdirectory 64 had not yet been created, and could not be created because the file_upload_handler does not have permission to do so. Check your permissions. Or 64 is created and has bad permissions itself?___ 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] Work Scheduling (pt 2, Cooperative Scheduling?)
El 30/04/2009, a las 13:13, john.mcl...@sybase.com escribió: jm7 Nicolás Alvarez nicolas.alva...@gmail.com wrote on 04/30/2009 12:0 5:33 PM: Nicolás Alvarez nicolas.alva...@gmail.com 04/30/2009 12:05 PM To boinc_dev@ssl.berkeley.edu cc john.mcl...@sybase.com, Martin m_boinc...@ml1.co.uk Subject Re: [boinc_dev] Work Scheduling (pt 2, Cooperative Scheduling?) El Jue 30 Abr 2009 12:45:44 john.mcl...@sybase.com escribió: The server recorded that it was sent to client X in the DB during the initial connection. It now has to unrecord that information in the DB. Sorry, there is DB access involved. Nope. It HAS to be recorded sometime, and since file downloads DO NO DB ACCESS, it CANNOT happen at that time. The server does not know which host is downloading any particular file, and cannot know. A batch of WUs are given to whatever server process allocates them to client requests as is the case now. That process only records back to the db those WUs that are successfully downloaded by the client. No DB access during file download. The ack for a client taking a WU is the last ack of the download indicating successful download. No DB access during file download. After that, /then/ the db is updated /just the once/ to say that the host has that (or those) WU(s). No DB access during file download. I never said anything about files, I even explicitly said I wasn't talking about file downloads. I'm talking about a new concept of workunit download separate from the workunit request/assignment. And yes, it would do DB access. I may have gotten confused. I thought that someone was claiming that it ***could*** be done without DB access, and be triggered by the file download. I also think that is what Martin was implying. Some notes: It has to be backwards compatible - client versions that do not do this exist, and the server has to behave correctly. We have been told many times before that only one trip to the scheduler is allowed for scheduling a set of tasks. What happens if the project assigns a dozen tasks. 10 or them download instantly, but there is a delay getting the other two? ___ 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] A strange permission error.
El Sáb 02 May 2009 14:14:58 Alan Sun escribió: If someone folder created and has bad permission itself, how can I avoid this? Is it a bug of the file_upload_handler component? The documentation explains the upload directory should have setgid permissions so that subdirectories inherit its permissions. Did you follow all the instructions here? http://boinc.berkeley.edu/trac/wiki/ServerIntro#permissions ___ 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 documentation
El Martes 05 May 2009 02:47:20 Paul D. Buck escribió: The windows build documentation as noted in page: http://boinc.berkeley.edu/trac/wiki/SourceCode implies that the source code can be completed by downloading the supplemental files from page: http://boinc.berkeley.edu/trac/browser/trunk/boinc_depends_win_vs2005 ; yet this link, if used in SVN indicates that this page is not WebDAV enabled. 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.
Re: [boinc_dev] Work Scheduling (pt 2, Cooperative Scheduling?)
El Jue 30 Abr 2009 21:39:27 Rom Walton escribió: The problem with persistent connections is the overall memory consumed in just maintaining the connection. Even if you striped down the scheduler to a self contained daemon you still will have to deal with the basics of maintaining connection state for which ever clients are connected and however many connections need to be made to the database to service queries promptly. More memory in the database server will be allocated towards maintaining the increased number of connections. Eventually you'll be buying new machines to run the server farm, not because the servers couldn't handle it if the connections closed, but because the connections last so darn long. Would it be significant compared to all the mysql_store_result calls done by every daemon, usually with a cap of 1000 rows? And with all the arrays of data objects that the new PHP DB abstraction layer creates on every query? Primegrid once had a bit of downtime with its validator, and people couldn't see their list of pending credits. The DB code loads every row into an array of objects, then passes it to the presentation code, instead of streaming from the DB. There were so many pending results that pending.php failed with maximum memory usage reached. Don't turn down ideas in the name of performance until the *current* performance problems (more like server resource sinks) are 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.
Re: [boinc_dev] Work Scheduling (pt 2, Cooperative Scheduling?)
El Miércoles 06 May 2009 18:12:11 Rom Walton escribió: Now let us assume for a moment that all of our users have an Internet connection that is fast enough to download 20 s...@h workunits in 20 minutes. s...@h, on average, processes 10 scheduler requests a second. That comes out to 12,000 scheduler connections every 20 minutes, 12,000 connections would consume roughly 2.5GB of memory if MySQL were left at the default configuration. That would be 2.5GB of memory that couldn't be allocated towards caching high use tables, or indexes. 12000 connections every 20 minutes says nothing about how many active connections you have at once. Why would the scheduler keep a connection to the DB during a whole 20 minutes? The scheduler seems to run and die in two seconds, and when it dies, there won't be a DB connection anymore. With your numbers, if a connection lasts 3 seconds, there will be 30 connections alive at a time. Which is 6.6 megabytes. If fast enough to download 20 s...@h workunits in 20 minutes means it takes 20 minutes for a client to download a scheduler request, you're using a *completely* unrealistic situation, so your analysis isn't valid... ___ 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 6.6 for Linux?
El Miércoles 06 May 2009 22:11:37 Paul D. Buck escribió: The problem is the package managers which don't seem to update but, I would guess, once or twice a year. [...] Not sure which one you want or how easy it is to install. My recollection was that I could not get these to work for me so I suffered with the package install which though not up to date, at least works (still running whatever was installed). Milos Jakubicek maintains the Fedora package. He thought lack of an official 6.6 build in http://boinc.berkeley.edu/download_all.php meant it wasn't stable on Linux yet, that's why he was asking. ___ 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] Work Scheduling (pt 2, Cooperative Scheduling?)
What penalty, lowered daily quota? You have no idea how easy it is to make the server think I'm a new host. Once, LHC was giving 2 tasks per request, and requested a delay of 10 minutes between requests. If you forced an update before the 10 minutes passed, it replied last RPC too recent and didn't give you work. By making it think I was a new host, the server thought it was my first request ever and gave me 2 more tasks. And it's not like adding a request/offer/accept facility to the protocol implies there will be a wizard in the GUI to automatically reject workunits with X characteristics. They'd have to edit the client code to (ab)use the protocol that way. And if people can do that, they might as well implement an auto-task-aborter *now*. El Vie 08 May 2009 14:31:54 john.mcl...@sybase.com escribió: But currently, there is a penalty. jm7 Nicolás Alvarez nicolas.alvarez@ gmail.com To Sent by: boinc_dev@ssl.berkeley.edu boinc_dev-bounces cc @ssl.berkeley.edu Subject Re: [boinc_dev] Work Scheduling (pt 05/08/2009 01:06 2, Cooperative Scheduling?) PM El Vie 08 May 2009 12:59:59 Rom Walton escribió: I mean if I'm a researcher for rose...@home and half my client base decides not to run a certain type of task because they don't think it doesn't do X, there by doubling the length of time for a CASP run to complete, I'm going to be annoyed. Or I'm working on my PHD thesis and I manage to only attract power crunchers who don't like a certain batch of tasks, how am I going to complete my research? If someone doesn't like a certain small batch of tasks, they already have the ability to abort the tasks. If someone doesn't like a certain big batch of tasks, they already have the ability to detach and contribute to another project. ___ 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 enable reCAPTCHA if my url contains a port forwarding ?
El Vie 08 May 2009 20:54:33 Kunsheng Chen escribió: Hello everyone, I posted a thread on how to enable CAPTCHA a week ago and many people gave me good ideas, thank you all for that. Now I did the following and tried to enable reCAPTCHA : http://boinc.berkeley.edu/trac/wiki/ProtectionFromSpam My urls is http://canis.csc.ncsu.edu:8009/anansi However I could only create keys with http://canis.csc.ncsu.edu otherwise it would keep reminding me my url is not a valid domain (the port is there). I put the keys in config.xml, however I could still create a new account without any CAPTCHA there, obviously it is not working... I am wondering if anyone got the same problem befoer and could give me some idea again. reCAPTCHA asks you for a domain name, not a URL prefix, so canis.csc.ncsu.edu should be correct. Captchas don't protect against account creation. That's not possible, since users can create accounts using BOINC Manager (where it would be hard and would break compatibility to use captchas), and the command line tool boinccmd (where it's technically impossible to show a captcha). Captchas just block profile creation, which is where advertising could appear. Try creating a profile for your new account. ___ 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] Trac ticket spam
Can somebody please block user jingjing in Trac? He keeps adding dog training spam to random Trac tickets, and I'm going crazy deleting it because it keeps appearing. I have no intentions of playing whack-a-mole all night :) ___ 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] Shared library versioning
Does *anyone* currently use the shared library for the API? Enviado desde mi iPod El 12/05/2009, a las 06:36, Gabor Gombas gomb...@sztaki.hu escribió: Hi, For some time, BOINC can build shared libraries. Unfortunately it uses the package version as library version, which is bad. Example: since at least r16904, the SONAME of the API is libboinc_api.so.6, but API/ABI-breaking changes were made to graphics2.h in r17405 abd gutil.h in r17195, so the SONAME should be libboinc_api.so.8 by now. There are two ways to fix this: - Use a separate, distinct version number for every shared library. This gives the most flexibility for using the library, but it means that every change to the libraries must carefully analyzed for API/ABI compatibility. - Use -release $(PACKAGE_VERSION) instead of -version-number $(LIBBOINC_VERSION) when linking the libraries. This way you don't have to care about API/ABI breakage but applications must be rebuilt for every new BOINC version. Ideally the first method should be used at least for the libraries used on the client side, but it means extra work when making changes. Libraries used on the server side only could use the second method. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - ___ 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] Reporting a lot of tasks at the same time
El Jue 14 May 2009 06:51:40 Maureen Vilar escribió: (Max. upload size too small? I think, 4MB is the default for upload_max_filesize in PHP.INI)' The scheduler is not PHP, so php.ini doesn't apply. ___ 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] Reporting a lot of tasks at the same time
El Jue 14 May 2009 07:58:28 Ian Hay escribió: Jorden van der Elst wrote on 14/05/2009 10:46: So how can we get these people to report their tasks? We're talking about around 60K in tasks that are still waiting to be reported (deadline of the 19th at max). Is there some crude way we can get people to report tasks in batches? The reported results are embedded in client_state.xml and they'd have to edit out the file_info, workunit and result sections for the results they're holding back then edit them back in. Or else if this is a database problem, where the database has a maximum amount of tasks it can take in one swoop, what should be changed to allow for a higher number of consecutive tasks to be reported at once? I'd guess the problem is DB_SCHED_RESULT_ITEM_SET::enumerate(), in which case there should be Batch query failed errors in the scheduler log. DB_SCHED_RESULT_ITEM_SET::enumerate() generates a SELECT on the result table with a WHERE name in (...) clause which includes every reported result name extracted from the scheduler request. If the problem is the size of that query the easiest solution would be to split that function (in db/boinc_db.cpp) to run the query in batches of, say, 500 results. Or better, instead of processing all tasks in batches of 500, it should process no more than 500. The client will later do another request with the tasks that didn't get reported (the server reply says which tasks got processed). ___ 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_alpha] New crashs odditiy
El Jue 14 May 2009 12:53:51 john.mcl...@sybase.com escribió: Was this with multiple copies of BOINC.exe running? If so, then each of them would be attempting the same thing. If you start a second boinc.exe, it will soon quit because it can't open the GUI RPC port. ___ 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] Reporting a lot of tasks at the same time
El Jue 14 May 2009 16:25:27 john.mcl...@sybase.com escribió: Does the client get informed about the tasks that were not correctly reported? Or does the server loop through the tasks X at a time until the entire RPC is complete? The server returns a report ack for every successfully-reported task. Look at a sched_reply_*.xml file after reporting. ___ 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] [Fwd: Problem with the parsing code in the forum?]
And if you do, remember to close http://boinc.berkeley.edu/trac/ticket/594 El Miércoles 13 May 2009 13:05:09 David Anderson escribió: If anyone wants to tackle this, feel free. Original Message Subject: Problem with the parsing code in the forum? Date: Tue, 12 May 2009 18:04:52 -0700 From: Eric J Korpela korp...@ssl.berkeley.edu To: David Anderson da...@ssl.berkeley.edu Some people have a comma in their username, so clicking the link to pm them sets the field to 4325219 (Blanston, Gern) which results in the error Unknown user 'Gern)' 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.
Re: [boinc_dev] Reporting a lot of tasks at the same time
El Jue 14 May 2009 16:03:59 David Anderson escribió: The scheduler is failing in memory allocation. According to my rough calculation, this is happening after allocating about 256MB given a request that reports 1800 completed jobs. On my machine, a RESULT is 197560 bytes and a SCHED_RESULT_ITEM is 131664 bytes. 1800 reported tasks need at least 678MB of memory, plus std::strings for every result name (for the acks). ___ 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_alpha] New crashs odditiy
El 18/05/2009, a las 09:49, john.mcl...@sybase.com escribió: Having a couple thousand files or directories in a directory can be a problem. On some systems, the more files and directories there are in a directory, the slower file access is, and at some point, opening a file in an overly large directory is a major problem. In any case, the directories still have to be cleaned out for re-use eventually (and to give the hard disk space back). The solutions that move the file to trash are OS dependent (what function to spawn, and where to move the directory), and BOINC does not ever need the data back, so they should be just deleted. The suggestion was for using a directory called trash within BOINC data directory, not the Recycle Bin or similar. Once the old stuff is in the trash dir, it can be slowly deleted, while another app can immediately use the now-clean slot. A better solution would be to add a cleaning state to the slot and to delete only X files total from all slots every pass through the polling loop. jm7 Gabor Gombas gomb...@sztaki.h u To Paul D. Buck 05/18/2009 02:08 p.d.b...@comcast.net AM cc BOINC Dev Mailing List boinc_dev@ssl.berkeley.edu, Charlie Fenton charl...@ssl.berkeley.edu, john.mcl...@sybase.com, Jack Shultz jshu...@hydrogenathome.org Subject Re: [boinc_dev] [boinc_alpha] New crashs odditiy On Fri, May 15, 2009 at 06:31:26AM -0700, Paul D. Buck wrote: The down side to that is clean-up of completed tasks will be deferred and slots will not be freed as fast as they are now. Personally, I would make that trade in a heartbeat... I have lost too many tasks to the too many restarts problem... and this looks to be the real cause... For one thing, I cannot think of a faster way to delete files on unix systems. Does not mean that there is not a way ... but I have never heard of it... Hmm, how is this for simpler? When the slot is done, and ready for clean up, do a mv to a trash directory mv ./1 ./trash/datetime. Next, create a clean slot of the right number. mkdir ./1 Or change the slot numbering: instead of reusing the same number immediately, just number them sequentially, and wrap around after a couple thousand. IMHO the most important thing would be to do any I/O sensitive tasks asynchronously. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - ___ 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] Work Scheduling (pt 2, Cooperative Scheduling?)
El Vie 08 May 2009 12:59:59 Rom Walton escribió: I mean if I'm a researcher for rose...@home and half my client base decides not to run a certain type of task because they don't think it doesn't do X, there by doubling the length of time for a CASP run to complete, I'm going to be annoyed. If they can't avoid running that type of task, they may detach altogether and not run any type of task from your project. ___ 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_dev Digest, Vol 60, Issue 38
El Lunes 18 May 2009 14:52:34 Matthew Saunier escribió: I really can't believe the way ideas are constantly beaten down on this list. Please, look for something you agree with (as I did above), and write about that before making a post that indicates only that there are challenges to overcome. Such posts always convey the feeling that the topic at-hand is a bad idea, and they often seem to stifle any further constructive discussion on topics. And since there's really no harm in this one, and LOTS of potential GOOD in it, there's really no reason for anyone to refute the merit. Plus, not everyone runs Win32, or x86 - making the same compressed video render natively (and correctly) on all the platforms BOINC supports is a major task in itself, and adds to BOINC's dependency tree. Not to post just to be contrary, but that's the way it is. He said the video would NOT be played in the manager, and I replied agreeing. ___ 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 All versions download page
El Miércoles 20 May 2009 08:21:32 Richard Haselgrove escribió: I am sorely tempted to start polluting trac again, so we have a searchable index of the issues which otherwise are in danger of underflowing the LIFO stack which is David Anderson's inbox. Please do. That's what it's for. Just try not to file bugs of I upgraded and things seem not to be working right :) There should be a reasonable amount of information so that the problem can be reproduced. ___ 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] Voice over for Mac OS X
El Dom 31 May 2009 21:00:03 Charlie Fenton escribió: Unfortunately, WCG who designed and implemented the Simple View specified there should be no menus in Simple View other than the minimum required by the OS, so there is no indication of this shortcut. The best I could do without violating this requirement is to include both shortcuts in the View menu in the Advanced View. In other platforms, having no menu means having no menu bar taking space at all. In Mac, the menu bar is always there, so you might as well put useful things in it... ___ 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] Bad packets from all Boinc-related sites
El Miércoles 03 Jun 2009 12:02:39 Scarecrow escribió: I haven't 'sniffed' the packets throughly, but it appears that they arrive with the SYN, ACK, FIN, URG, and PSH flags set. So every single flag set? I don't know much about networking but that sounds *really* weird (in particular syn and fin are kind of mutually-exclusive)... ___ 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: client compilation under Windows using VS2008
El Vie 29 May 2009 12:47:13 myle escribió: karse...@ceid.upatras.gr wrote: Hello, We are trying to compile the latest version of BOINC using VS2008 by following the exact procedure as described on [http://boinc.berkeley.edu/trac/wiki/CompileClient] but it fails. Could it be possible that these instructions are obsolete ? The same code copiles just fine under Linux. We are looking forward for a concrete answer. e.k Could someone update the guide here [http://boinc.berkeley.edu/trac/wiki/CompileClient]? I am sure that a lot of people are able to compile client under Windows. But for those who are willing to contribute it is a really hard task if these instructions don't fulfill their promise. They were updated a week *before* you two asked. If something is wrong in the guide, please say exactly what. Update it isn't useful if, as far as we know, it's already up-to-date. ___ 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] Offload task assignment to super server
El Vie 08 May 2009 21:51:30 Martin escribió: Various projects seem to be now branching out to offering multiple projects within their one project base. Which projects exactly? MilkyWay splitting its GPU app into a separate project? That just shows that either BOINC isn't good enough at handling both CPU and GPU apps in the same project, or the admins don't know how to make it work. ___ 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: client compilation under Windows using VS2008
El Jue 04 Jun 2009 14:53:44 Paul D. Buck escribió: When I tried the instructions it got a negative result. In that I did not know how to fix the problems I cannot tell you what is wrong with the guide other than it does not work if you follow the recipe ... I suspect the same issue occurs here. And negative result means what? I have yet to see anyone say, for example, in what part of the process they had a problem, or what compiler errors they got. ___ 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] Bug in update_versions?
El Lunes 08 Jun 2009 21:30:01 Jeremy Cowles escribió: Maybe I'm not understanding something, but under windows files must end in .bat to be executed as a batch file, correct? If this is the case, are batch files are not supported by update_versions? I ask because the reg-ex that parses executable names does not include .bat as an option. See: re_match_exec_filename(filepath) in update_versions for the reg-ex. A batch file shouldn't be the main_application, so it doesn't matter for that. And Windows doesn't have Unix-like executable permissions, so that's off too. What other benefit would you get if update_versions detects a .bat as an executable file? ___ 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] Any idea about Compile BOINC Application in Windows with Visual C++ 6.0
El Lunes 08 Jun 2009 21:50:19 Kunsheng Chen escribió: The thing is that it require Cygin1.dll to be under folder Windows/System32 in client side. I think I could have a multiple bionc app (includes this cygwin1.dll). And in my app, just copy Cygwin1.dll to Windows/System32, but this seems weird somehow. Is that what you are saying ? No, cygwin1.dll only has to be next to the .exe file. At least one project has used cygwin before. ___ 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] Mac OS 10.6 Snow Leopard
El Martes 09 Jun 2009 17:42:53 Patrick Wooldridge escribió: Hi. With the announcement that Mac OS 10.6 (Snow Leopard) will be released in September, I just wanted to recommend to those who are competent to do so, that a new version of the BOINC client for Macintosh be developed to take advantage of the enhanced multiprocessor support in Snow Leopard and perhaps at the same time incorporate use of the graphics processor. Thanks to all for your hard work and the continued success of the BOINC network. The BOINC client does not use multiple processors. Project applications do. I don't think any project would want to modify their apps to use the Mac-specific system for multithreading, since it wouldn't be portable to other platforms. ___ 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] Bug in update_versions?
El Martes 09 Jun 2009 14:20:09 David Anderson escribió: It would be possible to use code signing (WU files can have signatures, just like app version files). But this would defeat the ease-of-use goal. It's the same situation with single job submission. At least, in both cases, the time window of vulnerability is limited. Input files can have signatures, and if the signature is there, it's checked. If an input file has an invalid signature (doesn't match public key), the file is rejected. But what can a project admin do to enforce there has to be a valid signature on a certain file? If a project sends its Python scripts signed, what would stop a hacker from simply sending a workunit that doesn't have a signature at all in the Python script? I think this is relevant to any project where the input file format is powerful enough to cause harm if it's maliciously created. ___ 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] Bug in update_versions?
El Martes 09 Jun 2009 18:28:52 Jeremy Cowles escribió: On Tue, Jun 9, 2009 at 2:07 PM, David Anderson da...@ssl.berkeley.eduwrote: Should we add that capability to the client? I suspect that it will open a DOS window each time it runs a batch file, which would rule it out for general use. You can use the STARTUPINFO struct to hide it (I assume this is already in place, since we dont see other apps launch), but the security problems combined with the extra overhead of modifying the client makes me wonder if it's worth while. PyMW could do away with the script by using a compiled executable as the main-app. All it really needs to do is find the Python interpreter and then launch it with a couple parameters. I wrote a BOINC science app that *embeds* the Python interpreter, avoiding any kind of process-level wrapper (like the official WrapperApp) or launch script (like your .bat), and it even provides the Python code with functions like boinc.resolve_filename(). Release pending cleanup. From what I have seen, using a process-level wrapper (launching a real worker app as a separate process and keeping track of it) causes enough problems to be annoying. My opinion is that it should be used if and only if the computation code cannot be modified to use the BOINC API, be it for legal or practical reasons (like it being closed source). ___ 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] Add country to forum profile
El Miércoles 10 Jun 2009 19:47:24 David Anderson escribió: I'll do this if someone sends me an array that parallels the existing $countries array (see below) containing the 2-letter country codes used by the FamFamFam images -- David Debian systems, maybe most Linux systems, already have that, even translated to multiple languages. See, for example, /usr/share/xml/iso-codes/iso_3166.xml iso_3166_entry alpha_2_code=AF alpha_3_code=AFG numeric_code=004 name=Afghanistan official_name=Islamic Republic of Afghanistan / iso_3166_entry alpha_2_code=AX alpha_3_code=ALA numeric_code=248 name=Åland Islands / iso_3166_entry alpha_2_code=AL alpha_3_code=ALB numeric_code=008 name=Albania official_name=Republic of Albania / [...] Or maybe easier to parse, /usr/share/iso-codes/iso_3166.tab AD Andorra AE United Arab Emirates AF Afghanistan AG Antigua and Barbuda AI Anguilla [...] Country name translations to several languages are available in compiled gettext format, in: /usr/share/locale/lang/LC_MESSAGES/iso_3166.mo (The ISO3166 two or three letter code is what we should be using to store it in the database, anyway...) ___ 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] Changing master url
El Jue 11 Jun 2009 14:15:21 Jeremy Cowles escribió: I created a project with an internal IP address (192.x.x.x) and now I want to test it with clients out on the internet. So I've changed the address to my public address (78.x.x.x) in project.xml and recreated the apps (xadd, update versions). Now clients can attach to the project using the public address, but they fail to receive workunits. When I turn on more detailed logging on the client, I continue to see the 192.x.x.x address, even though it says that the main URL is 78.x.x.x (on the client). Is there something I need to do to reset the client or the project? I cant find instances of 192.x.x.x in any of the configuration. Changing a project master URL is not a trivial task. It's recommended that projects avoid keeping things prone to change in their project URLs, like using an IP address, or even putting the university they are in as part of the hostname (dock...@home had to change the URL twice or so because they changed university / organization / department / something). Thus, the best way is having a domain name just for that project. Good URLs don't change. Even having multiple projects as boinc.example.org/project1 and boinc.example.org/project2 may be problematic if you eventually decide you want to move project2 to a different server. It's best to have project1.example.org and project2.example.org so they can (now or in the future) have different IP addresses. All that said, here is how you change a project URL: 1. Pick a *good* new URL according to the above recommendations, so that you will never need to change it again. 2. If the project was ever public, post news to let users now the URL will change. 3. If you have any tasks in progress or waiting to be sent, it's recommended you wait until they are all done before changing the URL. And/or abort the unsent tasks. You *could* edit the database to fix URLs for input files, to make the unsent workunits work once the URL is changed; but if users already have workunits on their computers, they will still have old URLs and you can't edit that. 4. Stop the project. 5. Replace URL everywhere in config.xml 6. Replace scheduler URL in html/users/schedulers.txt. Prefix should match the URL in cgi_url in config.xml. 7. If you have project-wide files, like logos for the simple GUI, replace download URLs in project_files.xml 8. Delete everything in html/cache, since cached pages may have links to the old URL, and users would get broken links for an hour or so. Don't delete the cache folder itself. rm -rf html/cache/* 9. Either create new application versions, or update the app_version table to have the new URLs: UPDATE app_version SET xml_doc = REPLACE(xml_doc, http://old.example.com/;, http://new.example.org/;); 10. If you have forums, you may want to do a similar replacement on forum contents, in case users posted links to workunits / users / computers / something. 11. Start the project, send some test workunits, and hope it works. Keep a copy of Murphy's Law - and other reasons why things go wrong handy. [to be cleaned up and posted on the wiki] ___ 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] Command as main program w/out files
El Vie 12 Jun 2009 15:50:03 Jeremy Cowles escribió: Agreed. Also, it would be nice to expose the suspend/quit/checkpoint api (boinc_status) into Python, or is this already available? You don't need to notify the Python code when it's suspended, since it will be suspended at the process level anyway. The only time it matters is if your app starts another app, then the parent needs to handle a suspend message by suspending the child. The official WrapperApp already does this. Your python code shouldn't need to know when a quit happens, for example to save data cleanly, because it's supposed to work with unclean quits anyway (like power outages). Save data atomically on checkpoints. Those two items apply to BOINC applications in any language. I could easily expose the checkpoint API on my Python wrapper if needed (easily but not quickly; I'm currently having a lot of distractions and interruptions) ___ 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] Idea on compiling boinc source in Cygwin
El Sáb 13 Jun 2009 02:19:32 Kunsheng Chen escribió: boinc-client required libcurl 7.16 or later version while Cygwin only installs 7.15 there, so I have to disable it by ./configure --disable-client to pass ./configure command. However even if I disable the client and made the command pass, when I run 'make' command after that, it reminds me ../lib/boinc_win.h includes 'share.h' and 'dgbhelp.h' which were not exists there. I don't know what share.h is about, but for dbghelp.h, change it to include imagehlp.h instead. ___ 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] Splitting libboinc?
El Sáb 13 Jun 2009 09:39:16 Bernd Machenschalk escribió: Does this mean that now the lib can be compiled without curl and openssl? They shouldn't be needed for an App (at least not for the BOINC part). curl was never needed to compile/link science apps. libboinc doesn't use curl, only the core client does. You're right about openssl, though. ___ 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] Command as main program w/out files
El Sáb 13 Jun 2009 18:09:30 Jeremy Cowles escribió: El Vie 12 Jun 2009 16:21:06 David Anderson escribió: Jeremy Cowles wrote: Agreed. Also, it would be nice to expose the suspend/quit/checkpoint api (boinc_status) into Python, or is this already available? This page has a link to a python binding of the BOINC API: http://boinc.berkeley.edu/trac/wiki/PythonApps This is probably out of date but might be a good starting point. Here is my Python-BOINC wrapper. It *embeds* the Python interpreter, so the process-level wrapper isn't needed. http://bitbucket.org/nicolas17/pyboinc/ So embedding the interpreter looks really straight forward, but how do you propose to handle the standard library? Some of it is platform specific and depends on compiled libraries, isn't that going to pose a problem for client distribution? Well, each platform needs its own version of the interpreter anyway, so it's not much harder to add other platform-specific files. ___ 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] Command as main program w/out files
El Sáb 13 Jun 2009 20:17:06 Jeremy Cowles escribió: Windows and Mac seem pretty straight forward and easy to compile in advance, but would you have to compile on the client for Linux or would you just make assumptions about what libraries are present? At the moment I'm having bigger problems compiling it on Windows. The prebuilt Python libraries require msvcrt90.dll, which may not be on all computers, and either way it needs some manifest mess... So I have to rebuild Python with a static CRT, which seems better in the long run than dynamically linking with an old-enough CRT. Just installing Visual C++ 2008 was a task by itself... ___ 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] Finding BOINC API from a build system
I'm working on the build system for a science app. I'm having trouble with locating the BOINC API include files and compiled libraries. If the library is installed, both miofile.h and boinc_api.h would be in eg. /usr/local/include/boinc/, but if it's not installed, the source dir has lib/miofile.h and api/boinc_api.h. Most of the time, the BOINC API isn't make installed. I have *that* part working; I search in lib and api subdirs and I successfully find the include files in a non-installed source directory. However, how do I find BOINC's config.h? If I look in the global search paths, I might end up finding the config.h from some other completely different program (like /usr/include/wx-2.8/wx/config.h if that happened to be in the path). ___ 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] Finding BOINC API from a build system
El 15/06/2009, a las 08:48, Gabor Gombas gomb...@sztaki.hu escribió: On Sun, Jun 14, 2009 at 10:01:26PM -0300, Nicolás Alvarez wrote: However, how do I find BOINC's config.h? If I look in the global search paths, I might end up finding the config.h from some other completely different program (like /usr/include/wx-2.8/wx/config.h if that happened to be in the path). Why do you want to find it? You should never use config.h from some other project in your program. It usually is a bad idea to install config.h and reference config.h from public headers. parse.h includes it, and probably others. I get a build error if I don't add the path to config.h to the search path for include files (with -I). I haven't checked, but if BOINC puts something in its config.h that applications should also use, then it must be moved to some other header with an unique name. You can use the AC_CONFIG_COMMANDS() autoconf macro to generate such a header. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - ___ 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] Upload server redirection
El 16/06/2009, a las 10:50, Milo Thurston milo.thurs...@oerc.ox.ac.uk escribió: Hello, As you may have noticed, we've had a bit of server trouble of late. One of our upload servers seems to be unfixable at the moment and I wonder about the feasibility of updating the DNS records to point all uploads to a working server. I don't see why this shouldn't work, but if there is any reason I've missed I'd appreciate it if someone would let me know. Thanks, Milo. As long as both servers know the correct upload signature key, and the scheduler, validator and assimilator can see files uploaded via the other server, there won't be any problem. --- Dr. Milo Thurston http://climateprediction.net http://www.oerc.ox.ac.uk ___ 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] Upload server redirection
El Martes 16 Jun 2009 11:28:07 Milo Thurston escribió: and the scheduler, validator and assimilator can see files uploaded via the other server, Do you mind if I ask for clarification of what you mean in this case? The normal way things work is: When a client reports a task, the scheduler needs to confirm that it already uploaded the output files. Then the validator needs to check if the uploaded files are valid, and, if there is replication, compare them to other results from the same workunit. Finally the assimilator has to read the files to make them do something useful for the project, like putting the results into a database. A lot of this may be different for CPDN, because of trickles. I obviously have no idea how *your* backend stuff works ;) No matter what server handles the file upload, the other daemons need access to the uploaded files. I don't really know how things have to be setup if you have more than one upload server. I guess it would easily work if all write to the same filesystem (which of course may be in a huge RAID of many disks). ___ 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] About don't require that file upload URLs contain 'file_upload_handler'
With files sent by the server via the file storage features, and not as part of workunits, when the project asks the client to upload a file, the upload URL is *added* to the list of URLs. So the file_info ends having the upload_when_present flag, and two URLs: http://example.com/project/download/398/file1.zip http://example.com/project_cgi/file_upload_handler (I mentioned this in my giant BOINC file storage features message to boinc_projects) With this change: http://boinc.berkeley.edu/trac/changeset/18427 How does the client know which is the upload URL? Will it try to POST to the file1.zip URL? [begin useless if-I-could-do-BOINC-from-scratch rant] The problem is the current url element is used to give URLs, but they are handled in a completely different way depending on whether it's a download or an upload. That means the tag is ambiguous. For downloads, it's the URL of a file, and the client GETs it. For uploads, it's the URL of a program that accepts an upload, and the client POSTs custom protocol data to it. Cleaner ways would have been: - Use different tags for download and upload URLs, to remove the ambiguity. You can be sure it will never POST to a download URL, or try to GET from the file_upload_handler URL. - Don't use a custom protocol; the same URL could be used to either GET or PUT data. Then, when I ask the client to download a file, I send it a data/file1.zip URL, and when I want it back, I tell it to upload, and it could PUT to that same URL. [/useless rant] ___ 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] Command as main program w/out files
El Martes 16 Jun 2009 15:24:42 Jeremy Cowles escribió: Windows and Mac seem pretty straight forward and easy to compile in advance, but would you have to compile on the client for Linux or would you just make assumptions about what libraries are present? At the moment I'm having bigger problems compiling it on Windows. The prebuilt Python libraries require msvcrt90.dll, which may not be on all computers, and either way it needs some manifest mess... So I have to rebuild Python with a static CRT, which seems better in the long run than dynamically linking with an old-enough CRT. Is it compiling now? I tried to compile your code under windows, but I wasn't sure how to compile the BOINC api/lib under windows. If you got this working, can you tell me what you did? I know how to setup the VS project, it's currently importing the Python headers and libs correctly. It's just BOINC I'm having the trouble with (I'm sure it's just that I don't know what I'm doing). Yes, it compiles on Windows, but the CMake script needs manual tweaking to tell it where the libs are. Which won't directly be a problem if you are creating a VS project yourself to compile my code. To compile api/lib on Windows, use the Visual C++ projects in the win_build directory of BOINC repository. ___ 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] make clean leaves symlinks
El Lunes 22 Jun 2009 16:23:46 Jeremy Cowles escribió: I am upgrading my BOINC install to the latest version, when running make clean and then following the typical setup procedure it fails when creating symlinks to libstdc++.a in the samples directory. After I manually removed the links, everything worked fine. Also: - Running _autosetup creates several Makefile.in files that are not in svn:ignore. - Running configure creates a lot more files (Makefiles, boinc_path_config.py, etc) that aren't in svn:ignore either. - Running make distclean doesn't delete most of those. - make install tries to install stuff under /etc, ignoring my --prefix. Leave my system configuration alone thank you very much. - make uninstall doesn't delete everything that make install installed. - make dist doesn't work at all. - It says api_app.cpp doesn't exist (referred by api/Makefile.am). - If I remove the rules mentioning that file, it complains about several files referred in test/Makefile.am. - Rather than fixing that mess, I removed 'test' from the subdirs in the root makefile. It fails at samples/example_app, which is listed in SUBDIRS but it has a hand-written Makefile not supporting the standard automake rules, namely 'destdir'. - and it goes on. ___ 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] [Fwd: [BOINC] #924: Partial Transfer Fails]
El Lunes 22 Jun 2009 17:13:52 David Anderson escribió: It's not clear to me how to solve this problem. Synopsis: - projects can configure their web server to send files in a compressed form to clients that can handle it; see http://boinc.berkeley.edu/trac/wiki/FileCompression In modern (= 5.4) BOINC clients, the client tells libCurl to handle such compression. - The client keeps track of the bytes transferred N, and if a transfer fails and is retried, it sends a Range: header telling the web server to skip the first N bytes. NOTE: N is a count of uncompressed bytes; as far as I can tell, libCurl tells us only how many uncompressed bytes it's read. But when send Range:N to the server, it skips N compressed bytes, which causes the error Kevin points out below. I can think of 3 solutions, 2 of which I don't know how to implement: 1) If a file is compressed, always start the transfer from the beginning. Problem: how does the client know if a file is compressed? This is negotiated between libCurl and the server. 2) Keep track of the number M of compressed bytes transferred, and tell the server to skip M bytes on retries. Problems: a) libCurl doesn't tell us M, as far as I can tell. b) I'm not sure that Apache supports this. 3) Allow a no_partial_transfer flag in file_info elements, telling the client to always start transfers from the beginning. Does anyone know how to implement 1) or 2), or have other ideas? If not, should I go ahead and implement 3)? I'm discussing on IRC (for the n'th time) in what order HTTP expects range and content-encoding to happen. Are we supposed to get a piece of the compressed file, or a compressed piece of the original file? In the former case, we *can't* let libcurl handle compression for us, since when we resume a transfer, we have to concatenate the new data to the partial *compressed* file. If libcurl handles content-encoding compression transparently, then the partial compressed data is never saved anywhere. ___ 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] [Fwd: [BOINC] #924: Partial Transfer Fails]
El Lunes 22 Jun 2009 17:33:32 Kevin Reed escribió: I.e. I should add RequestHeader unset Range so that apache will not process the range request. However, you can not set conditions on the RequestHeader like you can with Header so this would take effect for all download requests (we don't do this for all of our projects). Any ideas out there? In that case you should also make sure the response headers do *not* return Accept-Range: bytes. But I don't know if the client looks at this response header to know whether it can resume transfers... ___ 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] Hi, there is a strange problem about the single job assimilation.
El Vie 26 Jun 2009 14:04:18 Alan Sun escribió: Well, I think the first time I launched project is under user boincadm. Because I noticed this issue before. I want to make a test today, so I'm carefully on this. Well, under user root, the project works well, and those machines are in a internal network, so I think launch project as root is also accept for me. I just want to know why it cause the different result, for user boincadm and root. I will read that assimilator later and find out what exactly it does. The assimilator is used to move the result to a place, when it access or write something to somewhere, the file permission issue raised. It's not about the very first time you run it, it's about having run it as root at least once at any moment. At that point file ownership would change and boincadm wouldn't work correctly anymore. Or maybe you never set users and groups correctly to allow files written by Apache (which usually runs on its own account) to be read by boincadm. ___ 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] edit time to completion
El Martes 07 Jul 2009 14:27:26 David Anderson escribió:
The weighting is actually quadratic; i.e., when the job is half done
the estimate is 75% from the dynamic and 25% from the static.
However, I think I see a serious bug in the code (see below).
Anyone else see it?
Last time I looked at this code, I thought something quite stupid was being
done. Then I analyzed it more carefully and it turned out to be right, just
written in a confusing way.
I'll try a second pass.
// Returns the estimated CPU time to completion (in seconds) of this task.
// Compute this as a weighted average of estimates based on
// 1) the workunit's flops count
// 2) the current reported CPU time and fraction done
//
double ACTIVE_TASK::est_time_to_completion(bool for_work_fetch) {
if (fraction_done = 1) return 0;
double wu_est = result-estimated_duration(for_work_fetch);
if (fraction_done = 0) return wu_est;
double frac_est = (elapsed_time / fraction_done) - elapsed_time;
double fraction_left = 1-fraction_done;
double wu_weight = fraction_left * fraction_left;
double fd_weight = 1 - wu_weight;
double x = fd_weight*frac_est + wu_weight*fraction_left*wu_est;
return x;
}
double RESULT::estimated_duration(bool) {
return
estimated_duration_uncorrected()*project-duration_correction_factor; }
double RESULT::estimated_duration_uncorrected() {
return wup-rsc_fpops_est/avp-flops;
}
___
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] Cloud-like BOINC
El Miércoles 08 Jul 2009 18:11:44 David Anderson escribió: but it's probably the wave of the future. That sounds like hype-speak. And apparently different people have different thoughts for what cloud is. Google's cloud view is that a web-based operating system that can only run web apps is the wave of the future (the recently-announced Google Chrome OS), where I'm not sure how BOINC would run at all... ___ 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] Optimizing uploads.....
El Dom 12 Jul 2009 07:45:37 erbenton escribió: Re-read what i wrote, i think you misunderstood what i was saying. When you have a bunch of files in the Ready to Report state and you click on the project update button they seem to upload all at once vs the Transfer tab where they seem to upload 1 at a time I think you misunderstand how BOINC works, or at least its terminology, because you're talking about a different process than everyone else in this thread. Files aren't in ready to report state, tasks are. Ready to report tasks aren't uploaded, they are reported. In the transfers tab, you see the output *files* belonging to workunits being uploaded. When you click update, workunits whose files were already uploaded are reported to the server, all at once, possibly also getting new work at the same time. ___ 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] Optimizing uploads.....
El Dom 12 Jul 2009 09:16:36 Martin escribió: Note that some control of incoming bandwidth can be achieved by merely delaying the server response to a request. So... delay a request until some time limit and then issue a deny regardless to kick that requesting client into a backoff count? When hosting a project on a home machine (with a residential Internet connection), I once wrote a script that turned off file uploads if there were more than N file_upload_handler processes running (= more than N uploads in progress at once). ___ 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] Optimizing uploads.....
El Dom 12 Jul 2009 19:32:14 Mikus Grinbergs escribió: I understand that for a project with more than 10 active clients, situations will arise where the servers are the bottleneck, and need to be protected from overload. But I have a philosophical problem with restraining the _clients_ when it is the _servers_ that get overloaded. To my mind, if a project cannot afford the hardware to service 10 clients, then it should not *accept* 10 clients. I myself do not run the way an average BOINC participant does -- I run off-line. Once a day I connect my client machines to the internet, squirt work up and down - and disconnect. If a 'ready' result gets backed off instead of being uploaded during this squirt -- it has to wait until tomorrow's connection for the upload to be tried again. If that makes the result miss its deadline - TOO BAD - I consider it the fault of the project for not accepting the upload, not my fault for not having the kind of connection that would wait around for the server to get 'ready'. And there are many projects which throttle the assignment of work (by enforcing a minimum interval between work requests from the same client). Little do these projects realize that my multiple client_machines are ready and willing to perform lots more crunching for them -- but they never see any follow-on requests from me, since I have already disconnected before their minimum interval expires. I realize that you have to design for the average participant. But as long as BOINC supports specifying an 'interval between connects' of more than 24 hours, I for one will definitely make use of the way-of-doing-work that offers. Please keep in mind the implications -- for any proposal that relies on backing off before retrying -- of the possibility of a connection that, rather than going idle, will simply close down (for the next 24 hours, or more). Maybe there should be a setting called simply: I have a permanent Internet connection. If the user has a permanent connection, throttle if needed to lower server load, as is being discussed between Martin and Lynn. If the user is on dialup, upload as much as you can while you can! Or maybe the client should try to automatically figure out whether the user has intermittent Internet; otherwise users with a permanent connection could set the setting to say they don't have one just to force immediate uploads, causing unnecessary server load. ___ 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] Optimizing uploads.....
El Dom 12 Jul 2009 20:58:00 Lynn W. Taylor escribió: If every work unit went out, was out for a few hours, and then returned, 24/7/365, the problem I'm talking about does not exist -- the flow is even. The problem I had involved no outages. A few hundred workunits went out, were out for a few hours, then the majority tried to come back at the same time. My project was running on a home Internet connection, so two or three users could be enough to saturate the project bandwidth. But increase the numbers and it could happen to a real project too. A project without a constant stream of work. It sends a bunch of workunits, clients get them and go quiet for a while. If most take around the same time to finish, you get a DDoS when they try to upload. ___ 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] Unzipping, client side
You don't need to unzip. Python supports reading modules from inside a zip archive since 2.3. Enviado desde mi iPod El 14/07/2009, a las 04:01, Jeremy Cowles jeremy.cow...@gmail.com escribió: I am trying to package the Python standard library with an application. I assume zipping it is the best way to go about this. So once zipped, does BOINC provide a mechanism for unzipping files on the client side or is this something that has to be done by the app? -- Jeremy ___ 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] Unzipping, client side
El Martes 14 Jul 2009 12:10:38 Carl Christensen escribió: well since presumably you can't use boinc_zip I guess either distribute zip/unzip executables for each platform, or use the zipfile module for python (does that get back to the problem of using various python libs within boinc though?) You could get a bootstrap problem that way; you have to ensure the zipfile module and all its dependencies are *not* in the .zip archive! ___ 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] Catastrophe is looming; desperately need advice
El Martes 14 Jul 2009 09:41:10 Carl Christensen escribió: with boinc credits the simple rule is there's no pleasing anyone. I actually think that if my GPU does 10 times the work of a CPU that I should get 10 times the credit (which I think is what you or the noisier credit people are complaining about)? at the very least, that promotes better energy efficiency for a project in addition to faster turnaround times for a workunit. That's correct. If a GPU is 10x faster you should get 10x credits per day, which is accomplished by simply giving the same credits per task no matter the processor. But here's scenario #3, following my message from yesterday: Project A gives 12 credits per task. The task takes four hours on a certain CPU, so a user running exclusively that project will get 72cr/day (again, this is a fictional situation; let's ignore whether this rate is reasonable compared to other current real projects). Other projects give 72cr/day too, so cross-project credit parity is okay. The project manages to optimize the app so it takes *three* hours on this CPU. And to ensure credits are kept in sync with other projects, they lower credits per task to 9, so the user still gets 72cr/day. That is, they choose the second option as described in my scenario 2. So far so good. Suppose this project, still giving 9 cr/task, makes a GPU app. The task takes three hours on the CPU, and the new GPU app takes 1 hour on a certain GPU model. Credits per task are the same for both. So a user running fulltime on that GPU will get 216cr/day (or more, if he *also* runs the CPU app). Now, the project finds a way to speed it up further on CPUs. Task goes down to 2 hours on that CPU, and 1 hour on the GPU. What do they do with credits now? Option 1: project lowers credits to 6 per task so that, taking two hours per task, that CPU still gets 72 cr/day. But then GPUs will get 144 cr/day. Why do GPU users get less than before, if their app is the same? (was 216/day) Option 2: project leaves credits at 9 per task. GPUs still get 216 cr/day. CPU now gets 108 cr/day. People say it's overgranting, and it's true, the same CPU gets close to 72 cr/day in every other project, but 108 cr/day in this one. Even more: think what would have happened if they had released the GPU app before doing the *first* CPU optimization (that is, if they had released the 1h GPU app while having a 4h CPU app), or if they had released the GPU app after doing both CPU optimizations. Is there any good reason for credits to be different depending on what was released first? ___ 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] Release Notes for 6.6.36 incorrect
Aren't release notes in the Wiki? You can fix them yourself... El Martes 14 Jul 2009 16:35:43 Richard Haselgrove escribió: If you have multiple login accounts for the computer, I believe you have to repeat step (3) (heeding the warning in step (4)) for each separate user account. - Original Message - From: William bcdecbi...@yahoo.com To: boinc_dev@ssl.berkeley.edu Sent: Tuesday, July 14, 2009 8:08 PM Subject: [boinc_dev] Release Notes for 6.6.36 incorrect The Release Notes for BOINC 6.6.36 are incorrect with respect to the directions for creating a silent installation. Those directions apply to a much older version of BOINC. The incorrect (outdated) directions are: - To run BOINC invisibly, choose the Protected application execution option, then delete the BOINC shortcut from the Start/Programs/BOINC and Start/Programs/Startup menus (locate BOINC in each menu, right-click, select Delete). You can still run the BOINC Manager by going to C:\Program Files\BOINC and double-clicking on boincmgr.exe - The correct directions are: - To run BOINC invisibly, 1) Install options screen - click Advanced, uncheck Screensaver and check Protected Application Execution. 2) After restart, click Advanced View. 3) Select menu item Advanced Options, uncheck Run Manager at Login, uncheck Enable Manager Exit Dialog, move Network Reminder Interval slider to 120, click OK. 4) Select menu item File Exit. [Note: If you simply use the X button to close the window, none of your changes will be saved and the installation will fail to be silent!] 5) In Start Programs, right-click the BOINC folder and select Delete. 6) Reboot. If you see a BOINC system tray icon, the BOINC Manager screen, or any other indication of non-silent installation, repeat these steps as needed. - ___ 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] Optimizing uploads.....
El Jue 16 Jul 2009 16:44:45 David Anderson escribió: The following change should have a big impact (I hope): - client: changed file upload logic Old: each upload attempt consists of two HTTP requests: the 1st to get the current file size on server, the 2nd to upload the remainder of the file. Problem: a) if the upload server is overloaded and requests are succeeding with probability X, then the chance of both requests succeeding is X^2. So e.g. a per-request success rate of 0.1 becomes an overall success rate of 0.01. b) the get file size request can be avoided in some cases. New: If we've already queried the file size and haven't uploaded any additional bytes, don't query the file size again. client/ pers_file_xfer.cpp Another: If the file is smaller than a certain threshold (eg. 4KB), don't EVER bother sending the first request asking for the file size. When the file is so small, sending that first request wastes more resources than needlessly sending the entire file when in fact only a few bytes were left. ___ 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] Catastrophe is looming; desperately need advice
El Martes 21 Jul 2009 16:54:01 Martin escribió: My thought is that we must have a semantic shift so that what is usefully utilised is rewarded, and not just *time spent* (perhaps busyly uselessly spinning wheels) on whatever hardware. The GPU and CPU apps don't necessarily make the same amount of floating point operations. If someone optimizes one of the two apps so that it can do the same with (slightly?) less calculations, and you grant credits per flops, then GPU and CPU get different credits for doing the exact same task (meaning same input, same output). If that happens, credits aren't really reflecting work done, in my opinion. By the way, credits are already defined proportional to flops: 1/100th day of CPU time on a computer that does both 1000 double-precision MIPS and 1000 integer MIPS. In other words, a 1 GigaFLOP machine, running full time, produces 100 units of credit in 1 day. ___ 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] Catastrophe is looming; desperately need advice
El Miércoles 22 Jul 2009 09:43:52 john.mcl...@sybase.com escribió: Rank is rather hopeless as a metric. I dedicate 1% of computing power to some projects and I am in the top few. On others I dedicate 33% of computing power and I am not in the top thousand. If you want to get into the top few quickly, you'd crunch for projects in the former group; that is, those with the least users. But if many people do that, then the project will start getting more users, and it will be harder for everybody to stay in the top few. So they may move to another that still has few users. So it would distribute computing power across projects, which is what we want, isn't it? ___ 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] Some CUDA related questions
El Miércoles 22 Jul 2009 06:25:11 Oliver Bock escribió: Sending sigkill (ctrl-c) to an application that is currently running a kernel on the GPU may not result in a clean shutdown of the process as the kernel may continue running for a long time afterwards on the GPU. In such cases, a system restart may be necessary before running further CUDA or graphics applications. SIGKILL is the one signal that is impossible to block by an application; the kernel will really kill the app and the app can do nothing to avoid it. BOINC doesn't use it to terminate applications. (by the way, ctrl-c is sigint, not sigkill) On Unix, when the client asks a science app to quit, the science app will call plain old exit(). Cleanup functions configured with atexit() will be called. On Windows, the science app kills itself with TerminateProcess(GetCurrentProcess()) ___ 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] credit goals
El Miércoles 22 Jul 2009 14:35:37 David Anderson escribió: Nicolás Alvarez wrote: So it would distribute computing power across projects, which is what we want, isn't it? Not exactly. We want projects that are doing better or more important science (as judged by volunteers) to get more computing power. The main criterion for choosing a project should be its scientific merit, not how much credit it grants. This goal is called credit neutrality. f...@home's GPU app is 3 times faster than its CPU app. b...@home's GPU app is 4 times faster than its CPU app. How can you satisfy all of these? 1. credits per day in CPU app same for both projects 2. credits per day in GPU app same for both projects 3. within each project, same WU should give same credits no matter the processor used (Currently, we are completely ignoring #2) ___ 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] credit goals
El Miércoles 22 Jul 2009 21:17:02 Martin escribió: How can you satisfy all of these? 1. credits per day in CPU app same for both projects 2. credits per day in GPU app same for both projects 3. within each project, same WU should give same credits no matter the processor used (Currently, we are completely ignoring #2) Credits per day does not make sense across different hardware with very different capabilities and across different projects. 1. and 2. were, of course, comparing the same CPU/GPU from the same computer. ___ 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] credit goals
El Jue 23 Jul 2009 10:10:06 john.mcl...@sybase.com escribió: A few thoughts: There is no guarantee that any two computation devices (general sense here) will be equally efficient at a particular computation. The CPU and GPU in a single box may very well have different efficiencies, and should be treated as separate computation devices for credit comparisons. Okay, let me re-write that. I meant that in goal 1, I was comparing a CPU in one project with the *same* CPU in the other project, and in goal 2 I was comparing a GPU in one project with the same GPU in the other project. *Not* that the CPU and the GPU had to be in the same computer, or that I was comparing CPU with GPU. ___ 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] Some CUDA related questions
El Jue 23 Jul 2009 05:18:33 Oliver Bock escribió: On Wednesday 22 July 2009 19:31:24 Nicolás Alvarez wrote: El Miércoles 22 Jul 2009 06:25:11 Oliver Bock escribió: Sending sigkill (ctrl-c) to an application that is currently running a kernel on the GPU may not result in a clean shutdown of the process as the kernel may continue running for a long time afterwards on the GPU. In such cases, a system restart may be necessary before running further CUDA or graphics applications. SIGKILL is the one signal that is impossible to block by an application; the kernel will really kill the app and the app can do nothing to avoid it. I suppose you mean the BOINC client (not the kernel) killing the app...? That's the problem: *if* a CUDA kernel, or its controlling host application respectively, isn't supposed to be killed (because of the problems described above) this behavior by the BOINC client *might* cause problems. No, I meant the *operating system's kernel* would kill the process if another app sends that process a SIGKILL signal, without giving it any opportunity to do any app-specific cleanup. ___ 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 compiling filesys.h (win32)
El Jue 30 Jul 2009 17:19:56 Jeremy Cowles escribió: I am trying to include filesys.h in a project using the BOINC API and I'm getting the following errors (only under win): error C2146: syntax error : missing ';' before identifier 'handle' boinc\lib\filesys.h 111 error C4430: missing type specifier - int assumed. Note: C++ does not support default-int boinc\lib\filesys.h 111 error C4430: missing type specifier - int assumed. Note: C++ does not support default-int boinc\lib\filesys.h 111 On the middle line of the following block (filesys.h:111): #if defined(_WIN32) !defined(__CYGWIN32__) HANDLE handle; #else The code seems fine to me. Also, it compiles when I am building BOINC from source - it only fails in this project. filesys.h is using HANDLE without including Windows API headers first; relying on the fact that all .cpp files using the header already include it themselves. That's wrong; header users shouldn't need to care about things the header depends on. ___ 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] Team page team join link and stats links
El Vie 31 Jul 2009 19:53:22 David Anderson escribió: John 37309 wrote: I only just noticed a few minutes ago that if you are logged out of a project, the link to join a team does not appear on the team page of a project any more, don't really know how long its been like that. Can this be fixed please so the Join team link is always there, logged in or not? I'm always logged in so thats why i did not notice until now. This would introduce a cross-site scripting vulnerability. Why would it? ___ 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 immutability between platforms?
El Lunes 03 Ago 2009 20:58:11 Jeremy Cowles escribió: I currently have two files: linux/python26.zip win/python26.zip These files each have distinct contents (i.e. win has .dll files and Linux has .so files), if I install these files as follows: apps/pymw/pymw_1.00_i686-pc-linux-gnu/python26.zip apps/pymw/pymw_1.00_windows_intelx86.exe/python26.zip Will BOINC think they are the same file or will it keep them separate? They will overwrite each other when you run update_versions; both will end up in the same place of the PROJECT/download/ hierarchy. ___ 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 immutability between platforms?
El Lunes 03 Ago 2009 21:15:36 Jeremy Cowles escribió: 2009/8/3 Nicolás Alvarez nicolas.alva...@gmail.com El Lunes 03 Ago 2009 20:58:11 Jeremy Cowles escribió: Will BOINC think they are the same file or will it keep them separate? They will overwrite each other when you run update_versions; both will end up in the same place of the PROJECT/download/ hierarchy. Yeah, that's what I figured. So I guess the standard way to work around this is to embed the platform in the filename? Yes, and preferably also a version number, in case tomorrow you notice you missed a file from the zip. ___ 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] Progress Thru Processors Launched
El Miércoles 05 Ago 2009 09:35:30 Maureen Vilar escribió: It appears to me that the alpha-testing process (which to my knowledge no CPDN moderators participated in) was not thorough enough to throw up all the problems likely to be experienced by Boinc-naive prospective members. I've italicised aspects of the PtP installation process that I think should be changed or improved. I still couldn't even register because PTP doesn't work if my Facebook name has international characters. And my name has only an á character. A user called 李翔 recently posted on PTP wall, so there is definitely a need for international support... ___ 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] *SPAM* Re: Spam on Trak tickets
El Martes 11 Ago 2009 13:00:41 Jorden van der Elst escribió: Isn't it possible to truly lock tickets when they're locked (only those with an admin tag can reopen them or add comments), or otherwise add a recaptcha to writing any comment on any ticket? It's reasonable for *users* to reopen tickets if they find the bug still exists. ___ 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 compiling head rev
I think it's related to the proxy code changes. Can you get a backtrace of that segfault? Enviado desde mi iPod El 13/08/2009, a las 12:18, Eric Myers my...@spy-hill.net escribió: On Wed, 12 Aug 2009, Jeremy Cowles wrote: Is anyone else having this problem or is it just me? I've also seen some problems lately with the head, but I didn't look closely until you posted. But my problem is different. The code compiles, but the apps, both concat and upper_case as well as hello, yello etc. fail to run correctly in standalone mode.The return code for concat and upper_case is 193. It looks like hello has a SIGSEGV. I can post a full log if it would help. This is on both FC4 and F8 machines. Kathryn, have you seen this too? It's been doing this for the past 3 or 4 days now. I usually ignore such things unless they stick around, because they are often due to work in progress. But some change a few days ago seems to have broken running apps standalone, even when everything compiles. -Eric -- Eric Myersmy...@spy-hill.net 503-564-4169 PGP Key #6E2D2259/RSA: BA39 1D46 5EC3 0D59 C2AC 6FCB F920 4DC8 PGP Key #E519EAC3/DSS: D15B 9A50 B1ED 2947 EC29 B0F6 EA61 FB6E E519 EAC3 ___ 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] AMD Core Math Library (ACML) redis tribution; faster FFTs
El Vie 14 Ago 2009 06:39:08 Bruce Allen escribió: Hi Eric, Thanks -- this is very helpful. Before going forward, I have a question. It sounds as if s...@home is distributing an executable that statically links the FFT libs. Is that correct? My understanding of the licensing issues is that if the linking to FFT libs is done dynamically at run-time on the hosts, rather than statically, then there are no GPL/non-GPL compatibility issues. In other words, a dynamic executable of pure-GPL code is allowed to dynamically link at run-time to a proprietary non-GPL library. No, I don't think so. For the GPL, static vs dynamic linking is irrelevant. You should have the right to modify, under GPL-compatible terms, all of the code that ends up running within the same process, except libraries that come with the operating system such as libc (or msvcrt). ___ 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] AMD Core Math Library (ACML) redis tribution; faster FFTs
El Vie 14 Ago 2009 13:00:41 Nicolás Alvarez escribió: El Vie 14 Ago 2009 06:39:08 Bruce Allen escribió: Hi Eric, Thanks -- this is very helpful. Before going forward, I have a question. It sounds as if s...@home is distributing an executable that statically links the FFT libs. Is that correct? My understanding of the licensing issues is that if the linking to FFT libs is done dynamically at run-time on the hosts, rather than statically, then there are no GPL/non-GPL compatibility issues. In other words, a dynamic executable of pure-GPL code is allowed to dynamically link at run-time to a proprietary non-GPL library. No, I don't think so. For the GPL, static vs dynamic linking is irrelevant. You should have the right to modify, under GPL-compatible terms, all of the code that ends up running within the same process, except libraries that come with the operating system such as libc (or msvcrt). See: http://www.fsf.org/licensing/licenses/gpl-faq.html#GPLIncompatibleLibs ___ 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] [Fwd: Re: [BOINC] #139: Project-by-project network disable (similar to communications deferred)]
El Vie 14 Ago 2009 15:04:51 Lynn W. Taylor escribió: It seems to me that the big fear is the two-week timer: if a work unit can't be uploaded in two weeks, it's going to be thrown away, causing irreparable harm to the project and a tragic hit to the cruncher's RAC. It'd probably help to make that two-week timer a whole lot longer (4 months??), just to reduce the perceived danger -- and the pressure to replace a server. Right. As mo.v mentioned, two weeks is NOT plenty of time to obtain funding for a new upload server, order it, take delivery and install it. ___ 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] AMD Core Math Library (ACML) redistribution; faster FFTs
El Dom 16 Ago 2009 18:06:27 Bruce Allen escribió: Thanks for the note and for the link. Does this mean for example that GPLd code is not allowed to link to the CUDA libraries (which are non-GPL and not normally distributed with the OS)? The libraries don't have to be GPL. They can also be a *more liberal* license, such as LGPL or BSD. A GPL program, however, normally can't be linked to a proprietary library, unless the program has an exception on its license saying the copyright holder explicitly allows linking to that one proprietary library. Or a GPL library could say proprietary programs are allowed to link to it but only if they use a certain subset of API functions. Does this mean that GPL programs can not display on an NVIDIA graphics card (since they need to send data to an NVIDIA device driver, not distributed as part of the OS?). A device driver isn't linked to the program that uses it; they interact via IPC. Otherwise, it wouldn't be legal for proprietary programs to run on Linux, since they are making syscalls to the Linux kernel, which is GPL. ___ 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] AMD Core Math Library (ACML) redistribution; faster FFTs
El Dom 16 Ago 2009 18:40:15 Bruce Allen escribió: Hi Nicolás, Thanks for the note and for the link. Does this mean for example that GPLd code is not allowed to link to the CUDA libraries (which are non-GPL and not normally distributed with the OS)? The libraries don't have to be GPL. They can also be a *more liberal* license, such as LGPL or BSD. I was asking specifically about the CUDA libraries: http://developer.download.nvidia.com/compute/cuda/2_2/toolkit/docs/cudaprof _eula.pdf This license expressly does NOT include any source code and forbids efforts such as reverse engineering to recontruct the source code. So it is not 'more liberal' than GPL. My question is, can GPL code be linked against the CUDA library? I assume from what you wrote previously, that the answer is 'no' but wanted to confirm it. The answer is no, *unless* the GPL program has an exception allowing linking to the CUDA library. And then, any GPL library used by that program needs a similar exception. Does this mean that GPL programs can not display on an NVIDIA graphics card (since they need to send data to an NVIDIA device driver, not distributed as part of the OS?). A device driver isn't linked to the program that uses it; they interact via IPC. Otherwise, it wouldn't be legal for proprietary programs to run on Linux, since they are making syscalls to the Linux kernel, which is GPL. I'm confused about this point. On Linux, device drivers are executable code blocks that can be dynamically loaded into the running kernel. This is essentially the same mechanism by which a running program loads a library. The kernel (GPL in the case of Linux) has to load a '.ko' object file. If this is (for example) a proprietary device driver from NVIDIA, this would appear to violate GPL as you have described it. The Linux kernel has an exception allowing proprietary modules, but with many restrictions. For example, they can only use a subset of kernel APIs, and they must call a function to declare they are proprietary, which sets a global tainted flag in the kernel. If your kernel crashes, the error will say whether it's tainted, and you're unlikely to get help if it was (since people will immediately blame the proprietary module for the crash). [As far as I know, data is not passed by a program to a kernel device driver via IPC (which usuallly involves sockets). Data is passed by a program to a device driver on the stack. The device driver code is then executed by the kernel in 'kernel mode' rather than in 'user mode'. Data in the heap is usually explicitly copied from the process memory segment (userland) to kmalloc()d space in the kernel context (kernel space). But since I'm a physicist and not a computer scientist I could be wrong about this.] Whether programs are linked to the kernel, and whether a system call (talking to the kernel itself or to a loaded driver) is 'legally' equivalent to a function call between a program and a library, is in fact subject of some debate; so don't quote me on the subject :) ___ 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] AMD Core Math Library (ACML) redis tribution; faster FFTs
El Lunes 17 Ago 2009 20:56:27 Eric J Korpela escribió: 2) Is IMKL or ACML covered by the GPL v2 clause However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. or the GPL v3 clause I posted earlier (if the license is v2 or later)? If the Intel compiler is required in order to use IMKL and an AMD compiler is required to use ACML, you could probably make the claim that it is allowed, especially if those libraries are included by default in any builds with that compiler. If you can link to these libraries using a stock GCC or Visual-C++ compiler, then that claim gets more difficult to make. For this point, I think you should ask licensing at fsf dot org. ___ 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_cvs Digest, Vol 57, Issue 17
El Martes 18 Ago 2009 19:50:52 Kamran Karimi escribió: This works fine if the app treats such argument as optional. So BOINC apps should just ignore any command line options they don't understand. Projects can change the name of these arguments on the server, so a clash can be avoided. Exactly, so now you're putting yet another requirement on BOINC applications. For apps to work in BOINC, they have to ignore arguments they don't understand (so a typo in a project-provided command line switch won't be noticed, it may just calculate the wrong thing), or they have to ignore the specific set of arguments used by BOINC for its own purpose (--device and now --num_threads), which means devs have to know what they are. It's much simpler if you could say: what you put in command_line in the WU template or in create_work is passed to the science app untouched. ___ 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_cvs Digest, Vol 57, Issue 17
El Martes 18 Ago 2009 20:13:19 Lynn W. Taylor escribió: There is no reason to *not* correctly handle surprising command line options. There is no reason for the client to mess with data given by the project before handing it to the app. What next, the client adding tags to XML input files used by apps, and people defending it because apps should correctly handle surprising tags? ___ 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_cvs Digest, Vol 57, Issue 17
El Martes 18 Ago 2009 20:45:19 Lynn W. Taylor escribió: No, I don't. It seems that you're arguing that the BOINC science applications should be fragile -- that they should expect a pristine and unchanging environment and not try to anticipate the inevitable errors. I can't say it better than Jon Postel: be conservative in what you do, be liberal in what you accept from others. By adding command line arguments on top of what the project asks for, the BOINC client is not being conservative... ___ 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_cvs Digest, Vol 57, Issue 17
El Martes 18 Ago 2009 20:53:50 Lynn W. Taylor escribió: Nicolás Alvarez wrote: El Martes 18 Ago 2009 20:45:19 Lynn W. Taylor escribió: No, I don't. It seems that you're arguing that the BOINC science applications should be fragile -- that they should expect a pristine and unchanging environment and not try to anticipate the inevitable errors. I can't say it better than Jon Postel: be conservative in what you do, be liberal in what you accept from others. By adding command line arguments on top of what the project asks for, the BOINC client is not being conservative... My point is not about what BOINC should do, but that a science application that expects a perfect, pristine, unmolested command line is asking for trouble. The robustness principle is often misunderstood. The idea is that, given invalid input data, it shouldn't *crash*. Which doesn't mean it should behave as if the invalid data wasn't there. a...@home, for example, crashes with a segmentation fault if given --nthreads without following it with a number (that's a custom parameter given by the project). It would be more robust if it printed an error message to stderr saying the command line is incorrect, and called exit(1). But it wouldn't be a good idea if it continued ignoring --nthreads and using a default number of threads. ___ 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] Distributed data functions
El Miércoles 19 Ago 2009 19:37:45 Mark Pottorff escribió: I've been reviewing BOINC server code and the BOINC server VM. All of the distributed data command line programs indicate they should be run from the project root directory, however I don't find them there. If found request_file_list, get_file, send_file, and delete_file all in the /boinc/sched subdirectories. This was true both in the RHEL environment where I built from source, and in the VM image distributed by berkeley. I was just wondering where the problem lays, in the doc or in my environments. It would seem the program wouldn't know which project to add WU and mth rows to unless it were run from within the project's directory structure. Indeed if I run from that directory I get: Can't parse ../config.xml: fopen() failed So I'm thinking perhaps the build is flawed and should be moving the compiled programs in to the project's /bin directory?? And then the doc should be revised to show each being run from the project root with a ./bin/ prefix on the program name? I did get it to work by doing the following from project root: ../../boinc/sched/send_file -host_id 1 -file_name test_filexfer but I don't believe that was the intended use. Also, the documentation states that the client will acknowledge a successful download, and upload, but it does not indicate how such acknowledgment is made. How does the server know when the download of the actual data file has been completed to the client? And why wouldn't one want an acknowledgment that the client has completed a file deletion? They should be run from the project root directory means that the project root directory has to be the current directory when you run them. It's the same for most commands. These tools just happen not to be installed into the project's bin directory. Either way, most of the distributed data functionality is broken. I did just enough fixing to successfully send a file to a client and get it back, and described it in the message BOINC file storage features to boinc_projects (29/05/2009), which seems to have been ignored. ___ 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_alpha] Linux 32bit 6.6.36 manager won't start client
El Jue 11 Jun 2009 11:04:13 Kathryn Marks escribió:
On Thu, Jun 11, 2009 at 10:37 PM, Jorden van der Elst
els...@gmail.comwrote:
Hi Rom,
Why did all of the 6.6.36 versions go out as recommended versions
without even testing them?
Now we're getting reports in that BOINC Manager won't start the client
when you run the boinc-manager script, plus an apparent key library
file is missing on starting BM on 32bit Linux. it works correctly on
64bit Linux.
I'm on 64 bit Fedora 10 currently. The run_manager script starts the
manager but the manager fails to start the client. This is in a clean
install in ~/kathryn/BOINC (directory created by the .sh).
Almost two months later, still no new 6.6 with this fixed. I guess PTP and ATI
are more important (or hyped) than getting Linux BOINC to *work at all*.
Code to detect if the client is running, for non-Windows:
sprintf(path, %s/%s, (char *)wxGetApp().GetDataDirectory().char_str(),
LOCK_FILE_NAME);
if (file_lock.lock(path)) {
running = true;
} else {
file_lock.unlock(path);
}
file_lock.lock() tries to open() the file and then lock it with fcntl(). If
that fails, then the client is assumed to be running and locking the file
exclusively. Even if the failure is not actually because of exclusive locking
by another process. Nobody ever looks at errno.
Here's the code that fills in the variable later returned by GetDataDirectory,
on Linux (that is, after removing Win-only and Mac-only code):
void CBOINCGUIApp::DetectDataDirectory() {
}
The string is initialized to wxEmptyString, so after this code (or lack
thereof), it will stay empty. Empty string + /lockfile = /lockfile, which
is a file in the filesystem root. I have confirmed with strace that this is
the path the manager is trying to open().
Since the manager doesn't run as root (at least I'd hope nobody is that
stupid), it cannot open() a file in the filesystem root. Since
FILE_LOCK::lock fails, the client is assumed to be running, and it's not
started again. And then this happens:
maelcum hi. i just upgraded from 6.4.something to the latest version and now
the manager doesn't show any projects anymore.
maelcum it's as if i didn't have any accounts.
maelcum this is on linux.
maelcum what can i do?
[...]
PovAddict go to Messages
PovAddict look for a line starting with Data directory:
maelcum messages is 100% empty
PovAddict o_o
PovAddict then it's not running at all, I'd say...
maelcum okay, that's a start
This was fixed in r18420 by first checking if the lockfile exists, but
citing a rare race condition. (Obviously committed before even testing if
it compiled, since r18421 added a missing parenthesis). It was then ported to
the 6.8 branch, but not to 6.6.
Can we now have a working 6.6 for Linux please?
___
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 Binary in boinc 6.6.36
El Jue 27 Ago 2009 15:32:52 Eric J Korpela escribió:
I still get all the binaries.
Do they correctly end up in the stage/${prefix}/bin directory if you
do a make stage?
This is the preferred method of making files for a binary package
rather than building under a chroot.
But then you get files thrown directly into your system's /etc no matter what
the stage directory is.
--
Nicolas
___
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] Segfault in boinc_get_init_data.
El Jue 27 Ago 2009 15:46:23 Eric J Korpela escribió: On Thu, Aug 27, 2009 at 11:43 AM, Eric J Korpela wrote: Does anyone know what has changed in PROXY_INFO that causes segfaults when boinc_get_init_data is called? Did someone change the init_data.xml format? If so, is a segfault the best way to react if a field is missing? There was a time when the file wasn't required to exists at all. The first stack dump is if init_data.xml doesn't exist. #0 0x029524ce in std::string::assign () from /usr/lib/libstdc++.so.6 #1 0x029525e4 in std::string::operator= () from /usr/lib/libstdc++.so.6 #2 0x08116a47 in PROXY_INFO::operator= (this=0x821ead4, new_...@0x8264cf4) at proxy_info.cpp:192 #3 0x0810e65f in APP_INIT_DATA::copy (this=0x821d600, a...@0x8263820) at app_ipc.cpp:102 #4 0x0810e7a4 in APP_INIT_DATA::operator= (this=0x821d600, a...@0x8263820) at app_ipc.cpp:70 #5 0x0810a595 in boinc_get_init_data (app_init_da...@0x821d600) at boinc_api.cpp:644 #6 0x0804d102 in main (argc=1, argv=0xbfecacb4) at main.cpp:259 The second is if it does... #0 0x029524ce in std::string::assign () from /usr/lib/libstdc++.so.6 #1 0x029525e4 in std::string::operator= () from /usr/lib/libstdc++.so.6 #2 0x08116a47 in PROXY_INFO::operator= (this=0x821ead4, new_...@0x8264cf4) at proxy_info.cpp:192 #3 0x0810e65f in APP_INIT_DATA::copy (this=0x821d600, a...@0x8263820) at app_ipc.cpp:102 #4 0x0810e7a4 in APP_INIT_DATA::operator= (this=0x821d600, a...@0x8263820) at app_ipc.cpp:70 #5 0x0810a595 in boinc_get_init_data (app_init_da...@0x821d600) at boinc_api.cpp:644 #6 0x0804d102 in main (argc=1, argv=0xbfecacb4) at main.cpp:259 Oops the second stack dump. (When app_info.xml does exist) should be #1 0x08116c0a in PROXY_INFO::clear (this=0x8264cf4) at proxy_info.cpp:168 168 socks_server_name.clear(); (gdb) where #0 0x0295212f in std::string::clear () from /usr/lib/libstdc++.so.6 #1 0x08116c0a in PROXY_INFO::clear (this=0x8264cf4) at proxy_info.cpp:168 #2 0x08116ef4 in PROXY_INFO::parse (this=0x8264cf4, i...@0xbfbb0810) at proxy_info.cpp:93 #3 0x0810d811 in parse_init_data_file (f=0x9cef730, a...@0x8263820) at app_ipc.cpp:260 #4 0x0810b442 in boinc_parse_init_data_file () at boinc_api.cpp:598 #5 0x0804d0f6 in main (argc=1, argv=0xbfbb0994) at main.cpp:258 parse_init_data clears the APP_INIT_DATA structure using memset, corrupting the internal structure of the std::string members. -- Nicolas ___ 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] Distributed data functions
El Vie 28 Ago 2009 16:55:04 David Anderson escribió: Currently the client doesn't do this. But it should and someday it may, which is why that statement is there. Right, the documentation shouldn't say what the client does, but what client behavior the server can rely on. -- Nicolas ___ 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_alpha] Card Gflops in BOINC 6.10
El Sáb 29 Ago 2009 00:30:44 Josef W. Segur escribió: First thoughts: Whetstones don't measure peak performance, more like minimum performance. The benchmark is of very basic funtionality and does not take advantage of improved architectures, instruction sets, etc. It would take advantage of advanced instruction sets if the C++ compiler uses them. What it doesn't do is use significant amounts of memory. It all fits in the CPU cache, so it would give *higher* performance than a real app. -- Nicolas ___ 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.
