Verification backlog

Being listed as "inconclusive" is likely a misnomer in this case and it's not really a "Verification Backlog" as the thread title suggests.  There is no 'backlog' - as soon as there is a valid 2nd result, validation would be attempted, likely without any further delay.

Referring to your linked result, a more correct status message in this case would be the standard "Completed, waiting for validation" message you see for some other results.  This clearly advises that there has been no other completed result for which a validation could have been attempted.  I imagine the wrong status message may have been used because of the "validate error" for one of the other quorum members.

The scheduler probably thought that a validation would have been attempted with only two possible outcomes - either 'valid' or 'inconclusive'.  The validator won't perform a validation at all if either result is complete rubbish.  It just marks the offending result as a validate error, presumably without ensuring that the status goes back to the 'waiting' message for the unaffected result.

I'm not trying to 'nit-pick' about the status message.  There are some people who tweak their systems to squeeze out every last drop of performance.  The appearance of 'inconclusives' (you have several, BTW) can be a cause for concern in that they may have gone too far with the tweaking.  It would be much less concerning if the results were just marked as "waiting for validation", which is a more correct characterisation.

If you look through the full history of the linked workunit, a lot of the delay came from the _2 resend which ended up exceeding the deadline without returning a result.  The 3 other tasks that eventually became errors also added delay so Mikey's comment about people using unsuitable GPUs is also probably a significant factor in causing the delay.  If the _1 original result hadn't failed, there should have been no delay at all :-).

If you follow the link to the computer for the _1 result (your original quorum partner), you find it has a 2GB GPU.  Some tasks do succeed, but that host is just crunching on and trashing most of them.  For the GW GPU tasks there are currently 324 errors and 174 valids.  Almost 2 out of 3 tasks are failing.

I didn't check, but a lot of your delay may be being exacerbated because you are partnered with the host producing all those errors.  Locality scheduling (which is vitally necessary) will just keep feeding tasks from the same series to both your host and the 2GB GPU host.

Perhaps we should start a petition to get Bernd to completely ban hosts with less than 3GB from receiving GW GPU tasks.  This is only going to get worse as the analysis frequency moves to ever higher values as the run proceeds.  According to what he posted quite some time ago there are supposed to be 'restrictions' but since this problem seems to be continuing, the restrictions are clearly not strong enough.

What do all readers think?  Should 2GB GPUs be restricted to gamma-ray pulsar tasks only?

I think a first step should be to ban them from running GW tasks. But what does it take to run the Binary Radio Pulsar Search (Arecibo, GPU) tasks? Will the ban restrict them from those types of tasks as well? Personally I'd like to see a restriction based on the ability of the gpu to successfully complete the tasks and if a gpu with only 2gb of ram or less can't do the work anymore then it needs to be restricted. BUT at the same time a note needs to be put under Preferences, Project where people select the tasks they want their pc to run saying that 'any gpu with 2gb of onboard memory or less cannot run this task' or 'restricted to gpu's with 4gb or more of ram'.

People can still today buy brand new gpu's with 2gb, or less, of ram on them and they need to be told that if they want to participate here at Einstein these tasks are the ones you can't run with that gpu. Now by the same token yes there are brand new gpu's being sold with alot more on board memory on them than 2 or even 3gb of ram and yes Einstein would love to have them crunching tasks here and relieve some of the backlog on the GW tasks but until Einstein itself recognizes the credit inbalance between the GW and the GRP tasks alot of people will go for more credits even if they have a chance to do 'more valuable' work.

You need to look at the apps page again. https://einsteinathome.org/apps.php

Show me any BRP gpu application that is intended for AMD or Nvidia.  There is none.  The only app is for Intel igpus. 

So you don't need worry about any restriction for low VRAM mainstream cards for that project.

1. GW GPU flops estimates are wrong/low (this is what causes the issues with DCF and low credit reward). this value needs to be increased to an appropriate value that better reflects computational effort.

2. the scheduler mechanism/calculation that tries to see if the user's GPU has enough VRAM is using the wrong value. currently they are looking at Global (total) ram in their comparison. when they need to look at Available ram instead. you might have 2048MB of total ram on a 2GB GPU, but the OS might be using say 300MB to run the desktop environment. so when the scheduler thinks a task needs 1800MB it goes ahead and sends it to you when it shouldnt because you really only have 1700MB available. this is why so many 2GB GPUs have problems with GW and why some tasks might work and others don't.

_________________________________________________________________________