Posts by xii5ku

1) (Message 5865)
Posted 24 Jun 2018 by xii5ku
Post:
Remember, the project had no chance to plan and prepare for this sudden spike in client capacity.
2) (Message 5861)
Posted 24 Jun 2018 by xii5ku
Post:
acronyms in my post:
TIA = thanks in advance
DC = distributed computing
3) (Message 5860)
Posted 24 Jun 2018 by xii5ku
Post:
Jerome,

thanks for commenting. The fact that less manpower is being devoted to formula-boinc.org than would be desirable is already known to all who have been participating in sprints lately. (Cf. "mod_python error".) The lack of manpower is also understandable and excusable. But (1.), there is something that could be done about that (e.g., Sébastien could look for a deputy), and (2.) the extra amount of work required would be limited.

For example:

  • A few weeks before a sprint, select three projects randomly. This can be done on a relaxed schedule even, but not too late.
  • Send an e-mail to the administrators of each project, asking whether it would be convenient to hold a contest at the given time frame.
  • As soon as the first positive reply is received, select this project, inform & TIA the admin, and send a TIA & cancellation note to the other two admins.
  • If only negative replies are received, cancel the sprint.
  • If no replies are received at all, either cancel the sprint, or select one of the projects anyway, and state in the sprint announcement that no contact to the project admin could be established prior to the sprint.


So, this is not much extra work (just send 6 e-mails, plus perhaps answer questions which the project admins could have). And in fact a procedure like this could even somewhat reduce the routine checking that Sébastien is probably already doing.

I know it is easy for me to give "advice" from the sidelines, but still. Other, much more experienced DCers than me have repeatedly suggested that Formula Boinc should work with the project admins.

PS,
I should post this at the formula-boinc.org forum instead of here, but I admit that right now I am too lazy to register and wait for the admin's approval for account creation.

PPS,
I appreciate a lot what Sébastien is doing with formula-boinc.org. I am still quite new to DC (into it less than two years), but Formula BOINC is the very reason for me to have joined quite a variety of projects already. It also provides certain motivation to spend for DC equipment and electricity.

4) (Message 5850)
Posted 22 Jun 2018 by xii5ku
Post:
So I suggested earlier in this thread that shortening the task turnaround times (e.g. by means of shorter deadlines) would enable this project to get more work done with the same amount of disk space.

Now that I have watched server status for two days, I think I was wrong. It now seems to me that not the tasks in progress are filling up the server, but the completed and validated tasks = finished WUs. I.e. I suppose that the project admin needs to periodically move the end products of the completed work off of the server. And if the admin is late doing so, everything grinds to a halt of course.

Reasoning: Tasks ready to send remain near 0, while tasks in progress decline by 80,000 per day now. Hence, it can't be the tasks in progress which clog the server, it must be the completed WUs.

PS, if this rate holds, tasks in progress will be 0 on Monday.
5) (Message 5849)
Posted 22 Jun 2018 by xii5ku
Post:
On June 22, Alessio Susi wrote:
Are there WUs for Nvidia GPUs? I have a GTX 1080 Ti and want to try it with A@H

To expand on what Woodles wrote, my understanding is that the work scheduler can distribute tasks freely to any of the current application versions, regardless what OS or CPU architecture or GPU architecture. (The latter being limited to cuda55 on Win/x86, Win/amd64, Linux/amd64 currently.) Thus, GPU tasks are scheduled out of the same pool of work as CPU tasks. And hence, GPU tasks are equally scarce as CPU tasks.
6) (Message 5844)
Posted 22 Jun 2018 by xii5ku
Post:
Gridcoin aren't smashing anybody. What they do is trying to harvest fake money; nothing else is their concern.

Meanwhile, tasks-in-progress has fallen from 320,000 to 290,000, while tasks-ready-to-send remain at ~0.
7) (Message 5842)
Posted 22 Jun 2018 by xii5ku
Post:
On June 21, I wrote:
What are your average task turnaround times?

I can estimate it: https://stats3.free-dc.org/stats.php?page=proj&proj=ast is currently showing about 65 M PPD for the entire project. And http://asteroidsathome.net/boinc/server_status.php shows a limit on tasks in progress of about 320,000.

~65 M PPD / (480 points per task) = ~140,000 tasks validated per day

~320,000 tasks in progress / ~140,000 tasks validated per day = ~2.3 days average completion period of the WUs

Edit:
More interesting than the average would be to know what the distribution of the WU completion times looks like. Then decrease the task deadline to the current 75-percentile of the current WU completion times, for example.

(By WU completion time I mean the time from issuing the first tasks until validation of the two required correct tasks.)

Task deadlines of less than the current 10.5 days should enable Asteroids@home to get more WUs done per day with the same amount of disk space for tasks-in-progress (if other factors, e.g. disk space for whatever post processing you d, are not limiting).
8) (Message 5841)
Posted 22 Jun 2018 by xii5ku
Post:
Last what I heard is that "they" (i.e. Sébastien) do not approach the project admins.

This problem has been brought up at the Formula BOINC forum, but there was probably no change in procedure yet.
9) (Message 5833)
Posted 21 Jun 2018 by xii5ku
Post:
On June 21, magiceye04 wrote:
Is there no Limit per Host?
e.g. Seti@Home sends only 100 WUs per GPU/CPU.

bcavnaugh is right, there is no per-host limit of tasks in progress here; at least not any below the boinc client-side limit of 1000 tasks-ready-to-start.

While imposing a limit of tasks in progress per host is indeed another way to try lowering the overall amount of tasks in progress, it is not as effective as shortening the deadlines, AFAICS. Users who really want more tasks from a project with such a limit, simply add more hosts.

By the way, SETI@home is an example of per-host limits gone wrong: Their limit is so low that modern hosts fall idle during SETI@home's regular maintenance window each Tuesday (unless users with such hardware work around the per-host limit).
10) (Message 5829)
Posted 21 Jun 2018 by xii5ku
Post:
On November 13, jiri kovar wrote:
There are some day breaks between pakages of work.
For the future I recommend you to set the ninimal threeday bunker in Boinc manager.

The more people follow this advice, the more server disk space you are going to need.

On March 12, Kyong wrote:
I have already written serveral times that if there are no WUs, we are aware of it. Asteroids should get a new server in the summer so it should solve problems with free space which is the reason why the work isn't always available to send.

What are your average task turnaround times? If it is more than, say, 2 or 3 days, then consider decreasing your task deadline, which is currently 10.5 days.
11) (Message 5828)
Posted 21 Jun 2018 by xii5ku
Post:
Hi Admins,

just a heads up that load on the server and requests for work may be a bit up from average now.
Asteroids@home has been selected for a 3-day sprint at Formula BOINC:

http://formula-boinc.org/sprint.py?sprint=8&year=2018