Trippple Checks

[kladner]

Maybe someone wrote a paper about those B1/B2 values.

[axn]

Originally Posted by Madpoo

It's kind of weird that someone chose that one exponent to do so much P-1 work, but whatever makes people happy.

Not "so much" work. That work can be incrementally performed. At the cost of 1 P-1 with the max B1/B2 (plus a little extra), all of those intermediate statuses can be generated. Try it. Just setup a large worktodo with all those B1/B2 combinations in sequence.

[petrw1]

Originally Posted by Madpoo

Seems kind of like someone automated some work and changing the b1/b2 values in a strangely progressive fashion.

The large # of LL work by one user/group also looks like some automated thing to distribute work to a computer lab or something went wrong and the same exponent was sent out to a bunch of machines at once by mistake.

It's kind of weird that someone chose that one exponent to do so much P-1 work, but whatever makes people happy.

Yes I recall noticing Rob Dee doing a bit of that back them.... I too though it was odd.

[S485122]

Originally Posted by petrw1

Yes I recall noticing Rob Dee doing a bit of that back them.... I too though it was odd.

But it reaps a lot of cheaply got credit.

Jacob

[Madpoo]

Is there ever a situation where the shift-count should be zero?

It may just be a data error where the shift counts weren't being recorded in the database, but in my scouring of the data I find that there are a few (as in 6720) exponents that have been double-checked, but the shift counts for both runs are listed as 0. Did Primenet not log the shift counts in early versions of the server (which seems like an odd choice, since making sure they're different is kind of a big deal in terms of verifying unique runs)?

A good chunk of those are small, as in 6716 of them are < 10M. But then you get some like:
M22849927

The one result from 2010-03-13 has the unexpurgated log entry:
M( 22849927 )C, 0x59e921c25b139e51, n = 2097152, MacLucasFFTW v8.1 Ballester

Is the "n = " line the shift count? Because that same n= value shows up in other logs for other exponents/apps. I'm not familiar with how the *Lucas clients report their work (CUDALucas/MacLucas, etc).

As in, exponent 27502927 has the log entry: "M( 27502927 )C, 0x3f4194821c19028c, n = 2097152, CUDALucas v1.0 " (and that's another exponent where neither LL run has a non-zero shift count).

One suspicious looking one is M35000741 which has it's two results coming in 12 minutes apart. The log message of the first one isn't stored, and the 2nd one has:
"M( 35000741 )C, 0x8a9ff8fb5658d4f4, n = 2097152, MacLucasFFTW v8.1 Ballester"

If the shift count is just missing for some of those and it's actually present in the log we have stored, we could maybe parse those out. For a good chunk of those, one or the other of the original log message isn't available anyway, even in the new v4 logs we've pulled in.

In that sense, it's perhaps a little disconcerting that we have no way of knowing if the shift counts were different for the double-check. Isn't it? Or is that my hyper-paranoia about triple-checking weird things kicking in again? LOL

I may do a sampling of a few of these and re-check them. Since they are smaller it wouldn't be much effort. 369 of them are sub-1M exponents... I didn't do them before when I did triple-checks on all <1M exponents that hadn't already been triple-checked, for the simple reason that those 369 *had* been triple+ checked already. All with shift-counts of zero recorded. 619561 has 7 results, all with 0 for shift count.

[Prime95]

Early versions of prime95 did not support shift counts. MacLucasFFTW did not. CudaLucas until recently did not. I don't think Ernst's program supports them either.

In all those cases the shift count is zero.

The server declares a double check valid if the LL test was run by two different programs or the same program with a different shift count.

[Madpoo]

Originally Posted by Prime95

Early versions of prime95 did not support shift counts. MacLucasFFTW did not. CudaLucas until recently did not. I don't think Ernst's program supports them either.

In all those cases the shift count is zero.

The server declares a double check valid if the LL test was run by two different programs or the same program with a different shift count.

Well, it's a good reason for why they're zero anyway.

[Madpoo]

Originally Posted by Prime95

Early versions of prime95 did not support shift counts. MacLucasFFTW did not. CudaLucas until recently did not. I don't think Ernst's program supports them either.

In all those cases the shift count is zero.

The server declares a double check valid if the LL test was run by two different programs or the same program with a different shift count.

Is there some version of Prime95 (either Windows or Linux) where it started using shift counts?

I see zero shift counts for some versions that I'm pretty sure should have had it like Prime95 v23.

Was it maybe added somewhere around v17? I should probably just check the release notes... LOL

[Prime95]

v17 introduced shift counts (and the infamous shift count bug)

if one continued an LL test in v17 or later that started in v16, then the final result would be reported by v17+ and have a shift count of zero. I can't think of any other reason a v23 client would report a zero shift count (except for the 1 in exponent chance that the randomly generated shift count was zero).

[Madpoo]

Originally Posted by Prime95

v17 introduced shift counts (and the infamous shift count bug)

if one continued an LL test in v17 or later that started in v16, then the final result would be reported by v17+ and have a shift count of zero. I can't think of any other reason a v23 client would report a zero shift count (except for the 1 in exponent chance that the randomly generated shift count was zero).

Okay... I narrowed it down (for now...very ad-hoc query) to a group of 44 anomalous results where both apps had a shift-count of zero, but one or the other of them *should* have had a non-zero shift (prime95 version 17+).

Most are Windows clients, but I went under the assumption that Linux versions of Prime95 17+ would have had this as well.

For example: M3091577
The 3 results come from these 3 clients:
Windows,Prime95,v14
Mac,John Sweeney,vLL1.0b1
Linux,Prime95,v19

Another example: M7835651
The 2 results come from:
Mlucas,Ernst Mayer,v2.5 and later
Windows,Prime95,v19,NT service

I'm happy to just run all 44 of those for now. Shouldn't take too long (they're all below 10M).

EDIT: Maybe these were all just people starting on v16 or below and upgraded to one of those newer versions before it finished... whatever. :)

[Madpoo]

Originally Posted by Madpoo

I'm happy to just run all 44 of those for now. Shouldn't take too long (they're all below 10M).

I also ran checks on all <1M exponents that only had shift-count=zero results (369 of them). Everything matched of course, as expected.

Honestly I'd be shocked as everything if one of these triple-checks didn't match. But then there are people searching for ET as well and I'd be shocked if they found anything either, but I guess it's fun they're trying.