I had this last on 30.3

[CODE]
[Worker #4 Feb 6 18:35] M104099027 stage 2 is 47.60% complete. Time: 936.607 sec.
[Worker #4 Feb 6 18:48] Worker stopped.
[/CODE]

Then after updating to 30.4 build 8

[CODE]
[Worker #4 Feb 6 19:50] Waiting 15 seconds to stagger worker starts.
[Worker #4 Feb 6 19:50] Worker starting
[Worker #4 Feb 6 19:50] Setting affinity to run worker on CPU core #4
[Worker #4 Feb 6 19:50] Optimal P-1 factoring of M104099027 using up to 24576MB of memory.
[Worker #4 Feb 6 19:50] Assuming no factors below 2^76 and 2 primality tests saved if a factor is found.
[Worker #4 Feb 6 19:50] Optimal bounds are B1=834000, B2=41687000
[Worker #4 Feb 6 19:50] Chance of finding a factor is an estimated 4.43%
[Worker #4 Feb 6 19:50]
[Worker #4 Feb 6 19:50] Using FMA3 FFT length 5600K, Pass1=448, Pass2=12800, clm=4
[Worker #4 Feb 6 19:50] Cannot continue stage 2 from old P-1 save file. Restarting stage 2 from the beginning.
[Worker #4 Feb 6 19:50] M104099027 stage 1 is 0.00% complete.

[Worker #4 Feb 6 21:31] Waiting 15 seconds to stagger worker starts.
[Worker #4 Feb 6 21:32] Worker starting
[Worker #4 Feb 6 21:32] Setting affinity to run worker on CPU core #4
[Worker #4 Feb 6 21:32] Optimal P-1 factoring of M104099027 using up to 24576MB of memory.
[Worker #4 Feb 6 21:32] Assuming no factors below 2^76 and 2 primality tests saved if a factor is found.
[Worker #4 Feb 6 21:32] Optimal bounds are B1=834000, B2=41687000
[Worker #4 Feb 6 21:32] Chance of finding a factor is an estimated 4.43%
[Worker #4 Feb 6 21:32]
[Worker #4 Feb 6 21:32] Using FMA3 FFT length 5600K, Pass1=448, Pass2=12800, clm=4
[Worker #4 Feb 6 21:32] Cannot continue stage 2 from old P-1 save file. Restarting stage 2 from the beginning.
[Worker #4 Feb 6 21:32] M104099027 stage 1 is 0.00% complete.
[Worker #4 Feb 6 21:41] M104099027 stage 1 is 92.24% complete. Time: 547.831 sec.
[Worker #4 Feb 6 21:43] Worker stopped.
[Worker #4 Feb 6 21:45] Waiting 15 seconds to stagger worker starts.
[Worker #4 Feb 6 21:45] Worker starting
[Worker #4 Feb 6 21:45] Setting affinity to run worker on CPU core #4
[Worker #4 Feb 6 21:45] Optimal P-1 factoring of M104099027 using up to 24576MB of memory.
[Worker #4 Feb 6 21:45] Assuming no factors below 2^76 and 2 primality tests saved if a factor is found.
[Worker #4 Feb 6 21:45] Optimal bounds are B1=834000, B2=41687000
[Worker #4 Feb 6 21:45] Chance of finding a factor is an estimated 4.43%
[Worker #4 Feb 6 21:45]
[Worker #4 Feb 6 21:45] Using FMA3 FFT length 5600K, Pass1=448, Pass2=12800, clm=4
[Worker #4 Feb 6 21:45] M104099027 stage 1 is 92.38% complete.
[Worker #4 Feb 6 21:54] M104099027 stage 1 is 92.93% complete. Time: 539.559 sec.
[Worker #4 Feb 6 21:56] Worker stopped.
[/CODE]

Is this normal? It says stage 2 has to be restarted, but then stage 1 is at 0%, then next time I start Stage one jumps to 92%.

[QUOTE=ZFR;571036]Is this normal? It says stage 2 has to be restarted, but then stage 1 is at 0%, then next time I start Stage one jumps to 92%.[/QUOTE]That seems about right. v30.4 has new optimizations that allow it to select higher bounds for P-1. So it selected a higher B1 and a higher B2 than before. The partially-completed stage2 has to be thrown out because of the new starting point (B1), but stage1 can be continued to the new higher B1 from the point it previously stopped, so your entire stage1 was useful and now it's doing 8% more, and will redo stage2 entirely.
The 0.00% is perhaps confusing, but I think just a display artifact. I would presume that it output that when it restarted prior to validating the savefile as valid for resuming stage1.

[QUOTE=James Heinrich;571042]That seems about right. [/QUOTE]

Ah. Thanks for explaining. The 0% threw me off.

Those new bounds are nice. B2 almost doubled, and chance of finding a factor increased by 30%.

I have another question. On 30.4 I get this on resume.

[CODE]
[Worker #4 Feb 7 07:42] Stage 2 init complete. 5489 transforms. Time: 198.902 sec.
[Worker #4 Feb 7 07:42] M104099027 stage 2 is 15.94% complete.

[/CODE]
It took just over 3 minutes for Stage 2 to resume.

In 30.3 I used to get this every time I resume

[CODE]
[Worker #4 Feb 6 16:41] Using 22337MB of memory. Processing 480 relative primes (0 of 480 already processed).
[Worker #4 Feb 6 17:12] M104099027 stage 2 is 43.43% complete.
[/CODE]

Taking roughly 30 minutes, every time I restart mprime.

Is the "stage 2 init" same as "Processing relative primes" from the previous version. If so, did its time drop from 30 mins to 3 mins?

[QUOTE=ZFR;571062]On 30.4 I get ... just over 3 minutes for Stage 2 to resume.
In 30.3 I used to get ... roughly 30 minutes, every time I restart mprime.[/quote]


[QUOTE=ZFR;571062]Is the "stage 2 init" same as "Processing relative primes" from the previous version. If so, did its time drop from 30 mins to 3 mins? [/QUOTE]Yes. Your numbers are proportionately the same as my testing, it used to take me 10 mins to resume stage2 and now it takes 1. The stage2 implementation is quite [url=https://www.mersenneforum.org/showpost.php?p=567795&postcount=297]different[/url] from earlier versions, one side effect of which is that resuming stage2 is now about 10x faster than before. As described by George:[QUOTE=Prime95;567707]Relative primes are no longer processed in passes. They are all done at once as prime95 steps from B1 to B2 in steps of size D.[/QUOTE]

[QUOTE=James Heinrich;571081]Yes. Your numbers are proportionately the same as my testing, it used to take me 10 mins to resume stage2 and now it takes 1. The stage2 implementation is quite [URL="https://www.mersenneforum.org/showpost.php?p=567795&postcount=297"]different[/URL] from earlier versions, one side effect of which is that resuming stage2 is now about 10x faster than before. [/QUOTE]

That's amazing. Those 30 mins on every resume were a huge time hog in my case, since I had to stop/resume Stage 2 fairly often during the day when I needed the memory for other programs. If we take that saved time into consideration, and the increased probabilities from higher bounds, this new version is about 60% more effiecient for me. I love it.

The new stage 2 uses E=2 by default (i.e. only prime pairing, no Brent-Suyama extension). If the old stage 2 was using E=12 it will take 6 times longer to initialize compared to E=2.
Apart from that, I don't know why it'd be faster by 10x, especially since the new version typically uses more temporaries.

I am having a reproducible issue with mprime 30.4 build 7.

The issue:
At start, F20 declares B1=44000000 and B2=TBD
As soon as I complete (100%) stage 1 of curve 1 (of 5) of F20, mprime aborts and exits.

It looks like 14000MB are not enough for the calculated stage2 / B2 value, but instead of rolling back to a smaller bound, the program stops.

The other worker is running PRP-DC-CF (double check on composite PRP), and certifications from time to time.
I have plenty of disk space.

Before trying to increase the memory for the ECM-F worker, I wanted to know if this issue could hide a bug...

My rig: Intel 9800x with 32GB of RAM DDR4 quad-channel.

My worktodo:
[code]
PRPDC=[stuff deleted],1,2,10182587,-1,99,0,3,5,"59140465297,36146723563243273297"
PRPDC=[stuff deleted],1,2,10183231,-1,99,0,3,5,"1900508377009657"
PRPDC=[stuff deleted],1,2,10184123,-1,99,0,3,5,"515631552344276287"
PRPDC=[stuff deleted],1,2,10184491,-1,99,0,3,5,"36740546801323961"
PRPDC=[stuff deleted],1,2,10185011,-1,99,0,3,5,"20370023,16621937953"
PRPDC=[stuff deleted],1,2,10185521,-1,99,0,3,5,"561099980849,559876498184068369"
PRPDC=[stuff deleted],1,2,10185991,-1,99,0,3,5,"5622667033"
PRPDC=[stuff deleted],1,2,10186381,-1,99,0,3,5,"2424358679,317868117499487,4533577375432697"
PRPDC=[stuff deleted],1,2,10187239,-1,99,0,3,5,"101872391,156801609855427079"
PRPDC=[stuff deleted],1,2,10187923,-1,99,0,3,5,"4801303223903,54845732759627098727"
PRPDC=[stuff deleted],1,2,10188359,-1,99,0,3,5,"1711644313"
PRPDC=[stuff deleted],1,2,10189841,-1,99,0,3,5,"9863766089,11983253017"
PRPDC=[stuff deleted],1,2,10190603,-1,99,0,3,5,"1811073965161"
PRPDC=[stuff deleted],1,2,10190941,-1,99,0,3,5,"8138139153661057"
PRPDC=[stuff deleted],1,2,10192277,-1,99,0,3,5,"1610379767"

[Worker #2]
ECM2=N/A,1,2,1048576,1,44000000,4400000000,5
ECM2=[stuff deleted],1,2,16777216,1,3000000,300000000,5
ECM2=N/A,1,2,1048576,1,44000000,4400000000,5
[/code]

My Prime.txt:
[code]
V24OptionsConverted=1
V30OptionsConverted=1
WGUID_version=2
StressTester=0
UsePrimenet=1
DialUp=0
V5UserID=ET_
OutputIterations=100000
ResultsFileIterations=999999999
DiskWriteTime=30
NetworkRetryTime=2
NetworkRetryTime2=70
DaysOfWork=7
DaysBetweenCheckins=1
NumBackupFiles=3
SilentVictory=1
Priority=1
RunOnBattery=1
PRPGerbiczCompareIntervalAdj=1

[PrimeNet]
Debug=0
ProxyHost=
UploadRateLimit=0.25
UploadStartTime=00:00
UploadEndTime=24:00
DownloadDailyLimit=40

[Worker #1]
WorkPreference=161

[Worker #2]
WorkPreference=6
[/code]

My local.txt:
[code]
OldCpuSpeed=3800
NewCpuSpeedCount=0
NewCpuSpeed=0
RollingAverage=1000
RollingAverageIsFromV27=1
WorkerThreads=2
ComputerGUID=
ComputerID=9800
WorkerDiskSpace=6
ProofResiduesDir=
ProofArchiveDir=
Memory=14000 during 7:30-23:30 else 14000
MaxEmergencyMemory=1024
CertDailyCPULimit=15
CertWork=1
Pid=[...]
SrvrUID=[...]
SrvrComputerName=[...]
SrvrPO2=1
SrvrPO3=7
SrvrPO4=14000
SrvrPO5=14000
SrvrPO6=450
SrvrPO7=1410
SrvrPO8=1
SrvrPO9=2
SrvrP00=8
LastEndDatesSent=1612645886
CertDailyRemainingLastUpdate=1612645886
CertDailyMBRemaining=40
CertDailyCPURemaining=15
RollingHash=934404953
RollingStartTime=0
RollingCompleteTime=415141

[Worker #1]
SrvrPO1=161
CoresPerTest=3

[Worker #2]
SrvrPO1=6
CoresPerTest=4
[/code]

[QUOTE=ET_;571098]I am having a reproducible issue with mprime 30.4 build 7.

The issue:
At start, F20 declares B1=44000000 and B2=TBD
As soon as I complete (100%) stage 1 of curve 1 (of 5) of F20, mprime aborts and exits.[/QUOTE]

Good find. Fixed in build 9, which is now available.

[QUOTE=Prime95;571111]Good find. Fixed in build 9, which is now available.[/QUOTE]

Thank you George :smile:

(Re an F20 issue:)[QUOTE=Prime95;571111]Good find. Fixed in build 9, which is now available.[/QUOTE]Does the prime95 v30.4 b9/b8 differential only affect Fermats? What if anything in the b9 update relates to Mersennes?

Note, in prime95 v30.4b8, it's possible to enter in Options, Preferences, Days of work to queue up, 0.5 or presumably other decimal values. It quietly truncates that 0.5 to 0 days when OK is clicked, and no work is obtained for the workers after that. Other fields may have a similar behavior; I did not test for that much.
A quick try in v30.3b6 shows all preferences fields will allow decimal values to be entered. This allows nonsensical input such as 3.1 backup files.
For short assignments such as P-1 factoring on fast systems it could be useful to limit the number queued up by accepting and applying less than a whole day. There's nothing on the child window to advise users to enter integers or that real inputs will be truncated to integer.