Validation Inconclusive, is it me or is this becoming more common?

Since they've broken that out for filtering on the results page I've notice that it's been growing as more and more of my GPU units are now waiting for a 2nd opinion. Now I agree that outright mismatches in number of pulses/spikes/triplets/Gaussians detected warrant another look but when both a CPU and GPU unit report the same, even all 0s, why would it be classified as inconclusive? It can't just be because of the flop count, there's no reason why two different apps, optimized for their specific platforms, have the same or reasonably close flop count.

When they first introduced the breakout, my inconclusive units were around 1/3 of my pending. Now they are nearly the same and is more than my daily valid. Did someone tightened up the valid requirements recently?

Edit: I just noticed that it appears that the additional unit isn't being assigned and hasn't been for a while now. That may have to do with the huge pile of MB units generated post crash being handed out first and would also explain why the number of inconclusive is growing.
____________
"Life is just nature's way of keeping meat fresh." - The Doctor

As I recall from previous discussions, the std.err.out report that we see is only a summary, not the whole story. There are significant differences between CPU and GPU apps in the way they process the WU data, so even if the pulse/spike/etc Counts are the same, they may not BE the same pulses, spikes, etc. I have seen this many times when my stock CPU apps are paired with GPU or Optimized apps.

There are also differences in precision and thresholds, so a particular signal may be above threshold on one app and just below it (and so not be counted) on another. There is a mechanism to determine how many signals match and how many do not. IIRC, it is 50% or more to validate, less than 50% you get an "inconclusive" and a third look.

Also, IIRC, resends go to the end of the queue, so they wait until after all the current batch of new WUs get sent out. They built up a big batch of new WUs to help us get through the planned outage this weekend, the resends are behind them.
____________
Donald
Infernal Optimist / Submariner, retired

I have noticed in the past few weeks being AP-only that I'm starting to see a lot of inconclusive results on the first go-around. Almost always, it is an open_cl GPU app that I get paired with..sometimes stock, sometimes optimized. At this moment, I have three of them, and they're all against stock.

In these past few weeks, all of them have granted me credit, as well as the other two parties. I haven't seen one yet that left someone with nothing, so that must be evidence of the precision thresholds between CPU and GPU. They're all above 50% similar, but obviously wasn't 100% for the first wingmate.

It is interesting though, because other APs will get paired up with stock open_cl and validate just fine. It just used to be maybe 1 out of 100 that would end up being inconclusive, but now it seems to be closer to about 1 in 20.
____________

Linux laptop uptime: 1484d 22h 42m
Ended due to UPS failure, found 14 hours after the fact

And that I can understand. However I've found another case were my system and my wing man's reported zero spikes, pulses, triplets, gaussians found and the it is still considered inconclusive. Did we somehow not find the same degree of nothingness?

Anyway like I stated before, the build up of inconclusive units is because the tie-breaker isn't being assigned for some reason over the last week or so. I imagine in the normal course of events (especially due to the 100 unit queue limits) the tie-breaker will return in a day or three and the work unit moved to validated, keeping the inconclusive list from growing longer while also keeping my RAC from slipping.

I'm more interested is seeing the tie-breaker being assigned again than knowing the reason why one detection of nothing isn't the same as another.
____________
"Life is just nature's way of keeping meat fresh." - The Doctor

Anyway like I stated before, the build up of inconclusive units is because the tie-breaker isn't being assigned for some reason over the last week or so. I imagine in the normal course of events (especially due to the 100 unit queue limits) the tie-breaker will return in a day or three and the work unit moved to validated, keeping the inconclusive list from growing longer while also keeping my RAC from slipping.

I'm more interested is seeing the tie-breaker being assigned again than knowing the reason why one detection of nothing isn't the same as another.

And yes, as sure as Galoka didn't think that the Ulus were too ugly to save, my Validation Inconclusive stack has been steadily decreasing since last night now that all the tie-breaker units have been assigned to wingmen. That'll also mean my RAC will bounce back up to where it should historically be.

It still bothers me that the optimized ATI/AMD code has a tendency to under detect pulses relative to the stock CPU code. It makes me feel like I'm not doing proper science.
____________
"Life is just nature's way of keeping meat fresh." - The Doctor