Posts by River~~

1) Message boards : Number crunching : Suggestion: separate gfx for s/s and manager (Message 2419) Posted 21 Oct 2006 by River~~ Post: In my view it is time to consider whether the screensaver should be the same graphic as that displayed on demand from the BOINC manager. Apologies for cross posting: I am putting this on Ralph, Einstein, and SETI boards so that all the coolest coders see it, but the really cool will see it 3x. I'm not currently on the BOINC forums/maillists so if someone would like to copy it there that is fine. A screensaver should be pretty but use very little code. Most of the time it will be running it will not be being looked at, and if it uses a lot of crunch time that will only hurt the project. It should not need user input because that conflicts with the fact that user input is supposed to interrupt the s/s completely and drop the user back into Word or whatever. A s/s should not use much memory either, as this makes it all the more likely that the user will experience a page-fault delay when they want to get back to Word. In contrast, when the user is hands-on, they want to look inside the model, see what it is doing now, rotate the protein, etc etc, all of which takes a fair amount of cpu time and all of which are much more entertaining if interactive and all of which typically gobble up more memory than the actual crunching. And a user who has being doing that will be less likely to even notice if there is a page file delay afterwards. There would be two ways to engineer this, depending whter BOINC or a project takes it up first. If BOINC then a future release of BOINC should be able to cope with there being different programs loaded as the s/s and as the "show graphics" response. Projects which still offer the same would simply provide the same program in both cases. If a project then the graphics part of the app should iteself have a test for "am I a s/s" early in the code and before the big chunky stuff is loaded. As a concession to those liking interactive s/s, there could be a cross-project standard that (say) ctrl-G during the s/s switched into advanced graphics mode. Perhaps this could even be the only key/mouse stroke responded to while acting as a s/s. After the usual s/s delay, the advanced graphics would lapse back to s/s mode, speeding up the crunching. The LHC s/s already does this, lapsing into a more efficient mode once the user stops prodding it. Just an idea for the future - clearly this is not on the urgent list but I do suggest it is worth thinking about in the longer term. I wonder how many protein decoys go untried, how many et's fail to phone home, how long Albert suffers with no waves in his gravy, while all the time the s/s is playing to an absent user? River~~
2) Message boards : Feedback : Creating work for Ralph (Message 535) Posted 23 Feb 2006 by River~~ Post: As to the forum bug ... I have reported it to the BOINC Devs ... - was going to do that when I got round to it (honest) but thanks for saving me the effort :)
3) Message boards : Feedback : Creating work for Ralph (Message 534) Posted 23 Feb 2006 by River~~ Post: Looks like they've implemented the idea River put forward. again (he says modestly) ;-)
4) Message boards : RALPH@home bug list : Report \"stuck at 1%\" bugs here (Message 533) Posted 23 Feb 2006 by River~~ Post: ... how exactly do you determine "stuck at 1%" under your Linux host? Do you check stdout.txt by hand? There are various ways 1. Use the BOINC Manager (this works locally if you have a GUI, or can be used remotely - you can even use the standard manager from a Win box to monitor a Linux box - see details on remote control in the wiki) 2. Use BoincView from a Win box 3. In linux command line from the BOINC directory, use ./boinc_cmd --get_state\|less and look for the fraction complete (presumably will stick at 0.01 ??) 4. again in command line, from the BOINC directory, use less client_state.xml /active / till get to the one you want to look at, and scroll down till see the fraction done tag. (If you don't understand what I mean here, please see man less or info less for how to drive the less utility.) hope that helps someone (& feel free to borrow for any FAQ or wiki) R~~
5) Message boards : RALPH@home bug list : Report \"failure when switching projects without keeping applications in memory\" bugs here (Message 508) Posted 22 Feb 2006 by River~~ Post: btw Contact - cool sig ;-)
6) Message boards : RALPH@home bug list : Report \"failure when switching projects without keeping applications in memory\" bugs here (Message 507) Posted 22 Feb 2006 by River~~ Post: Got one here that survived a reboot, was restarted OK and ran after restart OK, but then died when pre-empted by Einstein. Interesting point for me was that it bombed out at the point of removal from memory rather than when re-loaded (or is this the usual experience with these???) EDIT: This survived a reboot, as stated above, but before reboot keep in mem = YES, after reboot keep in mem = NO, and it failed on first swap out after NO setting. But that seems bizarre - it implies it can be swapped out for a reboot but not for a pre-empt. Does that give our coders any clues, or is it a red herring? Sorry for the non-standard log format, this is a BoincView listing, the machine is in another building and I can't get to it to give you the proper log, and with the work already having reported back the /slot directories will have gone already. If this style of feedback is no use at all to you, please say so and I will take this box away from Ralph... bt-gw is the machine, and times are in UTC. Machine is running Debian Linux and not running any graphics. bt-gw 22/02/2006 19:55:56 --- Starting BOINC client version 5.2.8 for i686-pc-linux-gnu bt-gw 22/02/2006 19:55:56 --- libcurl/7.14.0 OpenSSL/0.9.8 zlib/1.2.3 bt-gw 22/02/2006 19:55:56 --- Data directory: /usr/local/BOINC bt-gw 22/02/2006 19:55:57 --- get_local_network_info(): gethostbyname failed bt-gw 22/02/2006 19:55:57 --- Processor: 1 GenuineIntel Pentium III (Katmai) bt-gw 22/02/2006 19:55:57 --- Memory: 377.75 MB physical, 737.32 MB virtual bt-gw 22/02/2006 19:55:57 --- Disk: 4.07 GB total, 3.24 GB free bt-gw 22/02/2006 19:55:57 LHC@home Computer ID: 79658; location: work; project prefs: default bt-gw 22/02/2006 19:55:57 Einstein@Home Computer ID: 469573; location: work; project prefs: default bt-gw 22/02/2006 19:55:57 ralph@home Computer ID: 896; location: work; project prefs: default bt-gw 22/02/2006 19:55:57 --- General prefs: from Einstein@Home (last modified 2006-02-22 16:24:36) bt-gw 22/02/2006 19:55:57 --- General prefs: using separate prefs for work bt-gw 22/02/2006 19:55:57 --- Remote control allowed bt-gw 22/02/2006 19:55:57 Einstein@Home Resuming computation for result r1_0937.0__80_S4R2a_1 using albert version 440 bt-gw 22/02/2006 19:55:57 ralph@home Deferring computation for result TEST_HOMOLOG_ABINITIO_hom001_1fna__214_54_0 bt-gw 22/02/2006 19:55:57 Einstein@Home Pausing result r1_0937.0__80_S4R2a_1 (removed from memory) bt-gw 22/02/2006 19:55:57 ralph@home Restarting result TEST_HOMOLOG_ABINITIO_hom001_1fna__214_54_0 using rosetta_beta version 484 bt-gw 22/02/2006 19:56:00 --- request_reschedule_cpus: process exited bt-gw 22/02/2006 20:56:01 Einstein@Home Restarting result r1_0937.0__80_S4R2a_1 using albert version 440 bt-gw 22/02/2006 20:56:01 ralph@home Pausing result TEST_HOMOLOG_ABINITIO_hom001_1fna__214_54_0 (removed from memory) bt-gw 22/02/2006 20:56:02 ralph@home Unrecoverable error for result TEST_HOMOLOG_ABINITIO_hom001_1fna__214_54_0 (process exited with code 131 (0x83)) bt-gw 22/02/2006 20:56:02 --- request_reschedule_cpus: process exited bt-gw 22/02/2006 20:56:02 ralph@home Computation for result TEST_HOMOLOG_ABINITIO_hom001_1fna__214_54_0 finished
7) Message boards : Feedback : Credit scores (Message 476) Posted 22 Feb 2006 by River~~ Post: Also, personally I really DON'T WANT to see projects send the SAME WU to 5-7 different PCs, presumably "for redundancy of the science". E.g. both R@H and F@H are fine, in that they don't WASTE donor resources. My CPU / bandwidth may be free to THEM, but it's NOT FREE to me. So I feel the projects have to respect donated resources and not waste or abuse them. A lot of projects feel this is needed to ensure calculating accuracy. Some work done on mainframes is similarly repeated - eg when a new record is claimed for so many billion digits of pi, the claim is never allowed unless that many digits have been calcualted twice and by differeing algorithms. Some participants also support redundancy, feeling that otherwise credit scores are meaningless - these are mainly the participaants who see BOINC as a sporting contest and enjoy the stats races. Equally a lot of project participants dislike feeling their work has only a one-in-N chance of being used - some like you because of their bandwidth, others because they value the cpu time, or others who think of their cpu cycles as valuable donations, or maybe count the cost of the electricity. The only advice I'd offer is to choose a project that suits your own preferences - and for some participants this would mean going outside BOINC, for others it means careful choice of projects within BOINC. I think it is clear low redundancy will be an attractive feature to many prospective participants.
8) Message boards : Feedback : Credit scores (Message 473) Posted 22 Feb 2006 by River~~ Post: Credit certainly doesn't mean anything here at Ralph (and hence they should stop people from collectiong the xml stats files for places like boincstats, but they should still create them) My view on this is different, as I siad on the Rosetta boards before Christmas when the possibility of this project was being discussed. I agree that credit should not be a priority in terms of it being accurate, I agree that credit should not be a priority in terms of the project team trying to retrospectively repair past errors on Ralph, as and when they occur, which they will. Where I differ is that I still think credits should be exported and picked up by BoincStats, etc. The reason is that even tho the exact amount of credit will be understated, the fact of participation in a dev project is something I am proud to have recorded in my stats and in my sig. Personally, I am more proud of the 111 credits I curtrently hold on Pirates than the almost 1000x as many I hold on CPDN, precisely because the Pirates credit reflects contribution to a development project. So while getting the dredit exactly right should not be a priority here, getting some credit to every participant in due course should (in my opinion) be allowed to happen and to be reflected in the stats sites. This opinion seemed to be generally supported in the Ralph pre-launch dicsussion last year. River~~ ps: see those 111 credits ... aren't they so cool -
9) Message boards : Cafe RALPH : uotd from Manchester England (Message 471) Posted 22 Feb 2006 by River~~ Post: sorted! congrats to MrDaliard for being user of the day, good to see you mention M/c in your profile, innit River~~
10) Message boards : Current tests : Switching between projects with applications removed from memory (Message 430) Posted 21 Feb 2006 by River~~ Post: hi David, a similar question based around the keep in memory issue. Am I right that where a machine is turned off daily, it would be useful to have the cpu time set long enough to force every WU to experience at least one power cycle? So with the machine left on for 7hrs/day, I'd set the cpu time well over 7hrs for example. River~~
11) Message boards : Feedback : Working with CPDN (Message 429) Posted 21 Feb 2006 by River~~ Post: I'd like to draw people's attention to the point that there is no guarantee that test WU from Ralph will not affect other projects. This means there is a small risk that ongoing work for another project might get toasted. For most projects that would be mildly irritating - a day's work or so lost. For CPDN that would be very annoying. My suggestion is to only let Ralph run on a CPDN box if the CPDN result has not yet reached say its fourth trickle, so that not too much time would be lost. Then take that box off Ralph for a long while, till the next CPDN WU starts. Alternatiely, if you ignore the above, do do do please make sure you backup the boinc directory regularly so that if Ralph fries the CPDN stuff you can roll back. Or, of course, don't run the Ralph on the same box as CPDN at all -- but that would be a pity, it wouyld be nice if there was at least some interworking. Once again, this is a private view from me as an individual participant - it is not official advice from either Ralph or from CPDN. River~~
12) Message boards : Feedback : Credit scores (Message 428) Posted 21 Feb 2006 by River~~ Post: If you have been around Distributed Computing since it's infancy, you should realize by now that a fair and equitable credit system is what keeps people at a project. Sure, you get a few percent who are in it "for the science", but reality is that the biggest portion of the crunching power comes for the credits, and leaves rather quickly when the credit system goes awry. On a production project you'd be right. That is why on Rosetta, the sister production project, David has put work in to correct errors that lose people credit. On a test project, like this, we do not need very many people, and we particularly want the people who are interested in building up the science. So while you are still right that when the credit goes awry a lot of people will leave, the difference is that here it won't matter - it could even be an advantage if it leaves us with a higher proportion of those who will give constructive feedback over problems other than credit. Like, a thousand crunchers is more than enough for a test project (so long as there is a good distribution of different speed boxes and different operating systems). If the only-in-it-for-the-credit crew self select themselves onto another project that is good news, not bad. Personally so long as they stay on any BOINC project I'd be delighted - I guess the official project view is to hope they'd move over to Rosetta in particular.
13) Message boards : Feedback : Creating work for Ralph (Message 426) Posted 21 Feb 2006 by River~~ Post: ... Actually I am not so sure River has this figured right. He is correct on the feedback rate, but, if someone with a high resource share is pounding the server, and they have their contact interval set high (big queue). When they get WUs they will get a lot of them. ... er no. On my scheme (small quota set by project, large resource share set by user) when a user gets work s/he will get the max number of WU as set by the quota. Users who do not set a large resource share will also get the same number, as set by the quota, but will simply take longer to return them - annoyng to David & colleagues but this will not affect how many other users get. edit: oh, Ive just read that David will not find this annoying... Users who set miniscule resource shares will get fewer than the quota. Users who set cache size of n days (n>1) may find their client only looks for work once every n days, so they'd only get a quota every n days. Overall, as m9 says, we cannot assume anyone will do as they are asked, but this scheme (a) makes it most advantageous to the user to do so, and (b) minimises the bad news for the rest of us if they don't. River~~
14) Message boards : Feedback : Creating work for Ralph (Message 424) Posted 21 Feb 2006 by River~~ Post: What makes any of you assume that the bulk of the users are going to set their systems in the way that you specify? ... The best solution for this it to not rely on the BOINC requesting system, beyond recognizing that a request for work has been made,... I was not assuming that. Your point actually strengthens mine: the quota is set by the project not by the user. By setting a low quota this limits the number of wu that can be downloaded in any one day. This is almost as good as limiting the number over a period of time, with the added advantage of not needing any new coding, just a change to the max quota size by the project admins. And, as you suggest, this is independent of what a user sets (unless a user chooses to download even less than that, of course...) River~~ PS - m9 I worked out why I could not find my posting before - there is a BOINC bug so that when a mod moves a posting, the 'latest post' times do not get updated. I hadn't looked in this thread as it looked like nothing had been added for three days... R~~
15) Message boards : Cafe RALPH : (DO NOT POST HERE) This is the Moderators Archive thread (Message 392) Posted 20 Feb 2006 by River~~ Post: hi m9 & colleagues, I got an email that you'd moved a posting of mine from the guidelines thread to the feedback thread, which is fair enough if that is a better place to put it. However, it seems that although the email says you moved it, in fact the thread has been hidden where it was before. Is this a bug, or did your mouse slip at the crucial moment? Feel free to delete this post once my original posting has been found, or let me know if it has been lost in cyberspace and I will type it in again R~~
16) Message boards : Number crunching : Are un supported operating systems welcome here ? (Message 383) Posted 20 Feb 2006 by River~~ Post: I have just attached a WinME box to this project, and am wondering if this is a useful thing to do. I realise that Win9x an WinME are not officually supported by Rosetta or Ralph, so that any operating ystem specific bugs that come to light may well not warrant attention. However my thinking is that even if the bugs are not fixed, given that a number of people currently do run Rosetta with unsupported OS's, it might be useful to know about any problems up front? If you tell me this is a bad idea, I will happily remove this box from Ralph right away. River~~
17) Message boards : RALPH@home bug list : Registering with boinc account to RALPH (Message 382) Posted 20 Feb 2006 by River~~ Post: I do think I understand running multiple projects. see sig, and there I was imagining your mouse had just slipped a few times... ;-)
18) Message boards : Feedback : Creating work for Ralph (Message 380) Posted 20 Feb 2006 by River~~ Post: Hi, Please do not consider my suggestion to be a change to the guidelines unless and until David adopts it in the main GUIDELINES thread. I am wondering why a low resource share? A high resource share would mean that when test WU are available, you get feedback fast. If you don't want one machine to crunch lots of wu, my suggestion would be to set a fairly low quota. That would mean that no machine could crunch many test units per day, but that turnround would also be quick. This would also prevent people from building up large caches of RALPH wu, even if they normally hold long caches for other projects. Finally it would mean a better spread of test WU between slow and fast machines. For bug-catching that would seem to be a better balance. River~~ edit - add: PS David, I'd suggest also you 'sticky' your guidelines thread too ;-)
19) Message boards : Cafe RALPH : Hi all... (Message 377) Posted 20 Feb 2006 by River~~ Post: What do we do if we arrived before the thread???......Oh, hi anyway try posting a question in green ink, maybe? ;)
20) Message boards : Cafe RALPH : Hi all... (Message 376) Posted 20 Feb 2006 by River~~ Post: hi everyone! gosh, step out for a fortnight and when I get back they've started another project ;-) River~~