The entries might also have file signatures included (the above examples don't).
If the two files were 'official', the entries should have URLs included for where BOINC can get them if it needs to. Under the AP (anonymous platform - using app_info.xml) mechanism, file signatures are not needed because you, not BOINC, are responsible for the executables and BOINC is not supposed to download them.
Quote:
19/01/2009 16:59:01||[error] No URL for file transfer of einstein_S5R4_6.05_windows_intelx86.exe
19/01/2009 16:59:01|Einstein@Home|[error] Can't initialize file transfer for einstein_S5R4_6.05_windows_intelx86.exe
19/01/2009 16:59:01||[error] No URL for file transfer of einstein_S5R4_6.05_graphics_windows_intelx86.exe
19/01/2009 16:59:01|Einstein@Home|[error] Can't initialize file transfer for einstein_S5R4_6.05_graphics_windows_intelx86.exe
If you read the error messages closely, you will see that the complaint is about missing URLs - the very URLs I mentioned above. Something must have gone wrong at or before the time you deleted the app_info.xml file and your state file is now in an inconsistent state. The complaints about missing URLs will continue to haunt you until you stop BOINC and edit your state file to remove the two blocks similar to the ones I showed you in the examples above.
Quote:
Why can't I download them? When I replace the original files, I get the message the they don't have the proper signature.
You are not supposed to. They are not currently 'official' apps (version 6.10 is for S5R4) and there will be no future need for them. You need to clean them out of your state file.
That shouldn't be to difficult. BUT, I can't seem to find any client_state.xml file. Nowhere on my computer.
But I see a lot of S5R4 work in the status page that have to be done.
The status page currently says that there are ~600K R4 results and ~1.2M (I assume R4+R5) total results in the database. It doesn't list the 'ready to send' for R4 but it gives a figure of ~70K 'unsent' which once again I assume refers to (R4+R5). Please be aware (as always) that probably most of the results in the database are ones 'out in the wild' or 'returned and awaiting deletion', and not new work ready to send.
I would suspect that there are actually very few R4 results that are immediately ready to send.
Undoubtedly, some more will become available as resends when hosts fail to return them or they error out. As always this will continue for a while. Shortly you will probably find it difficult to get a regular supply.
Quote:
But why should I move on to new version if I see that server side has a job for me.
You can quite easily allow your hosts to receive either R4 or R5 work. You don't have to 'move on' at all. I've just finished converting ~150 machines which were running R4 beta test apps under AP to now be running the final official R4 app or the new R5 app at the discretion of the scheduler. The bulk of these machines are still getting and running R4 but virtually 100% of them also have at least one (or more) R5 tasks on board. The bulk of the R4 work still being received is resend work (_2 or higher).
Quote:
What makes me impossible to download new data files for old analysis?
I'm not really sure what you mean by this?? The large data files are the same irrespective of whether the scheduler sends you an R4 or an R5 task. If you are really asking what makes it impossible to download new R4 tasks then the answer is that new R4 tasks are becoming rather scarce. They turned off the R4 WU generator some days ago.
Quote:
P.S. I'm using S5R4 v6.07 and my cache is not empty yet :)
If I were you, I would upgrade 6.07 to the 6.10 beta test app - still running under AP. Once 6.10 is running, (even though your cached tasks are listed as 6.07) you can back out of the AP mechanism (deleting app_info.xml) and the tasks will not be lost as long as you add the file signatures for the 6.10 apps to the blocks for those apps in your state file.
I have done this on 150 machines and I haven't lost a single cache of work.
The edit is quite trivial once you understand exactly what to do. Please ask if you want me to spell it out. I can even provide you with the exact code to insert in your state file.
EDIT: I've now written the detailed instructions here.
That shouldn't be to difficult. BUT, I can't seem to find any client_state.xml file. Nowhere on my computer.
The state file used to be in your main BOINC folder. With the split between data and program folders in newer versions, check both places. I'm still living in the days of the single BOINC folder so I don't know for the new regime :-).
That shouldn't be to difficult. BUT, I can't seem to find any client_state.xml file. Nowhere on my computer.
If you restart Boinc and look under the message-tab the data directory is listed at the beginning.
Example:
17/01/2009 10:46:04||Starting BOINC client version 6.6.0 for windows_x86_64
17/01/2009 10:46:04||This a development version of BOINC and may not function properly
17/01/2009 10:46:04||Libraries: libcurl/7.19.2 OpenSSL/0.9.8i zlib/1.2.3
17/01/2009 10:46:04||Data directory: C:\ProgramData\BOINC
That shouldn't be to difficult. BUT, I can't seem to find any client_state.xml file. Nowhere on my computer.
The state file used to be in your main BOINC folder. With the split between data and program folders in newer versions, check both places. I'm still living in the days of the single BOINC folder so I don't know for the new regime :-).
Ok, I found it. In this file, I found two more references of the two exe's. I assume I can delete this part as well?
Ok, I found it. In this file, I found two more references of the two exe's. I assume I can delete this part as well?
After you deleted the app_info.xml file, then restarted BOINC, just reset the project. That will clear all straggling remains about the power app that you used from the Einstein directory as well as all the files it is mentioned in.
Thank you, Gary. I did what you'd suggested. It works but... no new work for S5R4 yet. Same as it was for S5R3 transition - once it just stops sending new work for old search and nothing help even though my machine is showing that it's capable to do remains of old search. May be I don't have needed data files for the rest of work.
Ok, I found it. In this file, I found two more references of the two exe's. I assume I can delete this part as well?
After you deleted the app_info.xml file, then restarted BOINC, just reset the project. That will clear all straggling remains about the power app that you used from the Einstein directory as well as all the files it is mentioned in.
Ah yes, that did it. The log looks good now and no more everlasting pending downloads. Even the lost work was sent back to my computer. Thanks!
... May be I don't have needed data files for the rest of work.
Yes, that is a very important component in the scheduler's decision making. If the scheduler has R4 work and if that work is not 'too old' then the scheduler will wait for a host that already has the correct data files. If such tasks are not being picked up by a host with data, the scheduler will eventually get more desperate and send the work to the first available host.
All of my 150+ hosts now have R5 work and most of them have the odd R4 task or three still to complete. About 10% of them are regularly getting R4 resends when requesting new work. I have seen quite a number of hosts, that were working on frequencies above 1000Hz, suddenly get a complete new set of data and an R4 task around the 660Hz range when the last 1000Hz+ task was acquired. This is because the new R5 tasks are not going above 1000HZ so the scheduler knows it has to switch data files for such hosts.
As suggested by a server
)
As suggested by a server message I have stopped BOINC, canceled the app_info.xml file, restarted BOINC and got new work,
Tullio
RE: RE: I'm afraid BOINC
)
That shouldn't be to difficult. BUT, I can't seem to find any client_state.xml file. Nowhere on my computer.
RE: But I see a lot of S5R4
)
The status page currently says that there are ~600K R4 results and ~1.2M (I assume R4+R5) total results in the database. It doesn't list the 'ready to send' for R4 but it gives a figure of ~70K 'unsent' which once again I assume refers to (R4+R5). Please be aware (as always) that probably most of the results in the database are ones 'out in the wild' or 'returned and awaiting deletion', and not new work ready to send.
I would suspect that there are actually very few R4 results that are immediately ready to send.
Undoubtedly, some more will become available as resends when hosts fail to return them or they error out. As always this will continue for a while. Shortly you will probably find it difficult to get a regular supply.
You can quite easily allow your hosts to receive either R4 or R5 work. You don't have to 'move on' at all. I've just finished converting ~150 machines which were running R4 beta test apps under AP to now be running the final official R4 app or the new R5 app at the discretion of the scheduler. The bulk of these machines are still getting and running R4 but virtually 100% of them also have at least one (or more) R5 tasks on board. The bulk of the R4 work still being received is resend work (_2 or higher).
I'm not really sure what you mean by this?? The large data files are the same irrespective of whether the scheduler sends you an R4 or an R5 task. If you are really asking what makes it impossible to download new R4 tasks then the answer is that new R4 tasks are becoming rather scarce. They turned off the R4 WU generator some days ago.
If I were you, I would upgrade 6.07 to the 6.10 beta test app - still running under AP. Once 6.10 is running, (even though your cached tasks are listed as 6.07) you can back out of the AP mechanism (deleting app_info.xml) and the tasks will not be lost as long as you add the file signatures for the 6.10 apps to the blocks for those apps in your state file.
I have done this on 150 machines and I haven't lost a single cache of work.
The edit is quite trivial once you understand exactly what to do. Please ask if you want me to spell it out. I can even provide you with the exact code to insert in your state file.
EDIT: I've now written the detailed instructions here.
Cheers,
Gary.
RE: That shouldn't be to
)
The state file used to be in your main BOINC folder. With the split between data and program folders in newer versions, check both places. I'm still living in the days of the single BOINC folder so I don't know for the new regime :-).
Cheers,
Gary.
RE: That shouldn't be to
)
If you restart Boinc and look under the message-tab the data directory is listed at the beginning.
Example:
The data directory might be in a hidden folder...
/Holmis
RE: RE: That shouldn't be
)
Ok, I found it. In this file, I found two more references of the two exe's. I assume I can delete this part as well?
einstein_S5R4
605
windows_intelx86
1.000000
1.000000
3152999967.790893
6.3.0
einstein_S5R4_6.05_windows_intelx86.exe
einstein_S5R4_6.05_graphics_windows_intelx86.exe
graphics_app
RE: Ok, I found it. In this
)
After you deleted the app_info.xml file, then restarted BOINC, just reset the project. That will clear all straggling remains about the power app that you used from the Einstein directory as well as all the files it is mentioned in.
Thank you, Gary. I did what
)
Thank you, Gary. I did what you'd suggested. It works but... no new work for S5R4 yet. Same as it was for S5R3 transition - once it just stops sending new work for old search and nothing help even though my machine is showing that it's capable to do remains of old search. May be I don't have needed data files for the rest of work.
RE: RE: Ok, I found it.
)
Ah yes, that did it. The log looks good now and no more everlasting pending downloads. Even the lost work was sent back to my computer. Thanks!
RE: ... May be I don't have
)
Yes, that is a very important component in the scheduler's decision making. If the scheduler has R4 work and if that work is not 'too old' then the scheduler will wait for a host that already has the correct data files. If such tasks are not being picked up by a host with data, the scheduler will eventually get more desperate and send the work to the first available host.
All of my 150+ hosts now have R5 work and most of them have the odd R4 task or three still to complete. About 10% of them are regularly getting R4 resends when requesting new work. I have seen quite a number of hosts, that were working on frequencies above 1000Hz, suddenly get a complete new set of data and an R4 task around the 660Hz range when the last 1000Hz+ task was acquired. This is because the new R5 tasks are not going above 1000HZ so the scheduler knows it has to switch data files for such hosts.
Cheers,
Gary.