PRPnet 2nd drive-51 bases with <= 5 k's to n=250K
 

This is CRUS PRPnet team drive #2 for all bases <= 200 with <= 5 k's remaining. We will be testing all k's to n=250K or until primed. Included in the drive are 51 bases and we may include more as bases are released or more bases are found with <= 5 k's remaining. The bases have each been sieved to their optimum depth for testing up to n=250K.

We will be running the drive entirely on CRUS PRPnet server port 1400. The server will hand out work by n-value so several bases will not be tested until we reach n=150K or 200K.

Instructions for running a PRPnet server and download links can be found [URL="http://www.mersenneforum.org/showthread.php?t=12223"][COLOR=#000080]here[/COLOR][/URL]. The info. specific to this server that needs to be entered into your prpclient.ini file is:

server=G1400:100:1:noprimeleftbehind.net:1400

Server info.:

[B]CRUS PRPnet server #2 (updated 2013-08-12 02:30 GMT):[/B]
maintained by mdettweiler on gd_barnes machine
Short identification: G1400
server: noprimeleftbehind.net
port: 1400
51 bases <= 200 with <= 5 k's remaining to n=250K
n-range: 50K-250K
currently processing at n= [COLOR=#0000ff]250K (complete)[/COLOR]
Server summary: [URL="http://noprimeleftbehind.net:1400/all.html"][COLOR=#000080]http://noprimeleftbehind.net:1400/all.html[/COLOR][/URL]

Primes:
[code]
Prime found by
1004*133^238300-1 Mathew
778*73^220782+1 mdettweiler
62*107^219967+1 Mathew
486*187^212627+1 Mathew
3303*112^210284+1 mdettweiler
194*165^196199+1 Mathew
2018*162^194314-1 Mathew
1886*67^177962-1 Mathew
86*123^176510-1 MyDogBuster
948*112^173968-1 MyDogBuster
18*189^171175+1 Mathew
4119*70^157484+1 Siemelink
576*172^132695-1 Mathew
38*200^131900-1 mdettweiler
584*103^131076-1 Mathew
304*135^114227+1 Lennart
94*107^105926+1 MyDogBuster
242*67^105312-1 Lennart
10968*61^102738-1 Lennart
58*200^102363-1 Lennart
2954*162^95124-1 Lennart
1308*162^82803-1 Lennart
693*172^61919-1 Lennart
178*191^52494+1 Lennart
[/code]Base / starting n / k's remain / # primes
[code]
R61 100K 4k 1
R67 100K 5k 2
R70 100K 3k
R80 200K 3k
R93 200K 1k
R94 200K 1k
R100 200K 1k
R103 100K 2k 1
R109 200K 1k
R112 150K 3k 1
R123 100K 2k 1
R133 100K 2k 1
R152 200K 1k
R158 100K 3k
R160 200K 1k
R162 50K 5k 3
R163 100K 1k
R172 50K 5k 2
R173 100K 1k
R177 100K 1k
R181 100K 1k
R182 100K 1k
R191 100K 2k
R200 100K 2k 2 (proven)
S37 200K 3k
S55 200K 4k
S68 200K 2k
S70 100K 5k 1
S73 200K 2k 1
S75 100K 2k
S86 200K 1k
S100 100K 5k
S102 100K 3k
S107 100K 4k 2
S112 150K 2k 1
S118 200K 1k
S122 200K 1k
S133 100K 3k
S135 50K 5k 1
S140 100K 2k
S148 150K 1k
S155 200K 1k
S157 100K 3k
S165 100K 4k 1
S173 200K 1k
S174 200K 1k
S183 150K 1k
S185 100K 1k
S187 100K 1k 1 (proven)
S189 100K 1k 1 (proven)
S191 50K 4k 1
[/code]Good luck everyone and let's go prove some conjectures! :-)

[B]The drive is now complete. Thanks to all who participated![/B]


Gary

All four n=50K bases have now been loaded into the server for a total of 22 bases. It's off to the races now! :smile:

693*172^61919-1 is Prime

2954*162^95592-1 is prime! (P = 3) Time : 3353.472 sec.

Lennart

178*191^52494+1 is prime! Time : 284.562 sec.

1308*162^82803-1 is Prime

2954*162^95124-1 is prime! (P = 3) Time : 3338.565 sec.

This one is on a lower n.

Lennart

Wow, what a run after a slow start.

I wonder why the clients only proved 2 out of the 5 PRP's? Mark, do you have any thoughts on that?

[QUOTE=gd_barnes;268326]Wow, what a run after a slow start.

I wonder why the clients only proved 2 out of the 5 PRP's? Mark, do you have any thoughts on that?[/QUOTE]

I can't access the NPLB PRPNet server from work, so I will investigate when I get home later.

Until then, can someone tell me which were not proven and which program was used to determine that they are PRP?

There are some possibilities, which might account for that.

1) Running LLR only, but LLR can't prove primality due to running an older version of LLR.
2) Running LLR only with current LLR, but PRPNet client is incorrectly parsing the LLR output.
3) Running phrot on non-x86 computer as phrot can't prove primality.
4) Running phrot on x86 computer as pfgw and llr are not available.
5) Running pfgw, but primality test fails (least likely cause).

[QUOTE=rogue;268329]
Until then, can someone tell me which were not proven and which program was used to determine that they are PRP?[/QUOTE]

Primes:
693*172^61919-1
1308*162^82803-1

PRPs:
178*191^52494+1
2954*162^95124-1
2954*162^95592-1

