It appears that Guido (at the above thread) also fixed his problem by simply refreshing/updating his disk prefs from the web-site (and, he also did the same thing to fix another project as - Rosetta I think). Looks like the "corrupted prefs hypothesis" is becoming more of a possibility. If that's the case, what info should we asking for to help isolate the cause? A copy of the global_prefs.xml file before refreshing? Anything else?
Quote:
Gary and Ageless,
Although this was an interesting discussion, I think it missed the point. If I read paulcet correctly, his problem (possibly) was that his disk preferences in BOINC Manager were somehow corrupted. That is, he simply went to the Einstein web page, reviewed his settings, made no changes, but did an "Update" and that fixed things. I think it would be interesting to know if Janet and flthompson report similar success after updating. And we should be alert to the possibility that there may be a BOINC Manager problem relating to preferences. EDIT: It appears that all three were successfully processing and returning work before the disk space issue cropped up.
It appears that Guido (at the above thread) also fixed his problem by simply refreshing/updating his disk prefs from the web-site (and, he also did the same thing to fix another project - Rosetta I think). Looks like the "corrupted prefs hypothesis" is becoming more of a possibility. If that's the case, what info should we asking for to help isolate the cause? A copy of the global_prefs.xml file before refreshing? Anything else?
I am just now beginning to realize how much I don't understand about BOINC.
Why does each project have "general preferences"? Are these separate project prefs somehow coordinated among the projects or is it possible to have different prefs stored on different project web-sites?
I just looked at my global_prefs.xml file (just so I would know what it looked like). And, I found out that mine was loaded from my Seti prefs. Then I glanced through my messages and found that my prefs file was loaded on start-up from Seti but apparently never changed when BOINC switched from Seti to Einstein and back again. It just so happens that my Einstein and Seti prefs are the same (or maybe that happens by design) so there is no need to switch anyway. But, again this raises the question: Why does each project have general prefs? Furthermore, how does BOINC determine which project's prefs to load?
I have just been trying to figure out how this new "disc space" problem could be happening and why refreshing prefs seems to fix it. And, instead of figuring anything out, I just came up with some more questions. It seems to me that if each project really can have unique prefs, then a project with bad settings could screw things up for all the others. Am I on to anything here (other than a wild goose chase)?
I do have direct experience with this problem and I believe I do know what is going on. I'm going to compose a detailed response which hopefully will explain it all. The ultimate answer will, of course, need to come from someone who is directly familiar with the code. However I will relate my experience with this and explain what I think is going on. I've been busy - just give me a bit of time to compose a response.
... how does BOINC determine which project's prefs to load?
HI, old buddy :-)
I think that it uses global preferences, so that whichever is most recently updated/altered is the new global, i.e., for all projects.
(aside) - I, too, am disappointed that our debate re: 0.18 went for naught, didn't stir up some response from devs. Perhaps we could schedule another go-around in a few days, keep tickling the subject and maybe someone will come along and scratch.
Michael
microcraft
"The arc of history is long, but it bends toward justice" - MLK
(aside) - I, too, am disappointed that our debate re: 0.18 went for naught, didn't stir up some response from devs. Perhaps we could schedule another go-around in a few days, keep tickling the subject and maybe someone will come along and scratch.
Michael
I'm game if you are. Maybe we can even shame Gary into joining in. (He won't be able to claim ignorance since he promised he will be posting here again shortly.)
With regard to the issue here, I am anxious to read what Gary has to say (as I am sure it will be thorough and definitive).
Thanks, Stick. I also found it curious.... First, that I had an issue at all after successfully running several WU. Second, that others had the same problem at about the same time. I certainly can't say that the .xml file wasn't corrupted. I do run antivirus scans daily.
Paul,
Have you had any other indications of corrupted files on your computer? Especially, any non-BOINC files?
No, no other indications.
Quote:
If so, that would tend to confirm Ageless's theory of local disk issues. On the other hand, have you made any other BOINC related changes recently - like attaching additional projects or adjusting resource shares?
Again, No. Only running E@H, and didn't see any reason to change the prefs.
Quote:
As you have probably guessed, I am just brainstorming as to possible events that might have corrupted your prefs file.
Stick
EDIT: I am also trying to get the original problem back up to the top of the thread. :-)
If it happens again, I will try to check out the .xml file before resetting anything. Can't wait to see what Gary has to say!
Thanks, Stick. I also found it curious.... First, that I had an issue at all after successfully running several WU. Second, that others had the same problem at about the same time. I certainly can't say that the .xml file wasn't corrupted. I do run antivirus scans daily.
Paul,
Have you had any other indications of corrupted files on your computer? Especially, any non-BOINC files?
No, no other indications.
Quote:
If so, that would tend to confirm Ageless's theory of local disk issues. On the other hand, have you made any other BOINC related changes recently - like attaching additional projects or adjusting resource shares?
Again, No. Only running E@H, and didn't see any reason to change the prefs.
Quote:
As you have probably guessed, I am just brainstorming as to possible events that might have corrupted your prefs file.
Stick
EDIT: I am also trying to get the original problem back up to the top of the thread. :-)
If it happens again, I will try to check out the .xml file before resetting anything. Can't wait to see what Gary has to say!
Thanks for all the help!
Paul,
Since Gary hasn't posted yet and since I have done a little more thinking about the subject in the meantime, I am going to speculate a little further. My guess is, if it happens again, you would find that the global prefs file is OK. That is, I think it is likely that something in BOINC Manager is internally corrupting the disc pref values that are loaded from the global pref file after the load has been made. If I am right, your fix worked because it forced BOINC to read the file again and not because the file itself was ever corrupted. But, again, we should wait for Gary and see what he has to say.
That is, I think it is likely that something in BOINC Manager is internally corrupting the disc pref values that are loaded from the global pref file after the load has been made. If I am right, your fix worked because it forced BOINC to read the file again and not because the file itself was ever corrupted.
When you update the preferences on the website (save the changes there), they are only updated there. Nothing on your harddrive is updated, until you update through Boinc Manager. BM reads the preferences from the project's preferences website and writes them to the harddrive for later use (or restarts of Boinc, by which they are used as General Prefs.).
Now here comes the clue: Boinc Manager does nothing with the preferences file. Boinc Manager does nothing whatsoever, but for look pretty and have clickable buttons... Boinc Manager is the GUI. The graphical user interface. It interacts with Boinc.exe, the actual daemon which does all the actual managing, up-/downloading/reporting of work, keeping an eye on the cache etc.
Boinc.exe is the continuous running program that decides which science applications to run, according to the needs of the scheduler and per your settings of the general preferences and your resource share. It is the program that calculates all the abbreviations: LTD, STD, DCF, ACE, EDF etc. and writes most of them to disk.
This long way around is to show which program does what.
Now, of course, we're all waiting for Gary's explanation, so you don't need to listen to a loon like me. ;)
Another similar report just
)
Another similar report just came in here: Message boards : Getting Started : No work sent - Not Enough Disk Space???.
RE: Another similar report
)
It appears that Guido (at the above thread) also fixed his problem by simply refreshing/updating his disk prefs from the web-site (and, he also did the same thing to fix another project as - Rosetta I think). Looks like the "corrupted prefs hypothesis" is becoming more of a possibility. If that's the case, what info should we asking for to help isolate the cause? A copy of the global_prefs.xml file before refreshing? Anything else?
RE: It appears that Guido
)
I am just now beginning to realize how much I don't understand about BOINC.
Why does each project have "general preferences"? Are these separate project prefs somehow coordinated among the projects or is it possible to have different prefs stored on different project web-sites?
I just looked at my global_prefs.xml file (just so I would know what it looked like). And, I found out that mine was loaded from my Seti prefs. Then I glanced through my messages and found that my prefs file was loaded on start-up from Seti but apparently never changed when BOINC switched from Seti to Einstein and back again. It just so happens that my Einstein and Seti prefs are the same (or maybe that happens by design) so there is no need to switch anyway. But, again this raises the question: Why does each project have general prefs? Furthermore, how does BOINC determine which project's prefs to load?
I have just been trying to figure out how this new "disc space" problem could be happening and why refreshing prefs seems to fix it. And, instead of figuring anything out, I just came up with some more questions. It seems to me that if each project really can have unique prefs, then a project with bad settings could screw things up for all the others. Am I on to anything here (other than a wild goose chase)?
To everybody posting in this
)
To everybody posting in this thread:
I do have direct experience with this problem and I believe I do know what is going on. I'm going to compose a detailed response which hopefully will explain it all. The ultimate answer will, of course, need to come from someone who is directly familiar with the code. However I will relate my experience with this and explain what I think is going on. I've been busy - just give me a bit of time to compose a response.
Shortly!! :).
Cheers,
Gary.
RE: ... how does BOINC
)
HI, old buddy :-)
I think that it uses global preferences, so that whichever is most recently updated/altered is the new global, i.e., for all projects.
(aside) - I, too, am disappointed that our debate re: 0.18 went for naught, didn't stir up some response from devs. Perhaps we could schedule another go-around in a few days, keep tickling the subject and maybe someone will come along and scratch.
Michael
microcraft
"The arc of history is long, but it bends toward justice" - MLK
RE: (aside) - I, too, am
)
I'm game if you are. Maybe we can even shame Gary into joining in. (He won't be able to claim ignorance since he promised he will be posting here again shortly.)
With regard to the issue here, I am anxious to read what Gary has to say (as I am sure it will be thorough and definitive).
RE: RE: Thanks, Stick.
)
No, no other indications.
Again, No. Only running E@H, and didn't see any reason to change the prefs.
If it happens again, I will try to check out the .xml file before resetting anything. Can't wait to see what Gary has to say!
Thanks for all the help!
RE: RE: RE: Thanks,
)
Paul,
Since Gary hasn't posted yet and since I have done a little more thinking about the subject in the meantime, I am going to speculate a little further. My guess is, if it happens again, you would find that the global prefs file is OK. That is, I think it is likely that something in BOINC Manager is internally corrupting the disc pref values that are loaded from the global pref file after the load has been made. If I am right, your fix worked because it forced BOINC to read the file again and not because the file itself was ever corrupted. But, again, we should wait for Gary and see what he has to say.
Stick
RE: That is, I think it is
)
When you update the preferences on the website (save the changes there), they are only updated there. Nothing on your harddrive is updated, until you update through Boinc Manager. BM reads the preferences from the project's preferences website and writes them to the harddrive for later use (or restarts of Boinc, by which they are used as General Prefs.).
Now here comes the clue: Boinc Manager does nothing with the preferences file. Boinc Manager does nothing whatsoever, but for look pretty and have clickable buttons... Boinc Manager is the GUI. The graphical user interface. It interacts with Boinc.exe, the actual daemon which does all the actual managing, up-/downloading/reporting of work, keeping an eye on the cache etc.
Boinc.exe is the continuous running program that decides which science applications to run, according to the needs of the scheduler and per your settings of the general preferences and your resource share. It is the program that calculates all the abbreviations: LTD, STD, DCF, ACE, EDF etc. and writes most of them to disk.
This long way around is to show which program does what.
Now, of course, we're all waiting for Gary's explanation, so you don't need to listen to a loon like me. ;)
RE: Now, of course, we're
)
Thanks Ageless (again). I said this earlier:
I would now like to amend that to read: I am amazed at how much I don't understand about BOINC.
I was also considering making a comment about being a loon, too. But that would be presumptuous of me. I do not belong in the same category as you.!
BTW: I hope Gary realizes the pressure he has put on himself. I mean, after all this waiting, his explanation better be good. ;-)