Unnecessary third result will not be canceled by server
29 Aug 2015 20:30:44 UTC
Topic 198212
(moderation:
The last few days I got a larger number of resends. Some WUs have now been reported from both users (after the deadline). Therefore, the resend is no longer needed.
- These WUs have not been started on my computer.
- The client has been contacted the server several times.
Normally (as I know it from other projects) such tasks will be automatically canceled by the server.
Here are three examples:
224902203 , 224889327 , 224973551
Bye, Grubix.
Unnecessary third result will not be canceled by server
)
I think this thread explains it very clearly, it may work for some projects, not all, this behaviour is normal at E@H.
Edit: see also here
Hi AgentB, thank you for your
)
Hi AgentB, thank you for your answer.
I had already read the posting from Gary, but not attentive enough. :-(
Now it is clear, not needed tasks are not canceled by E@H. I'll do it like Gary and review the tasks and possibly cancel by hand. I think it would be nice if E@H makes it automatically. :-)
Bye, Grubix.
RE: I think it would be
)
Perhaps Grubix, but i think you can help here.
I notice that this host has a large number of pending tasks, it has Average turnaround time is 4.3 days, but the host is typically completing these tasks in ~0.4 days, S6Bucket have a 7 day deadline. This means you are always working "old" tasks and the reason they are old is because your cache is large.
I think it would be nice if you could consider looking at the N days of work and reduce those numbers.
Hi AgentB. Normally
)
Hi AgentB.
Normally S6Bucket have a deadline of 14 days. Only resends have a shorter deadline (it was so the last few months). So I think a turnaround time of 4 days is not particularly high. Furthermore, the computer has a very bad internet connection, so I need a slightly larger buffer. Sometimes I do not have internet for 2-3 days.
A smaller buffer would not change the problem:
- I produce no resends. I always reporting the results within the deadline.
- My buffer also has no effect on the original (first) WU to be returned after the deadline. On the contrary, a larger buffer gives the server the ability to cancel the WU before it has started (if the result is arrived even after the original deadline). This saves computing time.
- The only thing that would change would be the chance that a late WU still gets points.
In my opinion, a smaller buffer does not change the resends I get.
Bye, Grubix.
RE: Normally S6Bucket have
)
Resends will become the norm as S6Bucket runs out of tasks, these seem to have a much shorter deadline. 7 days or less it seems?
See current status
It is difficult to handle this but if your internet connection has problems lasting N days, then having a queue size which lasts N+1 days (long enough to cover an outage of N days) means, after a N day outage, some of the tasks which are normally N+1 days old when reported, will now be N days older due to waiting for internet to return, so a total of 2N+1 days- for those unlucky tasks caught ready to send as the outage starts.
For this host the value for N is about 3.3 it seems (turnover is is 4.3 days)
Slightly unrelated, but if you have concerns about internet connectivity, i find S6bucket is very heavy on internet bandwidth, perhaps now is a good time to switch more processing to FGRP.
You are quite right, it will not change the number in any way, it will however allow the host to start a task sooner, as the queue is shorter.
RE: Hi AgentB, thank you
)
BM
RE: There is a feature,
)
Looking at the Project Options wiki, it looks as if there are two logically separate parts to that feature - although they can't be turned off and on independently.
I think that modern clients will self-abort tasks which haven't been started and are already past deadline, but it's the middle section - tasks which are still within their individual deadline, but aren't needed because two predecessors have already validated - which people are asking about here.
And they have their answer - the full package places too much load on the server, and the config doesn't allow it to be broken into smaller parts.
Thanks Richard for the
)
Thanks Richard for the clarification.
Note that the old BOINC code on Einstein may not even have all features that are mentioned in the current documentation ...
BM
BM
Hello and thank you for the
)
Hello and thank you for the explanation.
Yes that's right.
It is a pity that this feature places too much load on the server. I had only thought that some computing time can be saved thereby.
Live long and prosper, Grubix. :-)