Lennart will have to answer about LLR or Phrot. Based on your response, if I had to speculate, he may have an older version of LLR in a couple of clients.

[QUOTE=gd_barnes;268330]Lennart will have to answer about LLR or Phrot. Based on your response, if I had to speculate, he may have an older version of LLR in a couple of clients.[/QUOTE]

That information will be in the database.

Note that if running on a 64-bit OS that 64-bit pfgw is much faster than 32-bit llr for non-power of 2 bases. By much faster I mean more than 1 or 2 percent. pfgw can be 10 percent or more faster than llr, depending upon various factors. I understand that a separate primality test will be needed if a PRP is found, but since so few primality tests are needed (less than 1 in 1000), it is far better to use pfgw on a 64-bit OS. Now if they are all on 32-bit OS's then 32-bit llr is better than 32-bit pfgw.

[QUOTE=rogue;268329]I can't access the NPLB PRPNet server from work, so I will investigate when I get home later.

Until then, can someone tell me which were not proven and which program was used to determine that they are PRP?

There are some possibilities, which might account for that.

1) Running LLR only, but LLR can't prove primality due to running an older version of LLR.
2) Running LLR only with current LLR, but PRPNet client is incorrectly parsing the LLR output.
3) Running phrot on non-x86 computer as phrot can't prove primality.
4) Running phrot on x86 computer as pfgw and llr are not available.
5) Running pfgw, but primality test fails (least likely cause).[/QUOTE]
Interestingly enough, I think #5 may actually be what happened here. The email notifications for all three PRPs indicated that they were found with pfgw64 but for whatever reason not proven. Here's one of them:
[quote]
This number is approximately 119744 digits long. It was found on machine 15 using the program pfgw64. Since the test performed as only a PRP test, another program, such as PFGW must be used to prove primality. If the number is prime and is large enough for the Prime Pages, please include the program pfgw64 in the credits. If adding to the Prime Pages don't forget to include project "CRUS" in the credits.
[/quote]

[QUOTE=mdettweiler;268333]Interestingly enough, I think #5 may actually be what happened here. The email notifications for all three PRPs indicated that they were found with pfgw64 but for whatever reason not proven. Here's one of them:[/QUOTE]

Interesting. Can someone produce the PRPNet client output (and log file) to see what happened? Do you know which version of the client the user was running? Did they stop the client during the primality test?

The problem is PFGW 64

those 2 computer did not have glib 2.7

I did coment out pfgw and I have no problem.


Lennart

Why is PFGW64 unable to prove PRPs?

What is glib 2.7?

Why was PFGW commented out?

[QUOTE=Lennart;268337]The problem is PFGW 64

those 2 computer did not have glib 2.7

I did coment out pfgw and I have no problem.

Lennart[/QUOTE]

This isn't clear to me. Are you saying that pfgw64 found the PRP, but due to the missing glib 2.7 library that it could not prove primality?

Can you install the latest glib on those computers? If not, I can walk you through the building of pfgw64 on them. It will link with whatever version of glibc that you have installed. In the Linux distribution or 3.4.9 there is both pfgw64 and pfgw64s. pfwg64s is statically linked. Have you tried that version?

[QUOTE=gd_barnes;268338]Why is PFGW64 unable to prove PRPs?

What is glib 2.7?

Why was PFGW commented out?[/QUOTE]
First of all: the inability to prove PRPs had nothing to do with PFGW64. It apparently, for reasons that are not yet entirely clear, had to do with glib 2.7 being missing on Lennart's two computers.

