199 | | === Job submission === |
200 | | |
201 | | Given that RBoinc takes care of uploading the files, will it be |
202 | | important to ensure that input files for different WUs have |
203 | | different names, so they don't conflict? |
204 | | |
205 | | The scientist can and reuse whatever names and contents he |
206 | | likes. The only thing that matters is the file content at the |
207 | | moment of submission. The RBoinc server will generate internal |
208 | | unique names (which are hidden from the user). |
209 | | |
210 | | |
211 | | Will files with identical names conflict |
212 | | when they end up in the ''download'' directory? |
213 | | |
214 | | No, it will be handled correctly: file names are made |
215 | | unique (in fact, equal to the file's MD5), even though the |
216 | | submitter used the same name for different contents. (It's fairly |
217 | | common e.g. for 1000 WUs to have in common at least one of the |
218 | | inputs). |
219 | | |
220 | | |
221 | | Will there be a problem if a user send simultaneously 1000 jobs by a |
222 | | script? |
223 | | |
224 | | It's perfectly fine (common indeed). |
225 | | |
226 | | === Retrieve === |
227 | | |
228 | | How does the manual retrieve operation affect workunits once a job has |
229 | | been performed? |
230 | | |
231 | | Retrieve will free up space taken on the server by the results of |
232 | | the completed WUs. Currently running, scheduled, and future WUs |
233 | | will be otherwise unaffected (e.g., ''step1'' may depend on ''step0'' |
234 | | through the chaining mechanism). |
235 | | |
236 | | Note, however, that a {{{boinc_retrieve -stop ...}}} command will |
237 | | stop the chaining machinery, ie. the generation of new WUs. This is |
238 | | a ''stop'' operation, which should not be confused with a ''retrieve''. |
239 | | |
240 | | |
241 | | And what about the results if you don't perform a "retrieve"? |
242 | | |
243 | | The results are kept on the server until the issuing scientist |
244 | | retrieves them. (In fact, they may fill up the server if |
245 | | forgotten.) |
246 | | |
| 199 | === Portability and server coexistence === |
| 200 | |
| 201 | Is your application directly compatible with |
| 202 | Windows? |
| 203 | |
| 204 | The '''client''' scripts are likely portable with minor changes |
| 205 | (just install a good Perl interpreter and the required modules). |
| 206 | |
| 207 | |
| 208 | Is it possible to use your commands with different BOINC projects? |
| 209 | |
| 210 | Normally a ''RBoinc server'' is tied to the corresponding |
| 211 | ''Boinc server'' (but it can talk to any of its applications). The |
| 212 | ''RBoinc clients'' can talk to multiple servers using different URLs |
| 213 | ('''-url''' option). |
| 214 | |
| 215 | |
| 216 | I was thinking of having several Boinc projects to assign easily each |
| 217 | of them to a specific group of users. Should I be installing multiple |
| 218 | servers with their own URLs? |
| 219 | |
| 220 | Yes - that will be the most flexible solution (e.g. you wil be |
| 221 | able to perform maintenance on each of them separately, make |
| 222 | firewall rules, etc). Alternatively, you can create several |
| 223 | applications on the same server, if you prefer. |
| 224 | |
| 225 | |
| 226 | === Server and installation === |
| 248 | |
| 249 | |
| 250 | What is ''ENCODE_EXECUTABLE'' ? |
| 251 | |
| 252 | It's an optional script to pre-process files before submission, e.g. for a server-side sanity check, or reformatting, etc. |
| 253 | |
| 254 | |
| 255 | What is ETC_DIR => "$cgi/etc" ? Do I have to copy files included in server/etc ? Which ones will be used ? |
| 256 | |
| 257 | Most notably, the files which are supplied as defaults (if any), e.g. those marked as {{{<rboinc immutable="true"/>}}} or {{{<rboinc optional="true"/> }}} in the template. |
| 258 | |
| 259 | |
| 260 | What is "process.sh"? Is it a daemon? What if server is restarted ? |
| 261 | |
| 262 | ''process'' created automatically by the boinc_submit_server in each GROUP directory. (It's at the end of the server submission script.) It's invoked in two cases: |
| 263 | |
| 264 | 1. as the last step of the submission, when everything has been set up. It will create_work and exit. |
| 265 | 1. it will be invoked by the assimilator. if chaining is required, it will create_work for the next "chain step" (depending on the one which just ended successfully) and exit. |
| 266 | |
| 267 | Therefore its execution is short and usually triggered by a daemon; stopping/restarting boinc will not affect it. |
| 268 | |
| 269 | |
| 270 | === Job submission === |
| 271 | |
| 272 | Given that RBoinc takes care of uploading the files, will it be |
| 273 | important to ensure that input files for different WUs have |
| 274 | different names, so they don't conflict? |
| 275 | |
| 276 | The scientist can and reuse whatever names and contents he |
| 277 | likes. The only thing that matters is the file content at the |
| 278 | moment of submission. The RBoinc server will generate internal |
| 279 | unique names (which are hidden from the user). |
| 280 | |
| 281 | |
| 282 | Will files with identical names conflict |
| 283 | when they end up in the ''download'' directory? |
| 284 | |
| 285 | No, it will be handled correctly: file names are made |
| 286 | unique (in fact, equal to the file's MD5), even though the |
| 287 | submitter used the same name for different contents. (It's fairly |
| 288 | common e.g. for 1000 WUs to have in common at least one of the |
| 289 | inputs). |
| 290 | |
| 291 | |
| 292 | Will there be a problem if a user send simultaneously 1000 jobs by a |
| 293 | script? |
| 294 | |
| 295 | It's perfectly fine (common indeed). |
| 296 | |
| 297 | === Retrieve === |
| 298 | |
| 299 | How does the manual retrieve operation affect workunits once a job has |
| 300 | been performed? |
| 301 | |
| 302 | Retrieve will free up space taken on the server by the results of |
| 303 | the completed WUs. Currently running, scheduled, and future WUs |
| 304 | will be otherwise unaffected (e.g., ''step1'' may depend on ''step0'' |
| 305 | through the chaining mechanism). |
| 306 | |
| 307 | Note, however, that a {{{boinc_retrieve -stop ...}}} command will |
| 308 | stop the chaining machinery, ie. the generation of new WUs. This is |
| 309 | a ''stop'' operation, which should not be confused with a ''retrieve''. |
| 310 | |
| 311 | |
| 312 | And what about the results if you don't perform a "retrieve"? |
| 313 | |
| 314 | The results are kept on the server until the issuing scientist |
| 315 | retrieves them. (In fact, they may fill up the server if |
| 316 | forgotten.) |
| 317 | |
| 318 | |
| 319 | |
280 | | === Portability and server coexistence === |
281 | | |
282 | | Is your application directly compatible with |
283 | | Windows? |
284 | | |
285 | | The '''client''' scripts are likely portable with minor changes |
286 | | (just install a good Perl interpreter and the required modules). |
287 | | |
288 | | |
289 | | Is it possible to use your commands with different BOINC projects? |
290 | | |
291 | | Normally a ''RBoinc server'' is tied to the corresponding |
292 | | ''Boinc server'' (but it can talk to any of its applications). The |
293 | | ''RBoinc clients'' can talk to multiple servers using different URLs |
294 | | ('''-url''' option). |
295 | | |
296 | | |
297 | | I was thinking of having several Boinc projects to assign easily each |
298 | | of them to a specific group of users. Should I be installing multiple |
299 | | servers with their own URLs? |
300 | | |
301 | | Yes - that will be the most flexible solution (e.g. you wil be |
302 | | able to perform maintenance on each of them separately, make |
303 | | firewall rules, etc). Alternatively, you can create several |
304 | | applications on the same server, if you prefer. |
305 | | |