Unnecessary third result will not be canceled by server

Grubix
Grubix
Joined: 1 Jul 08
Posts: 19
Credit: 159690452
RAC: 0
Topic 198212

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.

AgentB
AgentB
Joined: 17 Mar 12
Posts: 915
Credit: 513211304
RAC: 0

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

Quote:
If set, and the client is processing a result for a WU that has been canceled or is not in the DB (i.e. there's no chance of getting credit), tell the client to abort the result regardless of state. If client is processing a result for a WU that has been assimilated or is overdue (i.e. there's a chance of not getting credit) tell the client to abort the result if it hasn't started yet. Note: this will increase the load on your DB server.
Grubix
Grubix
Joined: 1 Jul 08
Posts: 19
Credit: 159690452
RAC: 0

Hi AgentB, thank you for your

Hi AgentB, thank you for your answer.

Quote:
I think this thread explains it very clearly...


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.

AgentB
AgentB
Joined: 17 Mar 12
Posts: 915
Credit: 513211304
RAC: 0

RE: I think it would be

Quote:
I think it would be nice if E@H makes it automatically. :-)

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.

Grubix
Grubix
Joined: 1 Jul 08
Posts: 19
Credit: 159690452
RAC: 0

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.

AgentB
AgentB
Joined: 17 Mar 12
Posts: 915
Credit: 513211304
RAC: 0

RE: Normally S6Bucket have

Quote:
Normally S6Bucket have a deadline of 14 days.

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

Quote:

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.

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.

Quote:

In my opinion, a smaller buffer does not change the resends I get.

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.

Bernd Machenschalk
Bernd Machenschalk
Moderator
Administrator
Joined: 15 Oct 04
Posts: 4307
Credit: 249716130
RAC: 34876

RE: Hi AgentB, thank you

Quote:

Hi AgentB, thank you for your answer.

Quote:
Now it is clear, not needed tasks are not canceled by E@H. I think it would be nice if E@H makes it automatically. :-)

I am not aware of any feature in BOINC to cancel individual tasks of operational workunits, nor of any project that makes use of it. Most projects I know use adaptive replication anyway, and thus mostly have only one task per workunit. I'm always happy to extend my knowledge, though.

There is a feature, however, that can cancel tasks that are already on clients for workunits that were canceled by the project. This feature is disabled on Einstein@Home since we found it overloads our database, at least in its current implementation.

BM

BM

Richard Haselgrove
Richard Haselgrove
Joined: 10 Dec 05
Posts: 2143
Credit: 2941517915
RAC: 716577

RE: There is a feature,

Quote:

There is a feature, however, that can cancel tasks that are already on clients for workunits that were canceled by the project. This feature is disabled on Einstein@Home since we found it overloads our database, at least in its current implementation.

BM


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.

Quote:
0|1
If set, and the client is processing a result for a WU that has been canceled or is not in the DB (i.e. there's no chance of getting credit), tell the client to abort the result regardless of state. If client is processing a result for a WU that has been assimilated or is overdue (i.e. there's a chance of not getting credit) tell the client to abort the result if it hasn't started yet. Note: this will increase the load on your DB server.


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.

Bernd Machenschalk
Bernd Machenschalk
Moderator
Administrator
Joined: 15 Oct 04
Posts: 4307
Credit: 249716130
RAC: 34876

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

Grubix
Grubix
Joined: 1 Jul 08
Posts: 19
Credit: 159690452
RAC: 0

Hello and thank you for the

Hello and thank you for the explanation.

Quote:
I think that modern clients will self-abort tasks which haven't been started and are already past deadline...


Yes that's right.

Quote:
... tasks which are still within their individual deadline, but aren't needed because two predecessors have already validated ...
... the full package places too much load on the server ...


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. :-)

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.