glib is a standard "library" present on most Linux systems that compiled applications can typically refer to by implication rather than having to duplicate its code within their own binaries. However, sometimes a Linux installation will be missing one or more of these libraries (perhaps it's an older version, or was a "light" installation of the OS with not all the libraries installed to save space), and thus an application that depends on them will fail to run. In this case, the primality-proof function of PFGW apparently depends on glib 2.7. In order for it to work, one must either have glib 2.7 installed, or get a statically linked build of PFGW, which is compiled in a way such that the needed library code is included directly in the binary, instead of included by reference. A statically linked binary can be a rather larger file than a dynamically linked one, so the latter is preferable whenever possible.

You may recall that on Jean Penne's website where you can download LLR, he has both "llr" and "sllr" builds available for Linux; the latter is statically linked.

Also: on Windows, the equivalent of such a "library" is a DLL file (for "Dynamic Link Library"), which usually resides in the C:\Windows\System32 folder. If you've ever gotten a "cannot locate dynamic link library x.dll" error from a program, that's essentially the same kind of error Lennart got, just translated into Windows-speak.

In Lennart's case, he had a working LLR build set up with his PRPnet client (either he had the statically linked build, or his system had all the necessary libraries present to run the dynamic build of LLR), so in the absence of a fully-functional PFGW, he simply commented out the PFGW line in prpclient.ini, forcing the client to use LLR instead for both PRP and primality tests. As Mark explained earlier, both are equally fast on a 32-bit system (actually LLR has a slight advantage since it does not need to do a separate re-test to prove PRPs), but since there is no 64-bit LLR, it is preferable to use PFGW64 whenever possible on a 64-bit system so as to take advantage of the 64-bit speed boost.

[QUOTE=rogue;268339]This isn't clear to me. Are you saying that pfgw64 found the PRP, but due to the missing glib 2.7 library that it could not prove primality?

Can you install the latest glib on those computers? If not, I can walk you through the building of pfgw64 on them. It will link with whatever version of glibc that you have installed. In the Linux distribution or 3.4.9 there is both pfgw64 and pfgw64s. pfwg64s is statically linked. Have you tried that version?[/QUOTE]

I did use pfgw64 3.4.5 In all folder I found a PRP there is a pfgw.log with the number in.

But it did the prp but not the primeproof ! I can't see what happend but the client just closed.

I coment out pfgw and restarted the client and I don't realy know how it got back as a prp.

Now I have changed them to pfgw64s 3.4.9



Lennart

EDIT: Client Linux 64 4.3.5

[QUOTE=Lennart;268346]But it did the prp but not the primeproof ! I can't see what happend but the client just closed.[/QUOTE]

That implies a possible bug in the client or in pfgw64. Keep an eye on it and let us know if the problem is fixed with pfgw 3.4.9.

All n=50K bases for the drive have reached n=100K. Many bases are now being processed at once. There will be many "returns" to n=100K as we continue loading in more bases that are at that search depth.

A large majority of primes will now be in the top 5000 range. :smile:

S107
 

[URL]http://primes.utm.edu/primes/page.php?id=101029[/URL]

94*107^105926+1 is prime - 3 left in that base

[QUOTE=Lennart;268346]I did use pfgw64 3.4.5 In all folder I found a PRP there is a pfgw.log with the number in.

But it did the prp but not the primeproof ! I can't see what happend but the client just closed.

I coment out pfgw and restarted the client and I don't realy know how it got back as a prp.

Now I have changed them to pfgw64s 3.4.9



Lennart

EDIT: Client Linux 64 4.3.5[/QUOTE]


Based on your statements here, I just figured out something here that I could not previously figure out: When you said that the clients that found the PRPs just closed, I finally figured out that they just "hung" and did not report anything until you restarted them with PFGW commented out. That is why I saw two tests on client 15 at the top of the pending tests list for hours. Those tests were PRPs waiting to be reported! It caused those k values to continue testing to a far higher n range than the PRPs.

It also explains why it appeared there was only 1 prime on the drive for a very long time and then a whole bunch came in all at once.

The moral of the story is: Everyone please do whatever you can to make sure that your clients prove the primes. Otherwise there is a good chance that a PRP will be found, the client will hang without reporting any results to the server (kind of like not connecting), and others will continue testing that k value long after a prime has actually been found. As long as the PRP is reported to the server, that is OK but if the client just hangs, then nothing will get reported and the test will sit in the queue for 2 days (until handed out again) or until you restart the client.


Gary

Lennart,

It looks like the same problem is happening again. You have found that:

10968*61^102738-1 is prime!

(Actually I'm sure that you've found it to be PRP and cannot prove it to be prime.)

This test has hung on one of your clients for several hours, probably because it cannot prove a PRP. I proved it prime on my machine after seeing the hung test.

The problem is that k=10968 is continuing to be handed out by the server.

Can you please check that all of your clients can prove PRPs and return this test to the server?


Thank you,
Gary

[QUOTE=gd_barnes;268551]Lennart,

It looks like the same problem is happening again. You have found that:

10968*61^102738-1 is prime![/QUOTE]


We have what appears to be yet another hung client with a PRP that has been sitting for several hours:

242*67^105312-1 is prime!

Both of the recent primes were on client 14 and were likely found PRP but not returned to the server. Once again, I proved it on my machine.

If I happen to be online, I am now checking any tests that are hung in the queue for a period that is longer than that person's normal testing return time.

It is the same issue on that computer. They are in resultlog as PRP but close the client when starting N+1 test.
I have changed pfgw to pfgw64s 3.4.9 and restarted the client.Now it is doing the N+1 test, I hope it will be reported to server also.

Lennart

10968*61^102738-1 is Prime

242*67^105312-1 is Prime

Lennart

Lennart, can you be more specific by what you mean by "hung"? Are you saying that the PRPNet client is stuck due to unexpected results from pfgw or that pfgw is stuck when trying to do the primality tests?

[QUOTE=rogue;268566]Lennart, can you be more specific by what you mean by "hung"? Are you saying that the PRPNet client is stuck due to unexpected results from pfgw or that pfgw is stuck when trying to do the primality tests?[/QUOTE]

I'm the one that used the word "hung".

The clients get "stuck" when PFGW is trying to do the primality test. This is evidenced by the fact that the test sits in the port 1400 queue (on the web page in the 1st post of this thread) for hours waiting for the client to return the result to the server.

Is this something that can be fixed in PRPnet? I'm thinking that if the client cannot prove a PRP, it should still return it to the server without "hanging up" or "closing".

[QUOTE=rogue;268566]Lennart, can you be more specific by what you mean by "hung"? Are you saying that the PRPNet client is stuck due to unexpected results from pfgw or that pfgw is stuck when trying to do the primality tests?[/QUOTE]

pfgw does the prp test and write it to the log. When it start the primalty proof the clint close.

After that I changed to pfgw64s 3.4.9 and restarted the client pfgw did the primalty test and reported it back to the server

First I was using pfgw64 3.4.5

Lennart

[QUOTE=Lennart;268575]pfgw does the prp test and write it to the log. When it starts the primalty proof the client closes.[/QUOTE]

I believe that what is happening is that the client is thinking that Lennart terminated PFGW with ^C. A message would be in the log if that were happening. Presuming that is the case, the client will shut down. The problem is that the output from PFGW is "incomplete", i.e. it is missing something that tells it that PFGW completed its processing before stopping.

I don't know if there is much I can do about this in the PRPNet client because it is in essence stating that PFGW was terminated, thus it should terminate. I find it interesting that the PRP test did not require glibc, but the primality test does. I could probably put something into PFGW to make it require glibc for any test as that would have helped us discover this problem earlier.

[2011-08-06 23:21:22 CEST] crus: INFO: Test for 1520*61^102587-1 was accepted
[2011-08-06 23:21:22 CEST] crus: INFO: All 1 test results were accepted
[2011-08-06 23:21:23 CEST] crus: Getting work from server nplb-gb1.no-ip.org at port 1400
[2011-08-06 23:21:27 CEST] crus: PRPNet server is version 4.3.5
[2011-08-06 23:29:19 CEST] crus: Test results not found in file [work_crus.out]. Assuming user stopped with ^C
[2011-08-06 23:29:19 CEST] Total Time:127:44:57 Total Tests: 945 Total PRPs Found: 0
[2011-08-06 23:29:19 CEST] Client shutdown complete
[2011-08-07 12:36:25 CEST] PRPNet Client application v4.3.5 started
[2011-08-07 12:36:25 CEST] User name sm5ymt at email address is [email]sm5ymt@pekhult.se[/email]
[2011-08-07 13:07:53 CEST] 10968*61^102738-1 proven prime by pfgw64s. Time: 1888 seconds
[2011-08-07 13:07:53 CEST] crus: 10968*61^102738-1 is prime
[2011-08-07 13:07:53 CEST] Total Time: 0:31:29 Total Tests: 1 Total PRPs Found: 1
[2011-08-07 13:07:54 CEST] crus: Returning work to server nplb-gb1.no-ip.org at port 1400
[2011-08-07 13:07:55 CEST] crus: INFO: Test for 10968*61^102738-1 was accepted
[2011-08-07 13:07:55 CEST] crus: INFO: All 1 test results were accepted
[2011-08-07 13:07:56 CEST] crus: Getting work from server nplb-gb1.no-ip.org at port 1400

304*135^114227+1 is Prime

Lennart

58*200^102363-1 is Prime

Lennart

Hey guys. We have a problem. The 3 k's for S133 were incorrectly loaded in the server as R133 3-4 hours ago. As I am unfamiliar with loading/correcting PRPnet servers and have been unable to get ahold of Max since that time, can someone give me exact details on deleting the incorrect k's? Note that there are 2 correct k's for R133 already there.

I'm familiar with DB2 commands (legacy systems) and I know that SQL commands are virtually the same. More than anything I just need to know how to get to the database from the command prompt, select the incorrect k's, delete them, and then get back out of the database to restart it.

This will mean that you will get some rejected errors by the server after I delete the bad pairs. I do not believe that this will affect the server scores. The only loss of credit will be for the few pairs that are rejected.

I will not plan on loading in S133. Max should be available later today to load it in correctly. The main thing is to get the incorrect pairs out of the server to prevent further waste of CPU time.


Thanks,
Gary

[QUOTE=gd_barnes;268852]Hey guys. We have a problem. The 3 k's for S133 were incorrectly loaded in the server as R133 3-4 hours ago. As I am unfamiliar with loading/correcting PRPnet servers and have been unable to get ahold of Max since that time, can someone give me exact details on deleting the incorrect k's? Note that there are 2 correct k's for R133 already there.

I'm familiar with DB2 commands (legacy systems) and I know that SQL commands are virtually the same. More than anything I just need to know how to get to the database from the command prompt, select the incorrect k's, delete them, and then get back out of the database to restart it.

This will mean that you will get some rejected errors by the server after I delete the bad pairs. I do not believe that this will affect the server scores. The only loss of credit will be for the few pairs that are rejected.

I will not plan on loading in S133. Max should be available later today to load it in correctly. The main thing is to get the incorrect pairs out of the server to prevent further waste of CPU time.[/QUOTE]

From the command line:

mysql -u<user> -p<pwd> <dbname>

You can get these values from database.ini in the directory the server is run out of.

To get rid of the bad entries, you will need three statements:

delete from candidatetestresult where candidatename like '%133^%+1";
delete from candidatetest where candidatename like '%133^%+1";
delete from candidate where candidatename like '%133^%+1";

Then start prpadmin and use option 6 to recompute server stats.

--Mark

you can use the prpadmin-tool and a faked factorfile to remove all incorrect candidates. the tool only checks that the line is of form "factor | candidate".
so you can set any factor.
you will need the imported candidates (sievefile) and set for each candidate to remove a line in the factorfile.

prpadmin will then cleanup all tables in the database.

when clients report work for such a candidate the server writes a errormessage to log.

i think this way is easier than cleanup the database manually.

other ways can have ugly side effects.

[QUOTE=rogue;268855]From the command line:

mysql -u<user> -p<pwd> <dbname>

You can get these values from database.ini in the directory the server is run out of.

To get rid of the bad entries, you will need three statements:

delete from candidatetestresult where candidatename like '%133^%+1";
delete from candidatetest where candidatename like '%133^%+1";
delete from candidate where candidatename like '%133^%+1";

Then start prpadmin and use option 6 to recompute server stats.

--Mark[/QUOTE]

OK thanks.

First, the bad pairs entered are Riesels so deleting like '%133^%+1" would delete nothing. Second, there are 2 k's in there that are correct for R133. It's the 3 most recent k's that are incorrect (they should be S133). If I deleted all base 133 pairs, that would be a bad thing. Third, I wouldn't want to affect people's stats. They should still get credit for the work on the incorrect pairs.

Knowing SQL commands as I do, if I can get into the database, I can easily delete the specific rows that I need to. I just have to specify by both base and k-value.

Unfortunately I have to leave now. I hope to get to it in the next hour.

OK the server will be down for the next 10-15 mins. while I check closely and then delete the bad pairs. I'll edit this post when it is done.

[QUOTE=gd_barnes;268857]OK thanks.

First, the bad pairs entered are Riesels so deleting like '%133^%+1" would delete nothing. Second, there are 2 k's in there that are correct for R133. It's the 3 most recent k's that are incorrect (they should be S133). If I deleted all base 133 pairs, that would be a bad thing. Third, I wouldn't want to affect people's stats. They should still get credit for the work on the incorrect pairs.

Knowing SQL commands as I do, if I can get into the database, I can easily delete the specific rows that I need to. I just have to specify by both base and k-value.

Unfortunately I have to leave now. I hope to get to it in the next hour.[/QUOTE]

That's why it is "%+1", not "%1" or "-1". "%+1" will delete Sierpinski only. As for stats, users will not lose credit for what is complete, but they will not gain credit for workunits they return after you delete the records.

If you care about specific k, then use "<k>*133%+1" instead of "%133^%+1".

[QUOTE=rogue;268861]That's why it is "%+1", not "%1" or "-1". "%+1" will delete Sierpinski only. As for stats, users will not lose credit for what is complete, but they will not gain credit for workunits they return after you delete the records.

If you care about specific k, then use "<k>*133%+1" instead of "%133^%+1".[/QUOTE]

lol We're still not communicating.

S133 has been entered as R133.

Deleting +1 would delete nothing. There are no +1's in the DB. Everything has been entered as -1. I should have it here shortly.

BTW, the table names are case specific with several caps in each.

The bad pairs have now been deleted from the server. The HTML page is still showing the bad k's but I assume that it will update itself in a few minutes to remove them.

Even if there is something more to do, I can guarantee that no more bad pairs will be handed out.

You may have some results that are rejected by the server. These are just the bad pairs clearing themselves out. Future pairs will all be good.

Max will load S133 plus two more bases likely later tonight.

[QUOTE=gd_barnes;268865]The bad pairs have now been deleted from the server. The HTML page is still showing the bad k's but I assume that it will update itself in a few minutes to remove them.

Even if there is something more to do, I can guarantee that no more bad pairs will be handed out.

You may have some results that are rejected by the server. These are just the bad pairs clearing themselves out. Future pairs will all be good.

Max will load S133 plus two more bases likely later tonight.[/QUOTE]
Yes, all set now--nice work Gary, everything looks good. :smile: I ran a "recompute server statistics" with the prpadmin tool to clean out the (now empty) entries for the bad k's on the web page, and then reloaded S133 the right way.

Sorry about that everyone--this was my bad completely. Since the sieve files are in NewPGen format, and PRPnet reads ABC format, I need to add an appropriate header manually to each file before loading it; in this case, it needed to be "ABC $a*133^$b+1" but I typed -1 instead. :redface:

Max :smile:

[QUOTE=mdettweiler;268868]Since the sieve files are in NewPGen format, and PRPnet reads ABC format, I need to add an appropriate header manually to each file before loading it; in this case, it needed to be "ABC $a*133^$b+1" but I typed -1 instead. :redface:[/QUOTE]

That's what srfile is for. :smile:

[QUOTE=rogue;268870]That's what srfile is for. :smile:[/QUOTE]

I had been sending him files in -G (NewPGen) format not knowing about the header issue. After an Email discussion, I will now send them to him in -w (ABC) format. That should prevent the problem in the future.

[QUOTE=gd_barnes;268872]I had been sending him files in -G (NewPGen) format not knowing about the header issue. After an Email discussion, I will now send them to him in -w (ABC) format. That should prevent the problem in the future.[/QUOTE]


You must mean -g ?

Lennart

[QUOTE=Lennart;268889]You must mean -g ?

Lennart[/QUOTE]

No, -G. -G creates one file, which is what I want to send to Max. -g creates a separate file for each k. I suppose technically -G is not NewPGen format since NewPGen can only handle one k for multiple n. But the header is the same and it "looks" like NewPGen format. :smile:

[QUOTE=gd_barnes;268891]No, -G. -G creates one file, which is what I want to send to Max. -g creates a separate file for each k. I suppose technically -G is not NewPGen format since NewPGen can only handle one k for multiple n. But the header is the same and it "looks" like NewPGen format. :smile:[/QUOTE]

Ok Now I understand :smile:

Lennart

All 51 bases have now been loaded into the server.

Hooray! :smile:

Many thanks to Lennart for doing 90-95% of the sieving!

I am going to pull S43 out of the drive. The drive will make it too long before such a low 1k base is being tested at n>200K. All other 1k bases < 70 are already tested to n>=400K and all other 1k bases < 85 are tested to n>=250K.

I'll reserve it in the appropriate thread and start on it in ~10-12 days after R24 and R25 are complete to n=100K. I'll post the remaining sieve file up to n=1M on the pages when I am done with it.

[URL="http://primes.utm.edu/primes/page.php?id=101402"]584*103^131076-1[/URL] is prime

R200's summary line is bugged somehow. It has a red background color, and the Completed Thru and Leading Edge numbers are 999999999. It is presumably related to its recent prime, proving the conjecture for that base. Anyone know what's up?

[QUOTE=Mini-Geek;270609]R200's summary line is bugged somehow. It has a red background color, and the Completed Thru and Leading Edge numbers are 999999999. It is presumably related to its recent prime, proving the conjecture for that base. Anyone know what's up?[/QUOTE]

That is related to how the stats are computed. I could probably leave those cells blank instead.

As Mini-Geek hinted a couple posts up, we now have our first proof of the drive--and guess who found it? :big grin:

[URL="http://primes.utm.edu/primes/page.php?id=101461"]38*200^131900-1[/URL] is prime!

Kind of nice aesthetically with all the 00's in the number... :smile:

Congrats on providing our first proof! I noticed it on the server, but didn't know about the etiquette of posting it here in the forums.

I want a prime now! :D

[QUOTE=Mathew;270493][URL="http://primes.utm.edu/primes/page.php?id=101402"]584*103^131076-1[/URL] is prime[/QUOTE]

Nice one Mathew! :smile:

[QUOTE=mdettweiler;270622]As Mini-Geek hinted a couple posts up, we now have our first proof of the drive--and guess who found it? :big grin:

[URL="http://primes.utm.edu/primes/page.php?id=101461"]38*200^131900-1[/URL] is prime!

Kind of nice aesthetically with all the 00's in the number... :smile:[/QUOTE]

Wow. Nice proof! That's faster than I would have expected us to prove one.

[URL="http://primes.utm.edu/primes/page.php?id=101614"]576*172[SUP]132695[/SUP]-1[/URL] is prime

[QUOTE=Mathew;270699][URL="http://primes.utm.edu/primes/page.php?id=101614"]576*172[SUP]132695[/SUP]-1[/URL] is prime[/QUOTE]

Nice.

On an interesting note, the Riesel side primes are far outpacing the Sierp side primes so far on this drive despite the Sierp side starting with far more k's; 63 to 51.

Using prpclient-4.3.5 for Drive #2. I'm wondering if there is a way to maintain a buffer and report each work-unit as it is completed.

My internet can be a bit flaky, and it'd be nice if I could return workunits as soon as they're done, but have a twelve-hour buffer just in case my internet goes out.

Is there some combination of options in the .ini file that can achieve this?

[QUOTE=paleseptember;272484]Using prpclient-4.3.5 for Drive #2. I'm wondering if there is a way to maintain a buffer and report each work-unit as it is completed.

My internet can be a bit flaky, and it'd be nice if I could return workunits as soon as they're done, but have a twelve-hour buffer just in case my internet goes out.

Is there some combination of options in the .ini file that can achieve this?[/QUOTE]
Ah, yes...I do sympathize with your problem, having formerly had similar problems with my own DSL line where it cut out every 61 minutes like clockwork. :rolleyes: The PRPnet client does not, unfortunately, have this kind of option right now; it always runs an entire batch before reporting it unless you stop the client in the middle (in which case it can report partial results if you have so set up prpclient.ini) In fact, the "new" LLRnet client has a similar limitation; the reason being that, as far as I know, the only way to use a "buffer" model is to involve multithreading on the client side. That's what the "old" LLRnet client did, but the disadvantage was that it could be flaky at times and tended to "hang" (particularly on Windows platforms) when the connection was lost in the middle of a server communication, presumably due to synchronization between threads being messed up.

You may want to suggest the feature over in Mark's [url=http://www.mersenneforum.org/showthread.php?p=267715]PRPnet 4.x announcements/feature-requests/bug-reports thread[/url]; he would be able to give a better answer than I as to how tough it would be to implement. If it is to be pursued, I would think it might be better to (at least in the short term) fork off a second version of the client so as to leave a solid, stable single-threaded client while myriad bugs are worked out of the necessarily multi-threaded "buffered" version.

In early versions of PRPnet, the idea of buffering workunits was addressed by the ability to run a "slave" server, much like an LLRnet proxy, which would keep a constant buffer of work from the main server and dole it out to clients on the local network. This feature was initially retained from ECMNet, which contributed heavily to PRPnet's initial code; but it was dropped in later PRPnet versions since it would have needed heavy rewriting to work well for PRPnet, and nobody was using it anyway (being that it didn't work :smile:).

