On Seti, there have been problems with server overload, and it has been mentiond, frequently, better performance from the server is achieved if a host reports results and requests tasks at the same time and preferably in batches.

Now that Seti has moved to Enhanced I have reset my 'connect to network' option back to the default of 0.1 days. Since my cache of tasks returned to minimum values, it is noticable that tasks are reported some time before a request for a new task.

Wouldn't be preferable if reporting was delayed until the next request for new task(s) rather than after one period of the 'connect to network' setting, unless the report would miss the deadline.

The preferences for low 'connect to network' and join more than one project seem to be odds with each other.

Andy

They are at odds and it is somewhat confusing. It was discovered that with multiple projects it would take some time for work to be reported especially if a host was overloaded. As work sits on a host the chance something will happen and corrupt it increases. As a compromise tasks are reported after they have been ready to report for the connection frequency.

---

BOINC WIKI

BOINCing since 2002/12/8

John, with 5.4.9 we have the check of the client_state.xml file, doesn't that greatly reduce the chance of corruption?

---

Just to add insult to injury, I then get this;

2006-05-19 14:31:53 [SETI@home] Sending scheduler request to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi
2006-05-19 14:31:53 [SETI@home] Reason: To report completed tasks
2006-05-19 14:31:53 [SETI@home] Reporting 1 tasks
2006-05-19 14:32:13 [SETI@home] Scheduler request succeeded
2006-05-19 14:35:24 [SETI@home] Sending scheduler request to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi
2006-05-19 14:35:24 [SETI@home] Reason: To fetch work
2006-05-19 14:35:24 [SETI@home] Requesting 371 seconds of new work
2006-05-19 14:35:27 [SETI@home] Scheduler request to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi succeeded
2006-05-19 14:35:31 [SETI@home] Message from server: Not sending work - last request too recent: 198 sec
2006-05-19 14:35:31 [SETI@home] No work from project
2006-05-19 14:45:40 [SETI@home] Sending scheduler request to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi
2006-05-19 14:45:40 [SETI@home] Reason: To fetch work
2006-05-19 14:45:40 [SETI@home] Requesting 1071 seconds of new work
2006-05-19 14:45:46 [SETI@home] Scheduler request to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi succeeded
2006-05-19 14:45:48 [SETI@home] Started download of 05mr99ab.17601.32800.3394.1.64
2006-05-19 14:45:48 [SETI@home] Finished download of 05mr99ab.17601.32800.3394.1.64
2006-05-19 14:45:48 [SETI@home] Throughput 11175 bytes/sec
2006-05-19 14:45:48 [---] request_reschedule_cpus: files downloaded

Andy

John, with 5.4.9 we have the check of the client_state.xml file, doesn't that greatly reduce the chance of corruption?

Yes it does, from certain events. For example a sudden power loss may only kill the currently active workunit rather than the entire queue. It still can not prevent a dead hard drive though.

---

BOINC WIKI

BOINCing since 2002/12/8

It still can not prevent a dead hard drive though.

If BOINC is on a drive that dies, there's nothing one can do about it anyway.

---