[QUOTE=Madpoo;480248]I don't know why someone did a first PRP check and then someone doing a second one, when there was already a first-time LL done and waiting to be verified, but... whatever. :smile:[/QUOTE]

I don't know why someone did the first PRP test, but the double check is assigned automatically if you have the PRP-DC work type ([c]WorkPreference=151[/c]) set in prime.txt

The wavefront of PRP double checks is in the 76M range, so anything smaller will get automatically assigned right away.

PrimeNet Activity Summary 2018-03-01 23:00 UTC
 

And again:

[code] Exponent Range | Composite | Status Unproven | Assigned | Available |
Start Count P | F LL-D | LL LLERR NO-LL | ECM P-1 LL LL-D | ECM P-1 LL LL-D |
----------=-----=-- | -----=-----=-----=-----=----- | -----=-----=-----=----- | -----=-----=-----=----- |
8000000 62712 | 41151 21560 [color=red][b]1[/b][/color] | | 21560 |[/code]

Just for fun I did P-1 work on an exponent that apparently had no previous p-1 work being done on. A number of factors had been found during trial factoring in an early stage. The server does seem to ignore any P-1 work having been done and reported because no new factor was reported.

Can it be changed so that if any P-1 work (higher B1/B2 limits) are reported they are stored on the server?


[CODE]
[Work thread Mar 17 21:15] P-1 found a factor in stage #2, B1=400000, B2=8000000, E=6.
[Work thread Mar 17 21:15] M22351237 has a factor: 288476702225081262023002950746197048091558084285203081 (P-1, B1=400000, B2=8000000, E=6)
[Comm thread Mar 17 21:15] Sending result to server: UID: Tha/Riet-Ubuntu, M22351237 has a factor: 288476702225081262023002950746197048091558084285203081 (P-1, B1=400000, B2=8000000, E=6)

[Comm thread Mar 17 21:15] PrimeNet error 40: No assignment
[Comm thread Mar 17 21:15] Factoring result for M22351237 was not needed
[/CODE]

I thought P-1 bounds were recorded in the full history: [url]https://www.mersenne.org/report_exponent/?exp_lo=22351237&exp_hi=&full=1[/url]
but apparently not.

If you put the known factors in the worktodo.txt entry and then submit a no-factors-found result, do the bounds then get recorded in the history?

I downloaded the latest version of mprime to do that test. I used the same installation as on all previous versions of mprime on a Ubuntu-stable OS
This is what came back:

[CODE]
P5K:~/Mersenne$ ls -l
totaal 34120
lrwxrwxrwx 1 riet riet 16 mrt 19 09:32 libgmp.so -> libgmp.so.10.3.2
lrwxrwxrwx 1 riet riet 16 mrt 19 09:32 libgmp.so.10 -> libgmp.so.10.3.2
-rwxr-xr-x 1 riet riet 545695 feb 9 23:40 libgmp.so.10.3.2
-rw-r--r-- 1 riet riet 2110 feb 9 23:40 license.txt
-rwxrwxr-x 1 riet riet 34259741 feb 9 23:40 mprime
-rw-r--r-- 1 riet riet 20019 feb 9 23:40 readme.txt
-rw-r--r-- 1 riet riet 6860 feb 9 23:40 stress.txt
-rw-r--r-- 1 riet riet 36601 feb 9 23:40 undoc.txt
-rw-r--r-- 1 riet riet 55153 feb 9 23:40 whatsnew.txt
P5K:~/Mersenne$
P5K:~/Mersenne$ ./mprime -m
bash: ./mprime: kan binair bestand [I][U]Verkeerd uitvoerbaar bestand[/U][/I] niet uitvoeren
P5K:~/Mersenne$

[/CODE]

The last line can be translated as:

bash: ./mprime: cannot execute binary file [I][U]Wrong executable file[/U][/I]

Please post output from: [code]
file mprime
file libgmp.so.10.3.2
uname -a
[/code]
It sounds as if you have a version of mprime compiled for a different CPU to the one in your system. The above commands will check if that's the problem.

Chris

What is the output of [CODE]lscpu | grep Arch[/CODE]?

I downloaded mprime for Linux 64 bit as were all previous versions on this machine.

[CODE]
P5K:~/Mersenne$ ls -l
totaal 34120
lrwxrwxrwx 1 riet riet 16 mrt 19 09:32 libgmp.so -> libgmp.so.10.3.2
lrwxrwxrwx 1 riet riet 16 mrt 19 09:32 libgmp.so.10 -> libgmp.so.10.3.2
-rwxr-xr-x 1 riet riet 545695 feb 9 23:40 libgmp.so.10.3.2
-rw-r--r-- 1 riet riet 2110 feb 9 23:40 license.txt
-rwxrwxr-x 1 riet riet 34259741 feb 9 23:40 mprime
-rw-r--r-- 1 riet riet 20019 feb 9 23:40 readme.txt
-rw-r--r-- 1 riet riet 6860 feb 9 23:40 stress.txt
-rw-r--r-- 1 riet riet 36601 feb 9 23:40 undoc.txt
-rw-r--r-- 1 riet riet 55153 feb 9 23:40 whatsnew.txt
P5K:~/Mersenne$ file mprime
mprime: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.9, not stripped
P5K:~/Mersenne$ file libgmp.so.10.3.2
libgmp.so.10.3.2: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, not stripped
P5K:~/Mersenne$ uname -a
Linux P5K 4.4.0-116-generic #140-Ubuntu SMP Mon Feb 12 21:22:43 UTC 2018 i686 i686 i686 GNU/Linux
riet@Merlijn-P5K:~/Mersenne$

P5K:~/Mersenne$ lscpu | grep Arch
Architecture: i686



[/CODE]

You're running a 32-bit Linux installation, so the 64-bit binary won't work.

Looks like a 64 bit system to me, all previous mprime versions were also 64 bit on this machine:

[CODE]
P5K:~/Mersenne-oud$ lscpu
Architecture: i686
CPU-modus(sen): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 4
On-line CPU(s) list: 0-3
Draden per kern: 1
Kern(en) per voet: 4
Socket(s): 1
Producent-ID: GenuineIntel
CPU-familie: 6
Model: 15
Model name: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz
Stepping: 11
CPU-frequentie (MHz): 1596.000
CPU max MHz: 2394,0000
CPU min MHz: 1596,0000
BogoMIPS: 4811.10
Virtualisatie: VT-x
L1d-cache: 32K
L1i-cache: 32K
L2-cache: 4096K
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm retpoline tpr_shadow vnmi flexpriority dtherm

[/CODE]

[QUOTE=tha;482926]Looks like a 64 bit system to me, all previous mprime versions were also 64 bit on this machine:

[CODE]
P5K:~/Mersenne-oud$ lscpu
Architecture: i686
CPU-modus(sen): 32-bit, 64-bit
[/CODE][/QUOTE]

Your CPU is 64 bit, but your operating system (kernel, more specifically) is 32 bit. i686 is a 32 bit architecture. You can see "i686" in your previous console output as well.