[QUOTE=ATH;435232]That is due to a recent change which means everyone get 1 DC per year at least unless you opt out here: [url]http://www.mersenne.org/thresholds/[/url][/QUOTE]

Ah- OK. That seems pretty reasonable. Thanks for the explanation; I hadn't heard about it.

Norm

[QUOTE=Madpoo;435222]
If I'm reading LaurV's comments on that problem correctly,[/QUOTE]
you don't, there were two different residues, always the same, generated by the same program, with shift zero, for two different FFTs. That problem arose IIRC, during implementing non-power-of-two FFTs in cudaLucas, which was long before implementing the shifting. And it is normal that if you start with the same data, no random, you get the same result. The real problem was that CL was selecting the wrong FFT for it, which was later fixed. You are right in the second part of your post, it was just a case of wrong FFT selection, which kept giving [U]the same[/U] erroneous result, due to the fact that the random part (shifting) was missing, and the error checking was very poorly implemented at that time. It is not the case anymore. In fact all that discussion was in a thread and time where/when people were trying to make a reliable version of CL. I was only the "critique" there. Which CL we have today, thanks to a lot of good people who put a lot effort into developing it.

And I am still self-DC-ing :razz: (not currently, no free resources, but having big plans for the future, as usual, hehe).

[QUOTE=LaurV;435267]And I am still self-DC-ing :razz: (not currently, no free resources, but having big plans for the future, as usual, hehe).[/QUOTE]

Sigh... if you're really concerned about the reliability of your system, do the occasional double-check of someone else's work... DC could use the extra boost. :smile:

Plus that way you'd find out quicker if you were wrong (I mean, testing 36M goes much faster than testing something above 70M).

[QUOTE=LaurV;435267]It is not the case anymore. In fact all that discussion was in a thread and time where/when people were trying to make a reliable version of CL. I was only the "critique" there. Which CL we have today, thanks to a lot of good people who put a lot effort into developing it.[/QUOTE]

Yes, no doubt both CudaLucas and Prime95 are solid today. The only question was, are there any pre-shift results from long ago where perhaps the same bad residue was double-checked into the database.

The fact that this very old version of CudaLucas gave the identical wrong result reproducibly (when used with a badly-chosen FFT size) made me wonder if old pre-shift versions of Prime95 ever did the same (and I mentioned the exponent [URL="http://www.mersenne.org/M1048507"]M1048507[/URL] as an example where I wondered if that happened).

[QUOTE=Prime95;435178]All verified results where prime95 was used for both tests should have at least one result with a non-zero shift count.[/QUOTE]

Eek... may be a bug in that part of the verification.

So... since I had previously triple-checked everything below 2M (that wasn't already triple-checked), I thought, hey, why not make sure everything below 2M has 2 non-zero shift count results. Why? I don't know. :smile:

For no particular reason I queried for any verified results where the only shift-counts were zero... there are 13 of them.

All 13 had the latest verifying run done by our good friend AirSquirrels, part of the strategic double-checking he was helping me out with, especially in regards to the previous results by Robert_SoCal (who made up 12 of the 13 exponents first results).

So maybe it was my fault for assigning those to him when the first test was also done by a GPU.

Anyway, since it was probably my foul-up, I'll do a 3rd test of those 13 using Prime95 with a non-zero shift, and any others that may show up. I think AirSquirrels already finished up with those strategic double-checks and is now working with me on tackling the exponents that need triple-checks to declare the winner.

The fact that Shadow, Satellite and Remote all use the same IP address makes sense because they are all laptops running in my apartment, sharing the same router. The 4-core Workstation is my computer at my workplace and so should have a different IP address.

The fact that the second Workstation is identical to Remote and is running on the same IP address is a big clue. Basically, Remote is a "work from home" laptop, which occasionally connects to a network share. That share contains backups of the Prime95 jobs for both Remote and the 4-core Workstation (stored under different directories), so I'm wondering if I accidentally ran the Workstation backup by mistake or something similar. I'll investigate. If it's the case, then I'll reconfigure the work files so they all run on Remote, then merge the new Workstation with Remote. Would that work or could the merge cause problems due to the different CPU ids?

P.S. Sorry if I raised a false alarm.

Problem solved. It turns out that the copy of Prime95.exe in the backup directory somehow got executed and fetched its own work, at the same time while the regular copy was running. What it resulted in was "Remote" trying to perform twice as many tasks as it was supposed to and hence being somewhat slow on everything.

I've resolved the problem now by shutting down the running processes, making backup copies of what's been computed so far, merging the worktodo.txt files, and synchronising the network share (which also updated the copy of Prime95.exe that got executed somehow).

When I started up Prime95.exe again, a couple of the DoubleCheck tests (M43835747 and M43863007) got automatically unassigned, presumably due to unrealistic completion times - they were nowhere near close to even being started, so I wasn't worried about those, although it's nice to have warning before a task is unassigned sometimes, in case it actually [I]has[/I] been started, say. I do like to complete double-check tasks occasionally... to do my bit in making certain that the list of Mersenne numbers is reliable and to clear the back-log, even if I get no fame from it - it's a good community service!

Sorry if I caused any worries for anyone. It was what people suggested it was... I just wasn't aware that the backup copy of the program started somehow (most likely due to being configured to run on start-up or something). Thank you MadPoo for giving me the clues I needed to identify the problem, since I probably wouldn't have even identified the computer in question.

The potential exploit that was pointed out is something to consider though.

P.S. I dropped the extra "Workstation" CPU that appeared, so I should only have 4 computers to my name currently.

[QUOTE=CuriousKit;435328]The potential exploit that was pointed out is something to consider though.[/QUOTE]

No real exploit. If someone wants to give you credits, is this a serious problem?

LaurV played a bit of a joke on me a couple of years ago. He gave me some serious credits.

Perhaps it's a problem if someone gives you bad results.

Karma goes a long way....

[QUOTE=Madpoo;435312]For no particular reason I queried for any verified results where the only shift-counts were zero... there are 13 of them.

All 13 had the latest verifying run done by our good friend AirSquirrels, part of the strategic double-checking he was helping me out with, especially in regards to the previous results by Robert_SoCal (who made up 12 of the 13 exponents first results).

So maybe it was my fault for assigning those to him when the first test was also done by a GPU.[/QUOTE]

So...even the latest versions of GPU-based LL testing programs still use shift count = 0 ?

[QUOTE=CuriousKit;435328]When I started up Prime95.exe again, a couple of the DoubleCheck tests (M43835747 and M43863007) got automatically unassigned, presumably due to unrealistic completion times - they were nowhere near close to even being started, so I wasn't worried about those, although it's nice to have warning before a task is unassigned sometimes, in case it actually [I]has[/I] been started, say. I do like to complete double-check tasks occasionally... to do my bit in making certain that the list of Mersenne numbers is reliable and to clear the back-log, even if I get no fame from it - it's a good community service![/QUOTE]

You can add UnreserveDays= to your prime.txt. Prime95 will then only unreserve assignments if worktodo.txt exceeds that number of days.

Aah, thanks. What is the default value if "UnreserveDays=" isn't specified? It only unreserved them when I put the Double Check tests that hadn't started at the end of the work to-do list - there was also an LL test that was partially complete; originally that one was at the end of the list instead, but wasn't unreserved (thankfully!). Only after rearranging the list in order to complete it more quickly (basically, right after the DC test that was in progress) did it unreserve those two tests.