OK, but this small factor was not in the database a week ago apparently. So, can we figure out which other exponents have factors that were known to exist some time ago but are not in the database now?

[QUOTE=tha;525258]OK, but this small factor was not in the database a week ago apparently. So, can we figure out which other exponents have factors that were known to exist some time ago but are not in the database now?[/QUOTE]What makes you think it wasn't in the database a week ago?

Thanks to user TJAOI, we can be virtually certain that there are no undiscovered factors smaller than 67 bits for any exponent up to 1 billion.

And tiny exponents like [M]M14419[/M] have had enough ECM done on them by now to be nearly certain that they have no undiscovered factors smaller than about 100 bits.

All small factors are already in the database. The only question is why the History section in the report logs rediscoveries of already known factors.

[URL]https://www.mersenne.org/report_exponent/?exp_lo=332199017&full=1[/URL]


cheater :-) or double upload by mistake

[QUOTE=Lorenzo;527683][URL]https://www.mersenne.org/report_exponent/?exp_lo=332199017&full=1[/URL]


cheater :-) or double upload by mistake[/QUOTE]

Or self-verify not by mistake.

LaurV doesn't follow the conventional wisdom about self-verifying exponents.

[QUOTE=Lorenzo;527683][URL]https://www.mersenne.org/report_exponent/?exp_lo=332199017&full=1[/URL]
cheater :-) or double upload by mistake[/QUOTE]
Prove me wrong, please!** (Seriously!)
Hehe.

It can't be mistake, because for the server to accept it as a DC, at least one or two of the (user, computer, program, FFT size, shift, whatever) must be different. So, it will require manual edit of the report file, which can't be done "by mistake" in such a way to match checksums, whatever.

So, it is either intentional cheating, or we did the DC for real. :razz:

-------------
** as I said repeatedly in the past, the fastest and most efficient way (unless you have ECC memory) is to run two tests in parallel in two cards, with different shifts, and compare residues at each checkpoint. That is why I was so concerned and argued a lot about the names of the checkpoint files (they must include the iteration and the residue in the name, because the interior of the file is always different due to different shift, and you can't compare them in binary). If there is a mismatch, roll back both instances to the last checkpoint. This beats ANY OTHER method, because you don't waste any time (beside of the last half hour between checkpoints, assuming your scripts are keeping the cards running at the same speed). Running a single LL to the end and finding two years later that the residue was wrong means the whole time and resources (and electricity money) for the whole LL test LOST/WASTED..

Even ECC memory is not so "fool proof" like my way, and I don't want to know what "conventional wisdom" is in this case. My scripts will check the progress and if one card is faster than the other by more than three checkpoints, the tests are stopped and the cards are switched (it is as simple as using -D0 and -D1 when you launch cL, all the files and shifts stay the same as they were, in the same folders). This happens occasionally due to the fact that I am using the computer for other things too, like "watching youtube funny cats and dogs"[SUP](TM)[/SUP] :razz: and other similar "heavy stuff" when one card (the one driving the monitor and all the physics) is used and the other not. Interestingly enough, when the computer is not used for "heavy things", the card driving the monitors is always faster, for both mfaktc and cL, regardless of which card I connect the monitors. I assume (this was also discussed in the past many times, and it was also reported by other users here on the forum) that the card not driving the monitors enters some "low power" or "sleep" modes for microseconds between iterations, while the card most stressed has no time for that and keeps crunching.

Anyhow, for the current test, we get the switching event 6 times, and rollback event one time around iteration 280M (there was a storm, and we suspect power issues) which says that this pair of cards is quite reliable.

But if anybody still wants to prove me wrong, be my guest! :razz:

(this is not a request, is sarcasm, a TC is not needed, or it has a very low priority, I guarantee this result and there are other tasks more in need of crunching power, if you have for spare, so pick your own exponent, and your preferred work type!)

[QUOTE=LaurV;527710]** as I said repeatedly in the past, the fastest and most efficient way (unless you have ECC memory) ...[/QUOTE]Yes, ECC is awesome. But now we also have PRP with periodic checkpoints to recover from bad iterations.

The problem here, isn't that [i]you[/i] did two tests (that is great), instead it is that some people are not so open and honest about things. If we go around encouraging everyone to self verify then things can get out of hand.

ETA: Just look at what happens when Boeing are allowed to self verify the 737 MAX 8 planes.

[QUOTE=retina;527711]Yes, ECC is awesome. But now we also have PRP with periodic checkpoints to recover from bad iterations.

The problem here, isn't that [i]you[/i] did two tests (that is great), instead it is that some people are not so open and honest about things. If we go around encouraging everyone to self verify then things can get out of hand.
...[/QUOTE]

Yeah... ^^^ that.

While I may trust LaurV to properly and honestly DC his own work, I don't trust just anyone to do the same. That's why I encourage (and participate in) doing independent triple-checks of such things. Even the ones that LaurV continues to turn in. Because we may trust him now, but in the future, people who don't know him will look back and say "why?" :smile:

We are totally ok with that. Your clocks :razz:

PrimeNet has adopted the concept of LaurV's idea. Interim residues are sent in and stored. Therefore when a DC happens if it comes in with a mismatch a tiebreaker can be started and who is in the right can be found well be the test is finished.

I think Primenet (read: [URL="https://www.mersenne.org/"]https://www.mersenne.org/[/URL]) is down...