I deleted the whole BOINC folder within the data-folder (BOINC/Data) so all BOINC stuff is in one folder, so I can easily copy the whole folder and stop network-activity so I can try an app_info.xml or something that I'm not sure will work properly for the first time so I have a backup.
About hiberantion mode: I went to hibernate almost everytime for some years now and didn't notice such behaviour in previous BOINC versions. The estimated time was almost right. It went wrong just with the installation of 6.4.5
Before 6.4.5 I had 6.5.0 installed because of SETI CUDA and because 6.5.0 seemed to have problems with CUDA I installed the 6.4.5 which was recommended.
Due to the fact, that I shortened my cache to 0.1 days when I had the 6.5.0 installed I can't say, if it was a problem in that version.
About the uninstallation: When I go back to BOINC 5.10.45 does it also work with just uninstall the 6.6.3 and install the 5.10.45 even with tasks in progress? I think the data-structure is different (There is no specific data-folder? Am I right?).
My belief is that there is a serious DCF problem in v6.4.5 ....
Richard,
Thanks very much for taking the time to post all the detail about this.
I rarely visit the Seti boards and I have machines that are close to 'totally on-board graphics' so I'm virtually 100% unaware of the state of play regarding CUDA. I have long held the view that as long as the BOINC version doesn't start with less than a 5, you should pick a version that has a proven track record and stay with it until something that is equally stable comes along. Since BOINC does no crunching, it's pointless (from a performance point of view) to keep updating to the latest grief generator unless your aim is to be noble and assist with the debugging efforts.
Could it be that he deleted the main Boinc-folder and kept the Data-folder. Remember that version 6 splits to 2 folders. All .xml-files and project-files are stored in the data-folder and that usually resides in a hidden folder.
I guess it must be something like that. Out of 150+ machines, I have upgraded two to 6.2.19 some time ago but because everything was in the one place with 5.10.45, these two machines have retained that structure. I don't have any experience with exactly what goes where with the separation of data and programs but it would be logical for all .xml files to be with the data.
When the OP mentioned that he deleted "the whole BOINC folder" I assumed he meant everything rather than just the 'programs' folder.
So if he didn't delete client_state.xml that would explain the host ID but it doesn't explain why he got totally new data at the time he switched version. Up to Jan 28 he had been getting 510.xxHz tasks. There were no further tasks until Jan 30 so that 2 day gap would have been when he was running down the cache. From Jan 30 onwards he has been getting 262.xxHz tasks and that is why I thought he must have deleted his state file. With the state file already containing blocks for all the 510.xxHz data files, you would expect that the scheduler would continue to use that data rather than change everything over to an entirely new frequency.
1) Uninstalling any variety of BOINC v6 is supposed to migrate the data back into a single monolithic folder. So if Bluesilvergreen deleted the folder, he will indeed have deleted everything (unless the uninstaller is broken....)
2) That means that the data remaining after an uninstall is (or should be) in a proper state for BOINC v5.10.45 to install correctly and pick up crunching where the previous version left off - yes, including tasks in progress.
3) I believe (but I'm less certain about this) that recent BOINC servers are intelligent enough to re-cycle abandoned host IDs. So, even if the client_state containing the ID information is lost, when you re-attach using the same user account, the same IP address, and the same hardware description, the server will try to match you up with a likely-looking host ID if there's one available. A bit like the 'resend lost results' feature.
4) @ Gary,
Since you liked the last one, here's another addition to your library: BOINC dev message 22789. Might be worth struggling through (it's a long one), because there's an Einstein-specific example of BOINC v6.4.5 CUDA problems in there.
I deleted the whole BOINC folder within the data-folder (BOINC/Data) so all BOINC stuff is in one folder, so I can easily copy the whole folder and stop network-activity so I can try an app_info.xml or something that I'm not sure will work properly for the first time so I have a backup.
OK, if I understand you correctly, you now have all programs and data in the one place - your previous programs folder? I thought I'd read somewhere that the Windows installer didn't allow that? I don't have any knowledge of the true state of affairs as the only BOINC 6.x.x I've installed has been on Linux where there is no problem doing whatever you want. I tend to like the single tree myself for much the same reason you suggest - easier to manipulate one tree rather than two.
Quote:
About hiberantion mode: I went to hibernate almost everytime for some years now and didn't notice such behaviour in previous BOINC versions.
Yes, it may well be that the problem started at some particular 6.x.x version and wasn't there in earlier versions. It might be worthwhile trying 6.2.19 if you are reluctant to go back all the way to 5.10.45.
Quote:
About the uninstallation: When I go back to BOINC 5.10.45 does it also work with just uninstall the 6.6.3 and install the 5.10.45 even with tasks in progress?
Yes. If you look closely at this FAQ, you should find this particular statement:-
Quote:
If you install BOINC 6 and then uninstall it through Add/Remove Programs, the Data directory is migrated back into the BOINC directory. This is done so you can always return to BOINC 5.10 without needing to move a lot of files by hand.
There is a lot of other useful things to read as well.
Quote:
(There is no specific data-folder? Am I right?).
Yes, in BOINC 5.x.x everything is in the one tree if that's what you mean.
It took me a while to finally post my previous message because I got lured away to watch Nadal outlast Federer in the Australian Open. The match has just finished and then I quickly sent off my reply that had already been largely composed (and sitting around for a while) without noticing your most recent comments.
Quote:
1) Uninstalling any variety of BOINC v6 is supposed to migrate the data back into a single monolithic folder ...
Yep - I found it in one of Jord's FAQs.
Quote:
2) That means that the data remaining after an uninstall is (or should be) in a proper state for BOINC v5.10.45 to install correctly and pick up crunching where the previous version left off - yes, including tasks in progress.
Yep.
Quote:
3) I believe (but I'm less certain about this) that recent BOINC servers are intelligent enough to re-cycle abandoned host IDs ....
Ok, I haven't heard that before but it was something that crossed my mind when I was trying to work out why the original ID wasn't lost. There were a couple of things that caused me to think this wouldn't apply in this case. For example
* The BOINC server wouldn't know the ID was abandoned, since it was a manual deleting of the state file.
* If there were identical hosts on a LAN and one that had been attached to a project was given a rest and then a second which had not been attached was fired up, it would be quite inappropriate for the server to reuse the hostid. What happens then if the first host woke up and wanted to start crunching again?
Quote:
4) @ Gary,
Since you liked the last one, here's another ....
Thanks. It's late here so I'll take a good look at it tomorrow.
it never changed the directory structure? interesting, because ive been running boinc on this same computer for years. and when i went to 6.X it changed the directory structure. so i now have
C:\Program Files\BOINC
which has the boinc program files
and
C:\Documents and Settings\All Users\Application Data\BOINC
which has all the project files
seeing without seeing is something the blind learn to do, and seeing beyond vision can be a gift.
it never changed the directory structure? interesting, because ive been running boinc on this same computer for years. and when i went to 6.X it changed the directory structure. so i now have
C:\Program Files\BOINC
which has the boinc program files
and
C:\Documents and Settings\All Users\Application Data\BOINC
which has all the project files
Installing any BOINC from the v6 range makes exactly that change.
Uninstalling it again reverses the change, so everything goes back into one directory.
Very often, the new v6 Data directory is created as a hidden directory, so users aren't aware it exists - they just see the program directory as before, and don't notice that all the data has moved out of it.
After a few days of trying I can say, that v6.2.19 is the latest version where hiberantion isn't an issue. So the DCF hovers steadily at 1.34 on my E4300 and on my Q6600 it decreases constantly even with hibernation breaks in between.
After a few days of trying I can say, that v6.2.19 is the latest version where hiberantion isn't an issue. So the DCF hovers steadily at 1.34 on my E4300 and on my Q6600 it decreases constantly even with hibernation breaks in between.
So it is really a "bug" in 6.4.5 and higher.
Can you gather some data to demonstrate the point?
How about a simple explanation of the problem and how you discovered the solution?
Does not do us any good if we cannot make a solid bug report that maybe can get fixed...
I deleted the whole BOINC
)
I deleted the whole BOINC folder within the data-folder (BOINC/Data) so all BOINC stuff is in one folder, so I can easily copy the whole folder and stop network-activity so I can try an app_info.xml or something that I'm not sure will work properly for the first time so I have a backup.
About hiberantion mode: I went to hibernate almost everytime for some years now and didn't notice such behaviour in previous BOINC versions. The estimated time was almost right. It went wrong just with the installation of 6.4.5
Before 6.4.5 I had 6.5.0 installed because of SETI CUDA and because 6.5.0 seemed to have problems with CUDA I installed the 6.4.5 which was recommended.
Due to the fact, that I shortened my cache to 0.1 days when I had the 6.5.0 installed I can't say, if it was a problem in that version.
About the uninstallation: When I go back to BOINC 5.10.45 does it also work with just uninstall the 6.6.3 and install the 5.10.45 even with tasks in progress? I think the data-structure is different (There is no specific data-folder? Am I right?).
RE: My belief is that there
)
Richard,
Thanks very much for taking the time to post all the detail about this.
I rarely visit the Seti boards and I have machines that are close to 'totally on-board graphics' so I'm virtually 100% unaware of the state of play regarding CUDA. I have long held the view that as long as the BOINC version doesn't start with less than a 5, you should pick a version that has a proven track record and stay with it until something that is equally stable comes along. Since BOINC does no crunching, it's pointless (from a performance point of view) to keep updating to the latest grief generator unless your aim is to be noble and assist with the debugging efforts.
Cheers,
Gary.
RE: Could it be that he
)
I guess it must be something like that. Out of 150+ machines, I have upgraded two to 6.2.19 some time ago but because everything was in the one place with 5.10.45, these two machines have retained that structure. I don't have any experience with exactly what goes where with the separation of data and programs but it would be logical for all .xml files to be with the data.
When the OP mentioned that he deleted "the whole BOINC folder" I assumed he meant everything rather than just the 'programs' folder.
So if he didn't delete client_state.xml that would explain the host ID but it doesn't explain why he got totally new data at the time he switched version. Up to Jan 28 he had been getting 510.xxHz tasks. There were no further tasks until Jan 30 so that 2 day gap would have been when he was running down the cache. From Jan 30 onwards he has been getting 262.xxHz tasks and that is why I thought he must have deleted his state file. With the state file already containing blocks for all the 510.xxHz data files, you would expect that the scheduler would continue to use that data rather than change everything over to an entirely new frequency.
Must have been just a coincidence.
Cheers,
Gary.
1) Uninstalling any variety
)
1) Uninstalling any variety of BOINC v6 is supposed to migrate the data back into a single monolithic folder. So if Bluesilvergreen deleted the folder, he will indeed have deleted everything (unless the uninstaller is broken....)
2) That means that the data remaining after an uninstall is (or should be) in a proper state for BOINC v5.10.45 to install correctly and pick up crunching where the previous version left off - yes, including tasks in progress.
3) I believe (but I'm less certain about this) that recent BOINC servers are intelligent enough to re-cycle abandoned host IDs. So, even if the client_state containing the ID information is lost, when you re-attach using the same user account, the same IP address, and the same hardware description, the server will try to match you up with a likely-looking host ID if there's one available. A bit like the 'resend lost results' feature.
4) @ Gary,
Since you liked the last one, here's another addition to your library: BOINC dev message 22789. Might be worth struggling through (it's a long one), because there's an Einstein-specific example of BOINC v6.4.5 CUDA problems in there.
RE: I deleted the whole
)
OK, if I understand you correctly, you now have all programs and data in the one place - your previous programs folder? I thought I'd read somewhere that the Windows installer didn't allow that? I don't have any knowledge of the true state of affairs as the only BOINC 6.x.x I've installed has been on Linux where there is no problem doing whatever you want. I tend to like the single tree myself for much the same reason you suggest - easier to manipulate one tree rather than two.
Yes, it may well be that the problem started at some particular 6.x.x version and wasn't there in earlier versions. It might be worthwhile trying 6.2.19 if you are reluctant to go back all the way to 5.10.45.
Yes. If you look closely at this FAQ, you should find this particular statement:-
There is a lot of other useful things to read as well.
Yes, in BOINC 5.x.x everything is in the one tree if that's what you mean.
Cheers,
Gary.
Hi Richard, It took me a
)
Hi Richard,
It took me a while to finally post my previous message because I got lured away to watch Nadal outlast Federer in the Australian Open. The match has just finished and then I quickly sent off my reply that had already been largely composed (and sitting around for a while) without noticing your most recent comments.
Yep - I found it in one of Jord's FAQs.
Yep.
Ok, I haven't heard that before but it was something that crossed my mind when I was trying to work out why the original ID wasn't lost. There were a couple of things that caused me to think this wouldn't apply in this case. For example
* If there were identical hosts on a LAN and one that had been attached to a project was given a rest and then a second which had not been attached was fired up, it would be quite inappropriate for the server to reuse the hostid. What happens then if the first host woke up and wanted to start crunching again?
Thanks. It's late here so I'll take a good look at it tomorrow.
Cheers,
Gary.
it never changed the
)
it never changed the directory structure? interesting, because ive been running boinc on this same computer for years. and when i went to 6.X it changed the directory structure. so i now have
C:\Program Files\BOINC
which has the boinc program files
and
C:\Documents and Settings\All Users\Application Data\BOINC
which has all the project files
seeing without seeing is something the blind learn to do, and seeing beyond vision can be a gift.
RE: it never changed the
)
Installing any BOINC from the v6 range makes exactly that change.
Uninstalling it again reverses the change, so everything goes back into one directory.
Very often, the new v6 Data directory is created as a hidden directory, so users aren't aware it exists - they just see the program directory as before, and don't notice that all the data has moved out of it.
After a few days of trying I
)
After a few days of trying I can say, that v6.2.19 is the latest version where hiberantion isn't an issue. So the DCF hovers steadily at 1.34 on my E4300 and on my Q6600 it decreases constantly even with hibernation breaks in between.
So it is really a "bug" in 6.4.5 and higher.
RE: After a few days of
)
Can you gather some data to demonstrate the point?
How about a simple explanation of the problem and how you discovered the solution?
Does not do us any good if we cannot make a solid bug report that maybe can get fixed...