I wonder if the immediate delay request from the scheduler is how it handles things when it has too many connections open... but the 7 second delay it requested doesn't seem to leave it much time to dig out.

I brought that up in the Problems and Technical Issues thread, but there is so much noise in that thread...

Seti uses 301 seconds and Einstein around 60 seconds. Given the influx of new users I would suggest something like 20 or 30 seconds would be appropriate for Rosetta.

---

BOINC blog

I wonder if the immediate delay request from the scheduler is how it handles things when it has too many connections open... but the 7 second delay it requested doesn't seem to leave it much time to dig out.

Err... surely this 7-second delay is just the one we see when doing a manual update, deferring a request for a further manual update beyond the one just done (preventing further downloads more often than that).
It's nothing whatsoever to do with whether andor what gets delivered from the update request.

Yes, it should be increased. It used to be ~250secs at one time (too long imo) but inexplicably changed when the new servers got installed.
A very short time only encourages more unnecessary manual updates and server hits, which should always be discouraged.
I once suggested 30 seconds as a barest minimum, but 50-60 seconds would be more balanced imo
WCG is 127 fwiw

---

I wonder if the immediate delay request from the scheduler is how it handles things when it has too many connections open... but the 7 second delay it requested doesn't seem to leave it much time to dig out.

Err... surely this 7-second delay is just the one we see when doing a manual update, deferring a request for a further manual update beyond the one just done (preventing further downloads more often than that).
It's nothing whatsoever to do with whether andor what gets delivered from the update request.

I've only just worked out what everyone was talking about after upgrading and the event log for Boinc Manager 7.16.5 was as truncated for me as the earlier report.
I added a couple of options for file_xfer_debug, http_xfer_debug etc, Apply'd and Saved then took them out again and everything came back to how it was before.
Very odd.
Does the same for all projects

---

I wonder if the immediate delay request from the scheduler is how it handles things when it has too many connections open... but the 7 second delay it requested doesn't seem to leave it much time to dig out.

Err... surely this 7-second delay is just the one we see when doing a manual update, deferring a request for a further manual update beyond the one just done (preventing further downloads more often than that).
It's nothing whatsoever to do with whether andor what gets delivered from the update request.

I've only just worked out what everyone was talking about after upgrading and the event log for Boinc Manager 7.16.5 was as truncated for me as the earlier report.
I added a couple of options for file_xfer_debug, http_xfer_debug etc, Apply'd and Saved then took them out again and everything came back to how it was before.
Very odd.
Does the same for all projects

<max_event_log_lines>N</max_event_log_lines>
Maximum number of lines to display in BOINC Manager's Event Log window (default 2000, 0 means no limit).

in the cc_config.xml file should allow you to work around whatever is going on.


Edit- at the very bottom of the Event log, "Show only this project" isn't selected?

---

Grant
Darwin NT

Err... surely this 7-second delay is just the one we see when doing a manual update, deferring a request for a further manual update beyond the one just done (preventing further downloads more often than that).
It's nothing whatsoever to do with whether andor what gets delivered from the update request.

I've only just worked out what everyone was talking about after upgrading and the event log for Boinc Manager 7.16.5 was as truncated for me as the earlier report.
I added a couple of options for file_xfer_debug, http_xfer_debug etc, Apply'd and Saved then took them out again and everything came back to how it was before.
Very odd.
Does the same for all projects

<max_event_log_lines>N</max_event_log_lines>
Maximum number of lines to display in BOINC Manager's Event Log window (default 2000, 0 means no limit).

in the cc_config.xml file should allow you to work around whatever is going on.

Edit- at the very bottom of the Event log, "Show only this project" isn't selected?

I didn't mean truncated that way (can't think of the right word).

Where it would normally show

14/04/2020 22:56:53 | Rosetta@home | update requested by user
14/04/2020 22:56:57 | Rosetta@home | Sending scheduler request: Requested by user.
14/04/2020 22:56:57 | Rosetta@home | Not requesting tasks: don't need (CPU: job cache full; NVIDIA GPU: )
14/04/2020 22:56:59 | Rosetta@home | Scheduler request completed
14/04/2020 22:56:59 | Rosetta@home | Project requested delay of 7 seconds

It was only showing

14/04/2020 22:41:00 pm | Rosetta@home | update requested by user
14/04/2020 22:41:03 pm | Rosetta@home | Project requested delay of 7 seconds

What's the word for that? Less verbose?

Anyway, I just updated my laptop earlier too. I went straight to Event Log Options after, ticked a checkbox, immediately unchecked it, Applied and saved it and everything worked as expected.
The "Project requested delay of 7 seconds" message is new in this version and makes sense imo. WCG shows a request for 127 delay, both of which are the backoffs that prevent asking for new tasks straight after the last request. Fine by me.

---