1) Message boards : BOINC client : active_frac Question (BUG?) (Message 12857) Posted 5 Oct 2007 by Arcturus Post: Thank you. This exact same problem has been driving me nuts for about a week or two now. I'm running a dual core that is on 24 hours a day, 7 days a week and I recently noticed that it was only running two projects at a time with no additional work being downloaded until the ones that were running completed. I tried increasing the minimum work and additional work buffers to no avail. I ran across this thread today and set my active_frac to 0.900000 and instantly got new work units. Unfortunately, both my minimum work and additional work buffers were both set to 10 and I got just a wee bit more work than I wanted to so I reset them both, aborted the unwanted work units and now everything is operating the way I would expect it to.

2) Message boards : BOINC Manager : Advanced:Select computer... (Message 8243) Posted 15 Feb 2007 by Arcturus Post: Thanks, Nicolas, for saving me the trouble of typing the path. I don't care that it stores the computer name. That's actually somewhat convenient, even if it is a bit less secure. What I care about is where it stores them. I expected that it would store them in an XML file in the Boinc folder and, when I wanted to edit the list of computer names presented, I was unable to locate it. After some on and off searching, I gave up until I stumbled upon it in the registry last night. Why do I object to it being in the registry? 1. It's much harder to find and edit should the need arise. 2. The average Windows user is scared to death of editing their registry. This, by extension, makes Boinc less user friendly than it could be. 3. IMHO, the Windows registry is somewhat cryptic and I dislike any unnecessary tinkering with it (automated or manual) because of that fact. (Yes, I know, I can buy books that tell me all about it, but I still don't like it.) 4. Accidentally type your password in the computer name field and forget you ever saw this chain. (Yep, that's why I wanted to edit the list of computer names. It was either that, or go out and change the password on all of them.)

3) Message boards : BOINC Manager : Advanced:Select computer... (Message 8203) Posted 14 Feb 2007 by Arcturus Post: Why does Boinc store the names of your computers in the registry instead of creating an xml file in the Boinc directory as it does for all of its other parameters?

4) Message boards : BOINC client : My Clock Got Messed Up.. Now Boinc Isn't Requesting New Work (Message 8047) Posted 7 Feb 2007 by Arcturus Post: I see that Jeff managed to get his problem fixed a couple of weeks ago but the action he took was perhaps more drastic than it needed to be. Having experienced the same problem myself at about the same time, I can state with confidence that his problem was with his long term debt. There are several ways he could have handled this short of a complete reinstall. He could have, as was mentioned (but not specifically recommended), used a third party utility to reset his long term debt. I'm told there are several of them out there that will do this but have never used one myself. (Note: Boinc should not be running when this is done.) He could have edited client_state.xml manually with notepad or another editor, replacing the existing values for long term debt for all of his projects with 0.000000. (Note: Boinc should not be running when this is done.) As he stated he did, he could have set "No new tasks" for each project and waited for the queue to drain of all work. Instead of the uninstall, reboot and reinstall of Boinc, he could simply have detached from all of his projects and then reattached to them all. This would also have cleared his long term debt and, for those who are not comfortable messing with the client_state.xml file or are unsure of how to shut down Boinc and confirm it is not running, is a completely safe alternative. Given enough time (I would guess 6 months, maybe less, depending on how the long term debt was distributed across projects), the problem would have cleared itself up since SETI would have been 'repaid' the time debt it was 'owed' by the other projects due to the system time problem.

5) Message boards : BOINC Manager : Undesirable interaction between system date and BOINC (Message 7812) Posted 25 Jan 2007 by Arcturus Post: My gaff on account manager. I reread these things 10 times and I still make semantic errors. I meant to say Boinc manager. Careless of me. "This is why you cannot have a button in BOINC Manager to reset/clear any debts. Because as soon as BOINC Manager runs, BOINC will be running and will be writing to the client_state.xml file." Which is why I said: "which I'm sure could be worked out by sending a signal to Boinc that would trigger the routine that actually calculates long term debt." I suppose I should have said "signal to the Boinc daemon" This sort of thing is part and parcel of the Boinc manager, else how could it direct client programs to suspend/transmit when the user clicks on suspend in the manager? I see no reason why the same thing cannot be done to send a "zero long term debt" signal to the Boinc daemon. In fact, when you quit a project, does not the Boinc daemon have to recalculate the long term debt because of the departure of the project? Same thing.

