![]() |
[QUOTE=James Heinrich;534777] Should it not do this immediately upon sucking in new work via [i]worktodo.add[/i] ?[/QUOTE]
I've changed this for the next build -- whenever that is. |
[QUOTE=kriesel;534689]Please fix all 9 identified issues.
System condor, dual Xeon X5650, Windows 7, prime95 v29.8b6 PrimeNet connected, set to do [B]PRPDC[/B] on all four 3-core workers worktodo.txt: [Worker #1] [B]PRPDC[/B]=(aid redacted),1,2,81912167,-1,75,0,3,1 (worktodo entry is correct) prime95 status output: [Worker thread #1] M81912167,[B]PRP[/B],Sat Feb 08 15:20 2020 (prime95 status output is incorrect, 1) prime.log on the client: [Mon Jan 06 23:30:08 2020 - ver 29.8] Getting assignment from server PrimeNet success code with additional info: Server assigned [B]PRP[/B] work. Got assignment (aid): [B]PRP[/B] M81912167 (prime95 logging is incorrect twice, 2 & 3) Prime95 worker window title says [B]PRP[/B] not PRP DC (prime95 window title is inaccurate, 4) [URL]https://www.mersenne.org/report_exponent/?exp_lo=81912167&full=1[/URL] claims it was assigned to me as a first test [B]PRP[/B], not "PRPDC", although [B]there is already a first test PRP result reported by another user on 2018-11-05[/B] (PrimeNet exponent status lookup is incorrect and inconsistent, 5) [URL]https://www.mersenne.org/workload/[/URL] claims 819121677 is a first test [B]PRP, Cat 0[/B], expiring in [B]23[/B] days, with 25 days left to go. It's actually a [B]PRP DC, Cat 4[/B], which should have up to [B]360[/B] days allowed for ETA before expiration. (workload listing is incorrect 3 ways, 6, 7, 8) Double checking such a large exponent should be, and should be indicated as, a cat 4 exponent allowed up to 360 days to complete: [URL]https://www.mersenne.org/thresholds/[/URL] (likely outcome of mistreating a cat 4 PRPDC as a cat 0 PRP is incorrect [B]too-early expiration of the assignment[/B], 9) As a workaround to avoid early expiration, I've reconfigured this instance from 4 workers to 2 workers to reduce latency, and manually edited the worktodo to queue up the falsely-claimed cat0 PRPs on this system (81912167 PRPDC and 81889037 PRPDC) as first assignment in each remaining worker. See also [URL]https://www.mersenne.org/report_exponent/?exp_lo=81889037&full=1[/URL], which was earlier reported as showing this problem also. See [URL]https://www.mersenneforum.org/showthread.php?t=25066[/URL] and an additional report linked there made months earlier. Please fix the client software and server software to correctly handle PRPDC in the general case. Soon would be good. This system's prime95 will be doing nothing other than PRPDC for a while. To produce meaningful PRP error rate statistics, such as patrik graphs annually, GIMPS needs many many more than the ~1584 PRPDC results it has so far at p>75M. [URL="https://www.mersenneforum.org/showthread.php?t=10377&highlight=error+rate&page=10"]https://www.mersenneforum.org/showthread.php?t=10377&page=10[/URL] (end)[/QUOTE] #1,#3 fixed next build #2 fixed on server #4 wont be fixed #5 on require server web page work. James or Aaron might work on it as time permits. |
1 Attachment(s)
[QUOTE=S485122;523925]Trying to run the win64 version I get the following error message : "prime95,exe - Application error / The application was unable to start correctly (0xc000007b). Click OK to close the application." It seems the file libhwloc-15.dll is the culprit : using the version from 29.8b3 does not give the problem. (Could it be that the dll is the 32 bits version ? it is smaller than the version shipped with 29.8b3...)
Then a cosmetic correction is also needed : in the Windows 64 version, the File Version and the Product version are stuck at 28.8.1.0 and 29.8.0.0. Jacob[/QUOTE] [B]SAME ISSUE![/B] Same attachment. CPU: Ryzen 1600@2600 MSI B450 Tomahawk Max 16GB@3200 RAM |
I stumbled upon some code I'm confused by.
in ecm.c [CODE] /* When E >= 2, we can do prime pairing and each loop iteration */ /* handles the range m-D to m+D. When E = 1, each iteration handles */ /* the range m-D to m. */ ... bitclr (pm1data.bitarray, bitcvt (m - i, &pm1data)); if (pm1data.E >= 2) bitclr (pm1data.bitarray, bitcvt (m + i, &pm1data)); ... [/CODE] but when it comes times to print status [CODE] if (pm1data.E <= 2) sprintf (buf+strlen(buf), ", B2=%.0f", (double) C); else sprintf (buf+strlen(buf), ", B2=%.0f, E=%lu", (double) C, pm1data.E); ... if (pm1data.E > 2) sprintf (JSONbuf+strlen(JSONbuf), ", \"brent-suyama\":%lu", pm1data.E); [/CODE] When pm1data.E = 2 shouldn't E=2 be printed? Related I see some results in [URL="https://www.mersenne.ca/brent-suyama.php?s=e&o=a"]"Mersenne numbers with P-1 factors found via Brent-Suyama extension"[/URL] don't list e, is it possible this is why? |
There is no reason ever to run with E=1. E=2 is always cheaper than E=1. And E=2 doesn't count as B-S extension, since it doesn't introduce any new primes in stage 2.
|
[QUOTE=zzzzzzzzzz;535114][B]SAME ISSUE![/B]
Same attachment. CPU: Ryzen 1600@2600 MSI B450 Tomahawk Max 16GB@3200 RAM[/QUOTE]George has addressed the problem the same day in August 2019 :[QUOTE=Prime95;523962]My bad, included the 32-bit hwloc-15.dll. I repaired and uploaded the win64 zip file[/QUOTE]The current downloads do not have the problem. Go to "official" download page [url=https://www.mersenne.org/download/]https://www.mersenne.org/download/[/url] (you can also download the program directly from one of the mirrors [url=ftp://mersenne.org/gimps/]ftp://mersenne.org/gimps/[/url], mersenne.org, [url=https://mersenneforum.org/gimps/]https://mersenneforum.org/gimps/[/url] or [url=https://download.mersenne.ca/gimps]https://download.mersenne.ca/gimps[/url]). Jacob |
[QUOTE=Prime95;533197]There is no such tool. Yes, I'd be willing to add useful code.[/QUOTE]
[URL="https://github.com/sethtroisi/prime95/pull/1/files"]I got the code finished[/URL]. I'll still need to cleanup some of the comments and match the style of other code in prime95. Using this worktodo.txt stopped at the points indicated [CODE] [Worker #1] #Pminus1=N/A,1,2,13007,-1,20000000,0 # Stopped at ~7% stage 1 (stage 0, squaring small primes) #Pminus1=N/A,1,2,12011,-1,20000000,0 # Stopped at ~71% stage 1 #Pminus1=N/A,1,2,13009,-1,30000,300000000 # Stopped at ~9% stage 2 #Pminus1=N/A,1,2,13217,-1,200000,0 # Finished stage 1, stage 2 #ECM2=1,2,13033,-1,1000000,0,7 # Stopped at ~33% stage 1 #ECM2=1,2,13037,-1,10000,100000000,7 # Stopped at ~27% stage 2 (curve 2) #PRP=1,2,500009,-1 # Stopped at ~3.3% #TEST=500029,40,1 # Stopped at ~9% #PRP=4847,2,3321063,1 # Seventeen or bust like number stopped at ~10.8% #PRP=6,10,71299,7 # Near Repunit prime stopped at 89% [/CODE] I generated this status/backup/restore status [CODE] Status of files in 'testing'. Backup e0013033 | ECM | Curve 1 | Stage 1 (33.2%). Backup e0013033.bu | ECM | Curve 1 | Stage 1 (33.2%). Backup e0013037 | ECM | Curve 2 | Stage 2 (27.9%). Backup e0013037.bu | ECM | Curve 2 | Stage 2 (27.9%). Backup m0012011 | P-1 | Stage 1 (71.9%) B1 @ 14376553. Backup m0012011.bu | P-1 | Stage 1 (71.9%) B1 @ 14376553. Backup m0013007 | P-1 | Stage 1 (8.4%) B1 <2436719. Backup m0013007.bu | P-1 | Stage 1 (8.4%) B1 <2436719. Backup m0013009 | P-1 | B1=30000 complete, Stage 2 (9.9%). Backup m0013009.bu | P-1 | B1=30000 complete, Stage 2 (9.9%). Backup m0013217 | P-1 | B1=200000,B2=20000000,E=12 complete. Backup m0013217.bu | P-1 | B1=200000,B2=20000000,E=12 complete. Backup p0500009 | PRP | Iteration 16631/500009 [3.33%]. Backup p0500009.bu | PRP | Iteration 16631/500009 [3.33%]. Backup p0500029 | LL | Iteration 45144/500029 [9.03%]. Backup p0500029.bu | LL | Iteration 45144/500029 [9.03%]. Backup p4847_3321063 | PRP | Iteration 360034/3321063 [10.84%]. Backup p4847_3321063.bu | PRP | Iteration 360034/3321063 [10.84%]. Backup p6_71299_7 | PRP | Iteration 212862/71299 [89.87%]. Backup p6_71299_7.bu | PRP | Iteration 212862/71299 [89.87%]. [/CODE] Does is look useful? Is there additional status that I could print (error count, file modified date...) |
P-1 Save Files Incompatible...Stage 1 only
I Upgraded 4 CPUs from 29.4 to 29.8.
All had at least 1 core running P-1 Stage 1 at the time of the upgrade. 1 of the 4 got the following error on each core running stage 1: [CODE][Jan 16 13:35] Worker starting [Jan 16 13:35] Setting affinity to run worker on CPU core #1 [Jan 16 13:35] P-1 on M41872769 with B1=750000, B2=15000000 [Jan 16 13:35] Chance of finding a factor is an estimated 3.52% [Jan 16 13:35] Using AVX FFT length 2304K, Pass1=384, Pass2=6K, clm=1 [Jan 16 13:35] P-1 save file incompatible with this program version. Restarting stage 1 from the beginning. [Jan 16 13:35] Error reading intermediate file: m8G72769 [Jan 16 13:35] Renaming m8G72769 to m8G72769.bad1 [Jan 16 13:35] All intermediate files bad. Temporarily abandoning work unit. [Jan 16 13:35] P-1 on M41870533 with B1=750000, B2=15000000 [Jan 16 13:35] Chance of finding a factor is an estimated 3.52% [Jan 16 13:35] Using AVX FFT length 2304K, Pass1=384, Pass2=6K, clm=1[/CODE] It was an i5-3570. However there was a second identical CPU that did NOT get this error. Both were previously on v29.4.5.0. Created 11/11/2017 7:38PM Thanks |
[QUOTE=SethTro;535206]
Does is look useful? Is there additional status that I could print (error count, file modified date...)[/QUOTE] What does the public think? Tweak it until you're happy and I'll look at the code when I get back from vacation -- could be April though. In SFO airport right now. |
[QUOTE=petrw1;535263]
It was an i5-3570. However there was a second identical CPU that did NOT get this error. Both were previously on v29.4.5.0. Created 11/11/2017 7:38PM [/QUOTE] There was a warning buried in this thread or maybe the whatsnew.txt file or both that P-1 stage 1 save files changed. Hmmm, whatsnew has it listed as an issue upgrading *to* 29.4. The relevant code was added April 1, 2018. |
[QUOTE=Prime95;535286]There was a warning buried in this thread or maybe the whatsnew.txt file or both that P-1 stage 1 save files changed.
Hmmm, whatsnew has it listed as an issue upgrading *to* 29.4. The relevant code was added April 1, 2018.[/QUOTE] As I posted sometime on this forum: got similar error on PRP tasks where both worker have same exponent . |
| All times are UTC. The time now is 22:08. |
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.