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.

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.

But it's impossible to guard BOINC against user errors. ;-)

---

And it's not only BOINC, all programs are made assuming time goes always forwards and will never go back.

"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?

What we can avoid is some consequences of changing time, like using debt limit, but definitely not all. There would be no way to know how much it moved back (nothing to compare it to).

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?

Maximizing LTD is impossible to do with a project as CPDN. Its long term debt can easily be 6 months or more.

Next you ask if BOINC can check with an atomic clock if you filled in the correct date. Why should BOINC check (against) mistakes you make? It's called common sense. You check if everything is in ship shape before you start your programs.

In my opinion anyway. :-)

---

A long term debt reset option would certainly be a handy option to have in the Boinc manager for these types of situations!

Use BOINC Debt Viewer to reset your STDs and LTDs. Adding it to the BOINC Manager might confuse people, as you can't click it when BOINC is running...

---

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?)

Changing the date would affect a lot more than just debts. One example: imagine BOINC contacts a server while the date was 10 years in the future, and then defers communication for 1 minute. If you then correct the date, BOINC would be deferring communication for 10 years and 1 minute for that project.

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.

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.

So I understand you're suggesting we add sanity checks to everything remotely related to time, with arbitrary thresholds...

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.

[boinc_dev] Recovery from time setting.

It's quite impossible to make a program that can handle all the consequences of time going backwards, or forwards a big step. And like somebody said on the mailing list, BOINC would be expected to be a little concern compared to how much problems other programs would have with time changing.

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.

I own a project, I have made modifications to server code, but only looked *some *on the client code. And from what I saw, it's quite messy. And if the main BOINC developer (David Anderson) says it's very hard to handle time moving strange, I doubt you and me can make much with it.

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?

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.)

Hold on, before you run away with the wrong terms.

An Account Manager is a 3rd party website through which you can attach to multiple projects at the same time and manage them.

BOINC Manager is only a graphical interface through which you can easily tell the BOINC program what to do.

BOINC, the program (the daemon), is what is actually doing all this writing to disk, recalculating short term debt, long term debt, the to completion time of your results etcetera.

Short term debt is used to see which project is next in line to be crunched.
Long term debt is used to see which project is next in line to download work.

BOINC recalculates STD and LTD multiple times a second and writes these results to the client_state.xml file every second. 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. If you at that moment reset your debts, you corrupt your client_state.xml file and lose everything else in it.

So the only reasonable way around this is to quit BOINC. And then either edit the file by hand, or use a 3rd part add-on such as BoincDV.

On average you don't need to know all this information. But if you want to go reprogram things, it's useful to know how the program works in the first place and to check what each part is doing.

---

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.