6) Message boards : BOINC Manager : Undesirable interaction between system date and BOINC (Message 7810) Posted 25 Jan 2007 by Arcturus Post: Forgive me, but I wasn't really prepared to launch into a full blown design discussion when I submitted my original email so my thoughts have been pretty much continuously reorganizing themselves as this thread goes along. I sometimes find it helpful to view the problem from a different perspective so, if you will indulge me, let's think about this from a financial perspective. We all carry loans throughout our lifetimes. They are a necessary evil. To keep this simple, let us only consider the principal for the loans. Short term debt is basically how much we expect our aggregate monthly payments to be in total. Long term debt is the total we expect to pay out over the lifetime of all of the loans. The order in which we make these monthly payments is basically the purpose of short term debt in Boinc. Now, in a benevolent society, if we were to fall behind in our payments to lender A, we could simply contact lender B and come to an arrangement whereby we could skip payments for a month or more so we could catch up with lender A and agree to make the missing payments at some future date. Lender A would obviously need to agree that during that 'repayment' period, they would not receive any payments. This, in an admittedly warped way, is analogous to the purpose of long term debt in Boinc. It allows us (or, more accurately, the vendors) to restructure our monthly payments so that we can favor one over the other for a short time period in a hopefully equitable way. This is where the analogy breaks down. It breaks down in our favor, however, because in Boinc, we never actually committed to the lender (i.e. the project) that we were going to ever pay them anything. We are not obligated to them for anything and we are free to cancel our 'debt' (both long term and short term) to them at any point in time without any prior notice. What I've been talking about in this email chain, however, is not actually about cancelling the debt, it's about going back to the original payment schedule that was worked out. A "cancel long term debt" option in the Boinc manager would effectively do just that because, by cancelling long term debt, we are simply saying that we don't care what agreement the vendors came to with each other and we are reverting to the original payment schedule. In fact, Ageless (the forum moderator), among others, directed me to a utility that does just that, so it is obviously an acceptable thing to do. In fact, I would even say a necessary thing to do if you want to share time between all of the projects you sign up for. Ageless did allude to the perils of doing so while Boinc is running, but that is a relatively minor issue to work out. (Simultaneous updates, that sort of thing, which I'm sure could be worked out by sending a signal to Boinc that would trigger the routine that actually calculates long term debt. The account manager doesn't actually have to do the dirty work.) So, if the arbitrary cancellation of all long term debt is not harmful to Boinc (if done properly), then all we are really talking about is designing an automated method of arriving at the same end point that does not involve requiring the user to recognize the situation and push a button. (Or several buttons simultaneously while blowing bubbles with a straw and juggling plates at the same time.) This is where the 'arbitrary' threshold comes in. It could be something as simple as saying that all projects must be given the opportunity to run at least once per week, or it could be something more complicated (such as an algebraic equation that factors in the number of projects being run and the users preferences.) The point is, doing so would make Boinc a more user friendly program, which is something that I've seen it trashed for in several of the forums that I have visited. Why not take a known issue with a known solution and use it as a starting point for overcoming that perception?

7) Message boards : BOINC Manager : Undesirable interaction between system date and BOINC (Message 7801) Posted 25 Jan 2007 by Arcturus Post: Excuse me? I believe that you are the one who insists on dragging other date related functions into the discussion, not me. I have confined my comments to the issue that I originally brought up and, whenever you have attempted to redirect the conversation, I have simply responded with a correlation between that distraction and my original proposal. Arbitrary threshold? Yes, I did use that term originally but, as the discussion progressed, I also suggested that a possible alternative exists that could be based on a mathematical algorithm that incorporates other parameters contained within the Boinc system. I would hardly call a mathematical formula (which, before you even go there, I did not put forth or even attempt to prove the existence of) an 'arbitrary' threshold. When you use the term 'we', do you mean to imply that you are affiliated with Boinc in any way and that you are one of the inidividuals who maintains the source code? If so, I would be more than happy to explore the possibility a little further. We could each grab a current copy of the source code and walk thru it together. It is, after all, open source and making improvements to it would be totally in keeping with the spirit of the open source movement.

8) Message boards : BOINC Manager : Undesirable interaction between system date and BOINC (Message 7797) Posted 25 Jan 2007 by Arcturus Post: I believe that there is already a sanity check in place for communications with the server so that would not be affected by an incorrect setting of the system date. In that regard, it is no different than what I am proposing for long term debt.

