Loads of 4174's and a 4165 here errored multiple times.

Mike

Unixchick, the number of new SCC1-tasks being distributed is dropping fast, as the server (a) needs to find reliable clients (because of the increasing amount of tasks that need to be verified and that is because of the increasing amount of unreliable clients, caused by tasks from the faulty batch (still with Replication > 0) that error out immediately) and (b) to abort (Server Abort) tasks that will be 'Too Late' anyway (from the faulty batch that has Replication > 0).
So, SCC1-tasks are still being distributed, but the system has difficulty finding reliable clients. This is the same situation as reported in post 686894. The good news is that the server is holding up.
Still, in this situation I think that it is a good idea to abort (User Abort) the faulty tasks that you receive, for you will lose your reliability status if you execute a faulty task and as long as you have a reliable client your tasks don't need verification, giving the server more breathing room and more chance to send some tasks to you.

Adri

Adri,

From your post 687153 from a few hours back...

In this case that would've been me :-) I've written a Python script that scans client_state.xml for tasks that could be from invalid work-units, finds the specific flex file, checks it for the fault and invokes boinccmd to abort the task if appropriate. Here's a sample from its log on one of my machines (times are BST [UTC+1][*1]):

2023-06-08 19:17:11 - SCC1_0004176_MyoD1-C_50786_0:  aborted.
2023-06-09 04:32:21 - SCC1_0004165_MyoD1-C_0518_0:  aborted.
2023-06-09 08:07:26 - SCC1_0004174_MyoD1-C_0213_1:  aborted.
2023-06-09 09:52:28 - SCC1_0004174_MyoD1-C_0092_3:  aborted. 
2023-06-09 11:57:30 - SCC1_0004165_MyoD1-C_1998_0:  aborted.
2023-06-09 12:02:30 - SCC1_0004165_MyoD1-C_2032_0:  aborted.
2023-06-09 12:12:31 - SCC1_0004165_MyoD1-C_2086_1:  aborted.
2023-06-09 13:27:33 - SCC1_0004176_MyoD1-C_56113_0:  aborted.
2023-06-09 13:42:34 - SCC1_0004174_MyoD1-C_1241_2:  aborted.
2023-06-09 14:07:34 - SCC1_0004174_MyoD1-C_1565_1:  aborted.
2023-06-09 16:17:37 - SCC1_0004165_MyoD1-C_2405_3:  aborted.
2023-06-09 17:42:38 - SCC1_0004174_MyoD1-C_2246_2:  aborted.

If/when it sees a MyoD1-C task that doesn't have the bad flex file, the script will report "valid file!" and leave the task to run :-)

Your logic for aborting parallels mine, and the effect is obvious... Tthe machine from which that log snippet is taken typically returns about 100 valid SCC1 tasks a day; since I introduced the script I've not had any Errors (as expected) so I still manage to keep my [small] cache topped up despite still seeing "Tasks are committed to other platforms" fairly regularly (for reasons stated frequently in this and other fhreads...) My other systems that run SCC1 are also getting consistent supplies of work (but they don't handle as many SCC1 tasks a day')

Cheers - Al.

[*1] The script is based on the daemon scripts I've written for various other aspects of watching WCG work flow; they all use Python's logger module for the output and I've never bothered to work out how to get it to use UTC instead of local time (if it even can...)

And 4099 But they will be off for the weekend now!

Mike

Al, thanks for your response.

You wrote:
"And I wonder, still I wonder, who'll stop the ..."(*1)

Great! And I wonder, if people are getting inquisitive and interested in your script.

Still I wonder, how does that script handle the situation where a task is received that needs to be executed right away because its deadline is only 3 days instead of 6?
(Occasionally I get a task that has a deadline of 3 days, so it gets a high priority to run and this will always lead to that task in Running state - unless I have enough (MCM1/SCC1) tasks with a 3 day deadline in the queue, which is probably never. )


So, the task stays in the queue, unharmed. Good. The conceivable situation hasn't happened yet, I guess, but - I'm thinking along with you - what will happen when that script sees the same task? Will it report "valid file!" again?


So it isn't as simple as searching for 'python date utc' on internet and then finding this:

>>> from datetime import datetime, timezone
>>> print(datetime.now(timezone.utc).strftime("%Y-%m-%dT%H:%M:%S"))

Nevertheless, I think you should keep local time and just be aware of it. Logging, a nice feature of Python.

[*1] faulty tasks/workunits/batches

Adri
PS I don't have a weekend puzzle ready at this time.