Double Check - A discussion thread
 

ltd: I've seen that there are alot more results added to double check from the first pass range these days than earlier. Have you got any idea why this is happening? Is it just a coincidence, or is something malfunctioning?

Which tests do you mean?
For me everything looks fine.

The tests from primegrid come due to the fact that the BOINC server only finishes a test with two identical residues.

Then we have VJS, Joe_o and your account on the DC server.
Numbers look reasonable there also.

On my account i dumped everything from the offline systems.

All the other residues come from systems that report a residue for a pair that is already finished by another user. At least for the 4 tests I have crosschecked this is the case.

Sorry, I should have been a bit more precise... :)
These are the ones I was writing about:

[quote=ltd;157463]All the other residues come from systems that report a residue for a pair that is already finished by another user. At least for the 4 tests I have crosschecked this is the case.[/quote]

How long does the llrnet-server actually wait before it reissues a WU?

The llrnet server is set to a timeout of 28 days.
But most of the time the sporadic dc tests do not come from clients that miss the deadline by a few days. Else I would already have changed the deadline.

The typical dc test comes from somebody who stops contributing while he is in the middle of a test and after a few weeks or months he starts again to use the PC to do llrnet work.

The client then finished the workunit started a long time ago and as there is already a residue the new one counts as DC test.

[quote=ltd;157639]The typical dc test comes from somebody who stops contributing while he is in the middle of a test and after a few weeks or months he starts again to use the PC to do llrnet work.

The client then finished the workunit started a long time ago and as there is already a residue the new one counts as DC test.[/quote]

OK, I understand. It's just that I've once seen that one of my "fresh" WU's was credited as a DC. And I know it was new, because it was the first time I ran llrnet (8 instances on a dual quad) and suddenly I was credited for a DC without ever having stopped my clients. Could be that it was just some obscure bug in llrnet, though.

Speaking of llrnet... I tried to get hold of the developer of llrnet, but it turned out he was to busy in his work to help sort out the bug with llrnet and Windows 2003.

Also, I would like to mention this:
Next test handed out(N): 4000068

4M, here we are! :D

What you describe is an error due to the combination of llrnet server and my local database. There is a chance that the following happens:

1. Person A gets a WU assigned
2. The WU times out
3. Person B gets the reassigned WU
4. While person B runs the WU person A reports his result.
5. There is a gap in my scripts that leads sometimes to
Person A getting the result counted as first pass and person B as second pass.

I know how it happens but I have no clue how I could extend the interface with reasonable effort to solve the problem. My best idea so far would need around a week including the rebuild of two tables.

the dc n has been stuck at 3664116 for a while.

I'm hoping this isn't one of my tests LOL

No the DC n is on one of my offline machines.
It is already finished as everything below 3.8M but not yet imported.
30% of the range 3.8-3.9 is also done.

Hey sloth is that a i7 your running in DC??? Just noticed 8 tests at once.

What's your times like.

Good question. As I might get my hands on either a C2Q or a n i7 920 next month it would be interesting to hear more about the performance.

No nothing special or new. Just part of playing with new software so I grabbed a bunch off the llrnet server and after crunching it with the new stuff formatted the output for llrnet and submitted it back.

S.