Anyway...in the meantime, all I can suggest is that you keep a large queue of workunits in your clients, to reduce the number of times they have to connect to the server (and consequently, the probability that they'll attempt to connect during a time when the internet is out). For instance, if each test takes a maximum of (say) 3500 seconds to complete--factoring in a little extra wiggle room--each core should be able to safely do 40-45 or so workunits within the 48 hour limit. Depending on how long your internet usually goes out for (just a few minutes? or hours?) you may want to give a little more space to allow extra time in case the internet does happen to be out when the tests are up to be returned, so you don't risk having them expired while your internet is out.

It's not a perfect solution, but does help some at least. :smile:

[QUOTE=paleseptember;272484]Using prpclient-4.3.5 for Drive #2. I'm wondering if there is a way to maintain a buffer and report each work-unit as it is completed.

My internet can be a bit flaky, and it'd be nice if I could return workunits as soon as they're done, but have a twelve-hour buffer just in case my internet goes out.

Is there some combination of options in the .ini file that can achieve this?[/QUOTE]

Not today. I've thought about it, but not enough to implement. It isn't high on my priority list.

Thanks mdettweiler, thanks rogue. Will continue on crunching as best I can.

Have queued up a much larger buffer. Am slightly embarrassed by how much of the 'assigned work' table I'm taking up.

Hello friends,

I've managed to start a PRP-client succesfully. I noticed one thing that makes it harder for me run it: the CMD-screens.
I run this on the family PC and all the rest of my family may just kill off the sessions from the taskbar. What's an easy trick to hide the prpclients?

Thanks, Willem.

[QUOTE=Siemelink;272712]Hello friends,

I've managed to start a PRP-client succesfully. I noticed one thing that makes it harder for me run it: the CMD-screens.
I run this on the family PC and all the rest of my family may just kill off the sessions from the taskbar. What's an easy trick to hide the prpclients?

Thanks, Willem.[/QUOTE]

I use [URL="http://www.digik-oz.nl/dcPSP.aspx"]PSP Runner[/URL]. It was made for the PSP project, but works just as well with anything that uses PRPnet (except that for bases besides 2, it doesn't update the status correctly; this is visual only). It's used to run the prpnet clients for you.
Another more general option is [URL="http://www.expocenter.com/hideit/"]Hide-it[/URL]. It can hide any window. It's a handy utility for math projects, where many tools can only run in a command window.

[QUOTE=Mini-Geek;272713]
Another more general option is [URL="http://www.expocenter.com/hideit/"]Hide-it[/URL]. It can hide any window. It's a handy utility for math projects, where many tools can only run in a command window.[/QUOTE]

Thank you Mini-Geek. Hide-it did the trick.

Good night, Willem.

Adding S148 with 1k remaining at n=150K to the drive. I will begin sieving on it in 2-3 days.

noprimeleftbehind.net is down for me. I can't connect to port 1400 or 9000, and the site itself times out for me.

Posting just in case no one else has noticed.

[QUOTE=paleseptember;274161]noprimeleftbehind.net is down for me. I can't connect to port 1400 or 9000, and the site itself times out for me.

Posting just in case no one else has noticed.[/QUOTE]
Yeah, it does look down from here...I can't reach the server either through the web site or through SSH. [url]http://nplb-gb1.no-ip.org/[/url] (the alternate address) doesn't work either, so it doesn't look like a DNS issue; perhaps a power outage or something. At any rate, we'll probably hear more about it from Gary when he notices the outage and (hopefully) is able to fix it.

All is working now.

Mini-milestone reached: the project has passed n=150K!
Not too shabby for 10 weeks of crunching.

[QUOTE=paleseptember;274807]Mini-milestone reached: the project has passed n=150K!
Not too shabby for 10 weeks of crunching.[/QUOTE]

Yes, that's a big milestone! Several more bases are now being searched. :smile:

It appears that Willem (Siemelink) found a large prime here on Sunday. :smile:


Gary

[QUOTE=gd_barnes;277559]It appears that Willem (Siemelink) found a large prime here on Sunday. :smile:

Gary[/QUOTE]

I did?
I did!
[2011-11-06 10:43:11 RST] Server: G1400, Candidate: 4119*70^157484+1 Program: pfgw32.exe Residue: PRP Time: 6179 seconds
[2011-11-06 13:08:20 RST] Server: G1400 Candidate: 4119*70^157484+1 Program: pfgw32.exe Residue: PRIME Time: 8710 seconds

What's the correct label on the prime site? CRUS, srsieve, PFGW, myself. Lennart, for the sieving? Gary, as he runs our show?

Willem.

[QUOTE=Siemelink;277615]I did?
I did!
[2011-11-06 10:43:11 RST] Server: G1400, Candidate: 4119*70^157484+1 Program: pfgw32.exe Residue: PRP Time: 6179 seconds
[2011-11-06 13:08:20 RST] Server: G1400 Candidate: 4119*70^157484+1 Program: pfgw32.exe Residue: PRIME Time: 8710 seconds

What's the correct label on the prime site? CRUS, srsieve, PFGW, myself. Lennart, for the sieving? Gary, as he runs our show?

Willem.[/QUOTE]

yourself, Srsieve, CRUS, OpenPFGW

Congrats on a big one! :-)

Congrats indeed! That's an excellent find! :)

S189 is proven:

[URL="http://primes.utm.edu/primes/page.php?id=103986"]18*189[SUP]171175[/SUP]+1[/URL]

[QUOTE]S189 is proven:[/QUOTE]

Nice job Mathew. It also saves ~ 2700 tests :showoff:

Very nice! :tu: We've had a few people slowly, but steadily plugging away on this server for a number of months now without a prime--it's definitely time for one! (And a proof no less--superb!)

Excellent! Great find Mathew.:george::george:

It's about time for this server! :smile:

[URL="http://primes.utm.edu/primes/page.php?id=104194"]http://primes.utm.edu/primes/page.php?id=104194[/URL]

948*112^173968-1 is prime

R112 is now a 2ker

Talk about luck, I have only 1 core working on that port.

Nice one Ian.

R123
 

[URL="http://primes.utm.edu/primes/page.php?id=105413"]http://primes.utm.edu/primes/page.php?id=105413[/URL]

86*123^176510-1 is prime

R123 is now a 1ker

And my luck with this 1 core continues

Another nice one. Way to go Ian! :smile:

[QUOTE=MyDogBuster;292293][URL="http://primes.utm.edu/primes/page.php?id=105413"]http://primes.utm.edu/primes/page.php?id=105413[/URL]

86*123^176510-1 is prime

R123 is now a 1ker

And my luck with this 1 core continues[/QUOTE]

I also found this prime in my queue. I take it we're doing double checks?

Willem.

[QUOTE=Siemelink;292357]I also found this prime in my queue. I take it we're doing double checks?

Willem.[/QUOTE]

No. That's odd. Mark or Max, can you answer why the same test may have been handed out twice?

Willem, did you test the pair, return it to the server, and the server rejected or accepted it? There's no indication on the port 1400 page that it was tested more than once. It only shows that Ian found the prime. I'm not in a position to check the server logs so I don't know the specifics.

[QUOTE=gd_barnes;292361]No. That's odd. Mark or Max, can you answer why the same test may have been handed out twice?

Willem, did you test the pair, return it to the server, and the server rejected or accepted it? There's no indication on the port 1400 page that it was tested more than once. It only shows that Ian found the prime. I'm not in a position to check the server logs so I don't know the specifics.[/QUOTE]

Ah, it wasn't handed it yet I think. I have the entry in pfgw.log on the fourth of march. Currently the client is at:

Primality testing 86*123^176510-1 [N+1, Brillhart-Lehmer-Selfridge]
Running N+1 test using discriminant 3, base 1+sqrt(3)
N+1: 86*123^176510-1 402500/1225431 mro=0

Oh! My PC is not on 24x7, and when I shut it down the progress is lost. I just killed the process and the restart is back at 1/1225431.
Is this normal or did I screw up something in my installation?

Willem.

[QUOTE=Siemelink;292365]Ah, it wasn't handed it yet I think. I have the entry in pfgw.log on the fourth of march. Currently the client is at:

Primality testing 86*123^176510-1 [N+1, Brillhart-Lehmer-Selfridge]
Running N+1 test using discriminant 3, base 1+sqrt(3)
N+1: 86*123^176510-1 402500/1225431 mro=0

Oh! My PC is not on 24x7, and when I shut it down the progress is lost. I just killed the process and the restart is back at 1/1225431.
Is this normal or did I screw up something in my installation?[/QUOTE]

Unfortunately that is a caveat of pfgw. It doesn't checkpoint primality tests. I really want to fix it so that it can checkpoint point them, but it isn't an easy change and I am working on other things that have a higher priority.

OK, it sounds like you didn't get the test returned within 3 days so it was handed back out to someone else. I'm sorry that happened to you on a large prime.

Moral of the story: Make sure that your tests are returned to the server within 3 days. If unsure on machines that aren't connected all of the time, check our server status page for port 1400, which shows how long each test has before it expires.

[QUOTE=gd_barnes;292418]OK, it sounds like you didn't get the test returned within 3 days so it was handed back out to someone else. I'm sorry that happened to you on a large prime.

Moral of the story: Make sure that your tests are returned to the server within 3 days. If unsure on machines that aren't connected all of the time, check our server status page for port 1400, which shows how long each test has before it expires.[/QUOTE]
Also: you may want to consider using LLR (comment out the pfgwexe= line in prpclient.ini to force use of LLR) for non-base-2 testing on your not-always-connected machine(s). It does the primarity proof in a slightly different way, such that it's done at the same time as the PRP test. (Sometimes it has to do some extra steps to finish the proof after the main test, but AFAIK those are checkpointed too.)

[QUOTE=mdettweiler;292425]Also: you may want to consider using LLR [/QUOTE]

Nah, I am faithful to pfgw. It's a more comfy program for me.

Willem.

[URL="http://primes.utm.edu/primes/page.php?id=105904"]1886*67[SUP]177962[/SUP]-1[/URL] is prime

[QUOTE][URL="http://primes.utm.edu/primes/page.php?id=105904"]1886*67177962-1[/URL] is prime [/QUOTE]'

Nice one Mathew:fusion:

[QUOTE=MyDogBuster;294603]'

Nice one Mathew:fusion:[/QUOTE]

I'll second that! :bow:

Welcome to f1pokerspeed. I see you cached about 400 tests. I hope you are using more that 1 core because the tests take about 2 hours each and have a deadline of 3 days. 1 core could possibly handle about 36 tests in that time. The rest will be rejected.

[URL]http://noprimeleftbehind.net:1400/all.html[/URL]

The above link will show you the stats for that particular drive.

What is the sort order for candidates on this server? I'm using it as a backup when my personal server goes down, and I would rather not get any 15+ hour tests at the moment, since I'm pretty quick to get things back up and running. The ones I've gotten so far have taken ~2 hours, but I've gotten a few different bases, so just sort of curious.

[QUOTE=CGKIII;309953]What is the sort order for candidates on this server? I'm using it as a backup when my personal server goes down, and I would rather not get any 15+ hour tests at the moment, since I'm pretty quick to get things back up and running. The ones I've gotten so far have taken ~2 hours, but I've gotten a few different bases, so just sort of curious.[/QUOTE]

It is sorted completely by n-value. It doesn't care about base or k. That keeps all of the search depths for the many bases at the same n-depth. Right now, all bases are at n=~191K although there are some more that will "kick in" at n=200K. Like Ian said, the tests can take up to 2 hours. Therefore I strongly suggest that people cache no more than about 5 tests per core. I only cache 1 test on backup PRPnet servers in case my own is down.

Hum it looks like Pokerspeed must have realized the length of the tests and returned them to the server. Thanks! For this length of tests, we definitely want to avoid having so many tests sit there for several days unless someone has a huge pharm and can do them all. A lot of unnecessary testing might be done on a k that was eventually found prime in a large cache.

Ian or Mathew, is there a way to set a max cache on the server? I'd like to make it about 25 or 50 for this server.

[QUOTE]Ian or Mathew, is there a way to set a max cache on the server? I'd like to make it about 25 or 50 for this server. [/QUOTE]In ppserver.ini there is maxworkunits. It's per client. I've never tested it.