LHC@home

I got a couple of WU's stuck with validation inconclusive

http://lhcathomeclassic.cern.ch/sixtrack/workunit.php?wuid=17490395
http://lhcathomeclassic.cern.ch/sixtrack/workunit.php?wuid=17445763
http://lhcathomeclassic.cern.ch/sixtrack/workunit.php?wuid=17444083
http://lhcathomeclassic.cern.ch/sixtrack/workunit.php?wuid=17441053
http://lhcathomeclassic.cern.ch/sixtrack/workunit.php?wuid=17440832
http://lhcathomeclassic.cern.ch/sixtrack/workunit.php?wuid=17419979
http://lhcathomeclassic.cern.ch/sixtrack/workunit.php?wuid=17283010

Not sure what's happening, they should send out additional but they seem to just flop to unsent then get stuck?

Not a problem on your host, your wingman has already been reported in this posting.

At some point your workunits will be delivered a third time and when those come back, your results should validate.

The server side scheduler seems to place redeliveries at the end of the queue and with the currently quite long running workunits it might take some time until they moved to the top of the queue.

I didn't notice it was the same wingman in all of them!

it seems like the resends should be at the front?

Thanks Ananas; doesn't seem too good like that and
probably also explains why we tend to have a tail of
incomplete cases on our side. I'll see if we can't improve
that. Anyway queue was empty this morning so hopefully
this should be sorted out. More work is coming. Eric. .

---

I received a few redelivered ones a few hours ago, they can easily be recognized because most have a shorter deadline (download errors seem not to reduce the deadline) and all do not end with _0 or _1.

I think there is a server setting to put re-tries 1st in the queue. Richard might know.

I think there is a server setting to put re-tries 1st in the queue. Richard might know.

I don't think there's a queue-order setting: my guess is that queue-ordering is primarily governed by primary-key indexing on ResultID - there's not a lot you can do about that.

There is a selection of controls which might help to ensure that once the resends at the end of the queue finally reach the front and start getting issued, they spend as little extra time 'in the wild' as possible.

Project Options - Accelerating retries

That includes sending the resend tasks to hosts with (historically) a fast turnround time - the meaning of 'fast' being configurable - and also reducing the deadline for return.

Got another couple of results that seem different not the xxx504 host.

http://lhcathomeclassic.cern.ch/sixtrack/workunit.php?wuid=17592766

Not sure how CPU time can be > Run time??

This is strange too

http://lhcathomeclassic.cern.ch/sixtrack/workunit.php?wuid=17625043

the CPU times align but they don validate?

How about 5952 and 257 inconclusive from these:

http://lhcathomeclassic.cern.ch/sixtrack/results.php?hostid=10137504

http://lhcathomeclassic.cern.ch/sixtrack/results.php?hostid=10172067

---

The both went through today, new wingman fixed things.

Still problems on hostid=10137504 noted previously.
10 valid results but 2973 inconclusive and 2352 pending. Definitely something amiss with only "<core_client_version>7.2.28</core_client_version>" in the stderr.
Aqvario's other machines look ok, just this one where almost all wus only last a few seconds and don't produce a full stderr.
They've been here a long time but maybe doesn't pay attention to each machine.