Help!! I want to abort tasks but E@H keeps resending them to me

OK, because you are reporting your experiences in this particular thread, I'm assuming you are interested in understanding what is going on in order to assist in some way with the cleanup of the remaining tasks in the old run, particularly any resends. I'll try to explain it all as best I can. Please note that these comments and explanations are NOT designed for people who don't want to micromanage and just want a 'set and forget' experience. If you're in that category, please ignore what follows. Please don't take ANY action if what follows is not perfectly clear to you. BOINC will handle it automatically, but rather inefficiently, if left alone.

Your log snippet starts with the reporting of completed tasks but it doesn't say what sort of tasks were reported. I very much doubt you are reporting resent tasks but you could be reporting resends or primary tasks - you can't tell without looking at the actual task names.

I think you may be confusing what the scheduler is calling a "lost task" that is being "resent" with what I call a "resend" task. When tasks are first issued, I call them "primary" tasks. They always have an _0 or _1 suffix. If a primary task fails for whatever reason, the scheduler (when it becomes aware of this failure) will issue a further copy of the task. I call this extra copy a "resend" and you can always distinguish these from primary tasks because they have suffixes like _2, _3, _4, etc, as many as are required to eventually complete the quorum - with a max limit of 20 tasks.

The snippet above simply shows that your client reported 8 tasks and wasn't asking for any new ones - after all you did have NNT set. You would have to check the suffix on each of those tasks to see if any were resends and it really doesn't matter because it's not connected with what comes next.

This snippet tells you there was a discrepancy between the schedulers idea of things and your client's idea of things. There are (at least) 12 tasks (and they are all primary tasks - check for yourself) that the scheduler thinks you should have and that your client doesn't have. As you could imagine, it's extremely important that both sides of the client/server relationship should have identical views of the world. Your client has sent a list of the tasks it has and the server thinks that the client should have more. So the scheduler (irrespective of your NNT setting) will force the client to take these extra tasks (the "lost" tasks) so that each side will agree. It will do this 12 at a time so it could well be that you will eventually be sent more than 12 on the next exchange between client and scheduler - if there are any more lost tasks.

So how do tasks become lost? The most common reason is simply bad luck. If your client happens to ask for work at a time when the server is under heavy load, it may not receive a reply within a timeout interval. The client stops waiting and reports (on the messages tab of BOINC Manager) a problem talking to the server. it will usually retry after a further interval but this could easily have been prevented if NNT had been set in the interim. In the meantime, the server would have eventually got around to answering your request and would have issued tasks and recorded that fact in the database. Your client is no longer listening so it wouldn't have received the tasks. So the discrepancy now exists. This really isn't much of an issue because the server will notice and make good the discrepancy on the very next contact and your client can't refuse the lost tasks even if NNT is set. So agreement is going to be restored eventually.

There are a number of things in the above snippet that are important to understand. Firstly, these are not tasks that are being downloaded. They are data files, namely skygrid files and lots of LIGO data files - in fact all the data needed to support the 12 lost tasks that the scheduler had just resent to you. Secondly, there would have been about 2GB of data which would have taken quite a long time to download - and it was for just 12 tasks! Is it any wonder I'm on a crusade to improve this. Take a good look at all the different and unrelated frequencies being sent to you. In other words, check the frequency value included as part of the task name of each lost task being resent. The scheduler is not very smart in the way it assigns work - particularly from now on with so little work left in the current run.

Earlier on in this thread I discussed these sort of issues with Oliver Bock, who (in time) will be able fix the problems. This was a couple of weeks ago and there were more tasks available then. What happened to you is exactly what I described to Oliver in this message that I posted on April 7. Here's the critical bit.

Note in the last paragraph above, I commented that 10 tasks would be supplied from about 7 different frequency sets. In your case you got about 12 tasks from about 9 different frequency sets. This is the sort of inefficiency that I'm concerned about and (hopefully) Oliver will vastly improve.

Any participant can make a big improvement by their own actions. To prevent this unnecessary jumping to multiple frequency sets, just make sure you don't ask for a big number of tasks in one single hit if you don't have the necessary blocks already in your state file to support it. Always make it your business to know how many frequency bands you have available above the particular frequency that your most recent task was for. If you know you don't have many, just follow the next procedure. It's a bit painful to do but ask for 20 tasks by asking for just 1 initially (eg work out what cache size you need, to get just (say) a single extra task). In the worst case there may be no tasks for your current frequency set and you will get a frequency jump to a new set along with either 48 or 52 LIGO files. Once you have them all, you could then ask for at least 10 more tasks without risking another frequency jump. The scheduler can now see all the 12 or 13 frequency bands you have and will supply tasks for these bands without doing a complete frequency jump. You will download 4 extra LIGO files for each 0.05Hz frequency shift to the next band but this is far less than what happens with a jump to a different frequency set. When you get those 10 tasks (and the extra LIGO data as described) you can keep asking for 10 (or even more) at a time and keep getting more tasks from the same frequency bands with perhaps the occasional server delete request and the 4 extra LIGO files. The rule to apply is, "Don't ask for more tasks than what could be supplied for the frequency bands for which you already have blocks in your state file." You can estimate this by allowing say 2 tasks per frequency band. So if you've just downloaded a single task, you would have at least 12 current frequency bands in you state file and you could estimate that quite a lot of extra tasks could be asked for next time. If you're keen enough you can also remove the tags from the state file to get more tasks from the bands that have been marked prematurely for deletion.

Yes, everything in that log snippet is compatible with the way I know that the scheduler works.