9) Message boards : BOINC Manager : Undesirable interaction between system date and BOINC (Message 7794) Posted 25 Jan 2007 by Arcturus Post: You must keep in mind the audience that is being asked to run BOINC. Many (I hesitate to say most) of the users of Boinc are relatively ignorant of the interior workings of the system and, especially, of the inner workings of Boinc. Expecting them to edit cryptic configuration files manually is hardly what I would call user friendly and is more likely to turn people away from distributed computing than it is to attract them to it. As far as checking to make sure things are shipshape before starting the programs is concerned, the 'mistake' happened WHILE Boinc was running because Boinc starts when my PC is booted up. (I'm assuming this is how most people set theirs up as well.) Perhaps you can point out to me exactly where the option is located to instruct Boinc to terminate so that I can safely adjust the date? (Or perform any other kind of maintenance, for that fact.) Since Boinc is invoked at startup, rebooting your PC is not a viable shutdown alternative, which basically leaves you with the Windows task manager. Again, I'd say that is not at all in keeping with the concept of user friendly. As far as long term (and short term) debt is concerned, most Boinc users have no concept of what they are for. I'm kind of new to the concept as well but from what I understand, long term debt has nothing to do with the length of time that a project can run for. It has to do with the amount of CPU time that a project has previously managed to garner in relation to the other projects that the user has elected to run on their machine so that BOINC can fairly allocate computer resources among them. Assuming that to be the case, it is entirely possible to apply a 'sanity check' to the maximum long term debt. For instance, is it reasonable to expect that a single project has run for, in my case, 10 years, to the exclusion of all other projects? I think not. Therefore, whenever some arbitrary threshhold is exceeded (10 days? 1 month?), it would be a perfectly viable, and in my mind, acceptable option to reset all of the long term debt to zero and let all of the projects have an equal chance at running. Failure to do so would prevent the project(s) that just happened to be running at the time of the mistake from running again (after they swap out to give another project a chance to run) until the long term debt is 'paid' in full. Note that none of this relies on knowledge of the direction in time that the user has moved the clock, nor does it rely on the 'size' of the project being run. What it truly relies on is the resource share that the user sets up in their preferences so, while I have not done the math, it is wholly possible to determine what the proper threshhold should be by using simple algebra. (OK, toss in some additional boolean logic to account for project down time, etc., but, after all, that is what programmers do for a living, no?)

10) Message boards : BOINC Manager : Undesirable interaction between system date and BOINC (Message 7786) Posted 25 Jan 2007 by Arcturus Post: "But it's impossible to guard BOINC against user errors." Correction: It's impossible to guard against ALL user errors. Some are more difficult to protect against than others. Placing a maximum long term debt cap of 10 day or 1 month would at least prevent the situation I had where the long term debt was 10 years due to a fat finger mistake. In this instance, why punish the project(s) for my mistake?

11) Message boards : BOINC Manager : Undesirable interaction between system date and BOINC (Message 7780) Posted 25 Jan 2007 by Arcturus Post: I've already corrected the debt manually since it only takes a couple of minutes to do. Even so, they really ought to consider capping the maximum long term debt to prevent it from happening in the first place. Or, at least, to limit the amount of 'damage' that it does.

12) Message boards : BOINC Manager : Undesirable interaction between system date and BOINC (Message 7775) Posted 25 Jan 2007 by Arcturus Post: This is just a precautionary note to anyone who might happen to read it. Before changing the system date on your PC, MAKE SURE YOU SHUT DOWN BOINC AND LEAVE IT DOWN UNTIL YOU VERIFY THAT THE SYSTEM DATE IS CORRECT! Failure to do so could result in invalid statistics for whatever projects manage to contact the server while the date is set incorrectly as well as the corruption of the long term debt values for the projects that you crunch. I found this out the hard way when I accidentally set the year to 2017 instead of 2007. My long term debt is now approximately 400 million, so I have projects that won't be scheduled for approximately 10 years unless I manually adjust it. A long term debt reset option would certainly be a handy option to have in the Boinc manager for these types of situations! It might also be advisable to allow for the configuration of a 'maximum long term debt' value to prevent this from happening, or at least limit the damage it does when it does occur.

---

Copyright © 2024 University of California.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.