[QUOTE=Prime95;483459]That's a bug in the linux menus. Change your work preference to 153 and all should be good.[/QUOTE]

I don't see 153 anywhere in that list. :smile:

[QUOTE=chalsall;483464]I don't see 153 anywhere in that list. :smile:[/QUOTE]
[CODE]153 - 100M digit number to PRP test (Gerbicz)[/CODE]
I am probably missing the joke.

[QUOTE=kladner;483493][CODE]153 - 100M digit number to PRP test (Gerbicz)[/CODE]
I am probably missing the joke.[/QUOTE]

No joke, just your garden-variety reading comprehension #fail.

Hi,

for me the 153 seem to work! Thanks for that! :smile:

On one of my computers, a few of the benchmarks show INF ms. Is this normal?

[QUOTE=ixfd64;485170]On one of my computers, a few of the benchmarks show INF ms. Is this normal?[/QUOTE]

No. It's a complete mystery -- at least you are not alone. You can commiserate with xyzzy.

[QUOTE=Prime95;485192]No. It's a complete mystery -- at least you are not alone. You can commiserate with xyzzy.[/QUOTE]

Thanks for the response. If the benchmarks show invalid values, am I more likely to get incorrect results?

For the record, this computer did recently find a P-1 factor, but this probably isn't too useful because the minimum required B1 was less than 100,000. At any rate, I'm also running two double checks, although they're going to take a while to complete as the computer has a relatively old Q9400 processor.

[QUOTE=ixfd64;485193]Thanks for the response. If the benchmarks show invalid values, am I more likely to get incorrect results?[/QUOTE]

No, the bug seems to be completely related to timing an interval. Probably the Windows HighResTimer calls.

The software was recently modified to send interim residues at various milestones: 500K, 5M, 10M, etc. There seems to be a bug with that functionality.

I am doing PRP-CF for exponents in the 8.0M range, and these were manually added to the worktodo file with assignment IDs set to "N/A".

Here are some selected lines from prime.log:

[CODE]
[Mon Apr 23 15:01:45 2018 - ver 29.4]
Sending interim residue 500001 for M8047909
[Mon Apr 23 15:52:17 2018 - ver 29.4]
Sending interim residue 5000001 for M8047909
Sending result to server: UID: GP2/c5.xlarge, M8047909/known_factors is not prime. Type-5 RES64: ...

[Mon Apr 23 17:52:21 2018 - ver 29.4]
Sending interim residue 500001 for M8048069
[B]Sending interim residue 5000001 [COLOR="Red"]for M8050103[/COLOR][/B]
Sending result to server: UID: GP2/c5.xlarge, M8048069/known_factors is not prime. Type-5 RES64: ...

[Mon Apr 23 19:52:50 2018 - ver 29.4]
Sending interim residue 500001 for M8050103
Sending interim residue 5000001 for M8050103
Sending result to server: UID: GP2/c5.xlarge, M8050103/known_factors is not prime. Type-5 RES64: ...
[/CODE]

And lines from results.txt:

[CODE]
[Mon Apr 23 15:52:17 2018]
{"status":"C", "exponent":8047909, ...}
[Mon Apr 23 17:52:20 2018]
{"status":"C", "exponent":8048069, ...}
[Mon Apr 23 19:52:50 2018]
{"status":"C", "exponent":8050103, ...}
[/CODE]

As we can see, the interim residues usually don't get sent right away, instead they sit in prime.spl and get sent later. In particular the 5M (= 5000001) interim residues are only getting sent when the exponent itself completes. This delay may be intentional, but it might be related to the following bug:

At 17:52:21, when it says it's sending the 5M (= 5000001) interim residue for M8050103, that clearly ought to be the 5M interim residue for M8048069 instead. The exponent M8050103 had only just started at that point, and indeed that's when I noticed it and wondered how the program could send an interim residue it hadn't even calculated yet.

[B]At the very least, the log file recorded the wrong exponent; however it seems quite plausible that the interim residue sent to the server was also associated with the wrong exponent.[/B]

The problem might also be associated with the fact that these 8.0M exponents had no assignment IDs. However, there is some additional weirdness regarding that latter point, see the next message.

Earlier I was doing PRP-CF for exponents in the 7.7M range. Unlike the 8.0M exponents, these were assigned automatically and had assignment IDs.

There is the minor oddity that sometimes the 5M (= 5000001) interim residue is logged with the exponent itself, and other times with the assignment id. I wonder if there's any reason for the inconsistency, or if that's related to the bug in the previous message.

[CODE]
[Sun Apr 22 23:57:34 2018 - ver 29.4]
Sending interim residue 500001 for M7704127
Sending interim residue 5000001 for [B][COLOR="Red"]assignment 413EFCC136707FC6A40991B97F396D8E[/COLOR][/B]
Sending result to server: UID: GP2/c5.xlarge, M7704127/1886784765808106376319 is not prime. Type-5 RES64: ..., AID: 413EFCC136707FC6A40991B97F396D8E

[Mon Apr 23 01:36:56 2018 - ver 29.4]
Sending interim residue 500001 for M7704623
Sending interim residue 5000001 for M7704623
Sending result to server: UID: GP2/c5.xlarge, M7704623/1719170205596471 is not prime. Type-5 RES64: ..., AID: 3FF8382668A26ACECF68585E300F7FCC

[Mon Apr 23 03:01:45 2018 - ver 29.4]
Sending interim residue 500001 for M7705003
Sending interim residue 5000001 for M7705003

[Mon Apr 23 03:16:36 2018 - ver 29.4]
Sending result to server: UID: GP2/c5.xlarge, M7705003/63196434607/407313780520639 is not prime. Type-5 RES64: ..., AID: 2DF0093B273EF03203CE51CF65CF23BC

[Mon Apr 23 04:56:17 2018 - ver 29.4]
Sending interim residue 500001 for M7705219
Sending interim residue 5000001 for [B][COLOR="Red"]assignment 21EF1DBA9D2319BE1EA7CF7074398CFE[/COLOR][/B]
Sending result to server: UID: GP2/c5.xlarge, M7705219/3837199063/373810994567 is not prime. Type-5 RES64: ..., AID: 21EF1DBA9D2319BE1EA7CF7074398CFE
[/CODE]

As mentioned earlier, the interim residues don't get sent right away, instead they sit in a prime.spl file and only get sent at a later point. In particular the 5M (= 5000001) interim residues are usually only getting sent when the exponent itself completes.

I wonder if all the 5M (= 5000001) interim residues were received correctly by the server, regardless of whether they were logged by exponent or by assignment ID.

Jacobi check and battery
 

Hello, i noticed something about the battery mode - [I]program set to not run while on battery[/I]:
if the laptop is unplugged, it will still run the Jacobi check [I](and slower, since it is saving power)[/I], then stops as soon as it "starts" the exponent.
(Doesn't matter if prime95 runs as a startup, or resumes after a pause.)