http://setiweb.ssl.berkeley.edu/beta/results.php?hostid=63555&offset=0&show_names=0&state=3&appid=
This host uses opt V6 app for v7 work.
owner Spike_nl

http://setiweb.ssl.berkeley.edu/beta/results.php?hostid=63555&offset=0&show_names=0&state=3&appid=
This host uses opt V6 app for v7 work.
owner Spike_nl

And he's got a bunch of valid WUs too with that app, even though it doesn't have any autocorrelation.

http://setiweb.ssl.berkeley.edu/beta/results.php?hostid=63555&offset=0&show_names=0&state=3&appid=
This host uses opt V6 app for v7 work.
owner Spike_nl

And he's got a bunch of valid WUs too with that app, even though it doesn't have any autocorrelation.

Of that host's most recent 45 CPU "Valid", one was a result_overflow on Spikes so there was no best_autocorr from the wingmate either, the other 44 were all weakly similar so not the canonical result going to the science database.

The danger, of course, is that another user might do the same and results from 2 hosts running anonymous setiathome_enhanced apps renamed to setiathome_v7 could be assimilated.

Other than overflows, it may be almost impossible for a properly processed v7 WU to not have a best_autocorr. Perhaps the Validator should be revised to insist that full length results have a best_autocorr to be granted credit.

                                                                  Joe

Another one here, and this time from main. http://setiathome.berkeley.edu/results.php?hostid=5940343

He even manages to get some results as valid, and even canonical, and into the science database. Most are becoming invalid immediately, but some are validated.

Here's one canonical: http://setiathome.berkeley.edu/workunit.php?wuid=1270273091

Isn't it time to cut off these hosts that deliberately tries to cheat and destroy the science? Pull the plug, then maybe the wake up and smell the stink.

My take is in post 1385271 of the "Wondering why host gets Invalid" thread discussing that host. AFAICT there is no harm to the science, and it would probably be impractical to send a clearer indication to the user that his configuration is not being very productive.

                                                                   Joe

My take is in post 1385271 of the "Wondering why host gets Invalid" thread discussing that host. AFAICT there is no harm to the science, and it would probably be impractical to send a clearer indication to the user that his configuration is not being very productive.

                                                                   Joe

Well yeah. At this moment, he suffers more than the project does, since he mostly produces invalids.

Came across another user running v6 apps on v7 tasks:

Computers belonging to f_n_t

I have PM'd him.

Claggy

I've got an odd invalid v7 task, where my wingman just has it marked inconclusive:

Workunit 1269429805

Did the validator think my task was done with a v6 app?

<core_client_version>7.0.64</core_client_version>
<![CDATA[
<stderr_txt>
setiathome_CUDA: Found 1 CUDA device(s):
Device 1: GeForce GTX 460, 1024 MiB, regsPerBlock 32768
computeCap 2.1, multiProcs 7
pciBusID = 1, pciSlotID = 0
clockRate = 1600 MHz
In cudaAcc_initializeDevice(): Boinc passed DevPref 1
setiathome_CUDA: CUDA Device 1 specified, checking...
Device 1: GeForce GTX 460 is okay
SETI@home using CUDA accelerated device GeForce GTX 460
mbcuda.cfg, processpriority key detected
pulsefind: blocks per SM 4 (Fermi or newer default)
pulsefind: periods per launch 100 (default)
Priority of process set to NORMAL successfully
Priority of worker thread set successfully

setiathome enhanced x41zc, Cuda 5.00

Detected setiathome_enhanced_v7 task. Autocorrelations enabled, size 128k elements.
Work Unit Info:
...............
WU true angle range is : 2.714665
re-using dev_GaussFitResults array for dev_AutoCorrIn, 4194304 bytes
re-using dev_GaussFitResults+524288x8 array for dev_AutoCorrOut, 4194304 bytes
Thread call stack limit is: 1k
cudaAcc_free() called...
cudaAcc_free() running...
cudaAcc_free() PulseFind freed...
cudaAcc_free() Gaussfit freed...
cudaAcc_free() AutoCorrelation freed...
cudaAcc_free() DONE.

Flopcounter: 16353992651654.465000

Spike count: 4
Autocorr count: 0
Pulse count: 0
Triplet count: 2
Gaussian count: 0
Worker preemptively acknowledging a normal exit.->
called boinc_finish
Exit Status: 0
boinc_exit(): requesting safe worker shutdown ->
boinc_exit(): received safe worker shutdown acknowledge ->
Cuda threadsafe ExitProcess() initiated, rval 0

</stderr_txt>
]]>

Claggy