Automated PRP using LLRNet

[axn]

After around 2 weeks of testing, we have an LLRNet server ready for automated PRP testing Thnaks to ltd for setting up the server alongside PSP.

What do you need to do to participate?

1. Download the LLRNet client from http://base5.greenbank.org. The client is currently available only for Windows (EDIT:- As of 15 Oct, we have a linux build out, thanks to arminius). This is a patched version of the official LLRNet build, since we had to make some changes to allow base 5 PRP.

PS:- LLRNet only works on x86 and compatible machines.

2. Extract the zip file to a folder. Edit the llr-clientconfig.txt with your favorite text editor. Change the following lines:

-- server location
server = "www.sr5.psp-project.de"
-- Port for Riesel Server
--port =   12925
-- Port for Sierpinski Server
--port =   12920

-- username
--username = "nobody"

Uncomment the suitable "port" line to connect to either Riesel or Sierpinski queue. Uncomment the "username" line and put your user nick there.

3. Run llrnet.exe! You can open a console window using the tray icon and watch the client chugging away.
[For linux, run llrnet]

4. Watch the stats at http://www.sr5.psp-project.de/


If you need to run multiple instances of the client, just create separate folders and run from there

Since the client has been tested on only a couple of machines, you may face some hiccups. Please post any issues you face here. We'll try to work it out.

Users who are familiar with LLRNet might notice the absence of remotegui.bat. Currently, our llrnet build doesn't support the remote gui functionality. However, we do have a workaround. Please PM me if you need it.

Happy crunching!

[michaf]

Very happy here :)

Having
1) a new computer
2) a new niece
3) and now a new LLRNET :>

so far only three tiny comments:
1) could you please put somewhere on the life/live? stat pages whether I am looking at sierpinski or riesel stats?
2) could you make llrnet verbose make so that I can change the update rate, as in, I might not like the default 10k iterations...
and could you also make it output each line on the SAME line? only when a new number is processed on a NEW line? Better
yet, make it an option too :>
3) how come lowest n untested is at approx 1k for all of them? or is this to do with DC'ing?

thanks, Micha

edit: oh come on... one such numbers isn't so much work... get to 100% so I can see my stats rising :>

[michaf]

First hiccups:

Getting double output lines: see below.
When it starts crunching again, it is fine.

If you need any parts on what I run, please ask what you need


59912*5^100537+1, bit: 200000 / 233456 [85.66%]. Time per bit: 2.955 ms.
59912*5^100537+1, bit: 210000 / 233456 [89.95%]. Time per bit: 2.970 ms.
59912*5^100537+1, bit: 220000 / 233456 [94.23%]. Time per bit: 2.979 ms.
59912*5^100537+1, bit: 230000 / 233456 [98.51%]. Time per bit: 2.981 ms.
59912*5^100537+1 is not prime. RES64: 851E5DA62D683713 Time: 561.030 sec.
59912*5^100537+1 is not prime. RES64: 851E5DA62D683713 Time: 561.030 sec.
Successfully connected to server!
LOGGED ON
[08/29/06 22:49:15]
Result 59912/100537 succesfully sent to the server.
Result 59912/100537 succesfully sent to the server.

LOGGING OUT
Working on : 26798/100539 (1000000000:P:0:5:257)
LLR tests only k*2^n▒1 numbers, so, we will do a PRP test of 26798*5^100539+1
LLR tests only k*2^n▒1 numbers, so, we will do a PRP test of 26798*5^100539+1
Starting probable prime test of 26798*5^100539+1
Starting probable prime test of 26798*5^100539+1
Using generic reduction FFT length 24K

Using generic reduction FFT length 24K

26798*5^100539+1, bit: 10000 / 233460 [4.28%]. Time per bit: 3.022 ms.

[axn]

Originally Posted by michaf

1) could you please put somewhere on the life/live? stat pages whether I am looking at sierpinski or riesel stats?

I'll pass this on to ltd.

Originally Posted by michaf

2) could you make llrnet verbose make so that I can change the update rate, as in, I might not like the default 10k iterations...

Ummm.. Not sure what you mean. If you want to see output at higher frequency, just exit LLRNet, edit llr.ini and change OutputIterations?

Originally Posted by michaf

and could you also make it output each line on the SAME line? only when a new number is processed on a NEW line? Better
yet, make it an option too :>

Interesting. I used to have his problem (multiple lines and double lines), but since a new client_server.lua, this has not been there. Does stopping and restarting LLRNet help?

Originally Posted by michaf

3) how come lowest n untested is at approx 1k for all of them? or is this to do with DC'ing?

That shows the lowest n without a PRP residue. Since the testing started at 100000 for most k's, and our initial testing covered n < 1000, you see the first n higher than 1000 as the lowest untested k. No worries. We'll sort it out soon enough

Originally Posted by michaf

oh come on... one such numbers isn't so much work... get to 100% so I can see my stats rising :>

[ltd]

I will modify the stats pages sometime today to make it more clear if you are looking at riesel or sierpinski.

Lars

[Citrix]

In the stats could you post number of k's left.
Thanks.

[michaf]

Originally Posted by axn1

I'll pass this on to ltd.


Ummm.. Not sure what you mean. If you want to see output at higher frequency, just exit LLRNet, edit llr.ini and change OutputIterations?

Erm... yep, thats the way to go :)

Originally Posted by axn1

Interesting. I used to have his problem (multiple lines and double lines), but since a new client_server.lua, this has not been there. Does stopping and restarting LLRNet help?

No doesn't help

Originally Posted by axn1

That shows the lowest n without a PRP residue. Since the testing started at 100000 for most k's, and our initial testing covered n < 1000, you see the first n higher than 1000 as the lowest untested k. No worries. We'll sort it out soon enough

Ooooh... I'd love to see some quick results :) at n=1000 one prp shouldn't take too long :)

[michaf]

Is it so that, for all k/n pairs we don't have any residues on, we still will want to do them twice?

If not, I think it should be wise to do so.
If so, I think it should be wise to make certain two were done by different computers

[axn]

Originally Posted by michaf

No doesn't help

Bummer!

Originally Posted by michaf

Ooooh... I'd love to see some quick results :) at n=1000 one prp shouldn't take too long :)

Yeah, at that size you spent more time talking to the server than crunching

Originally Posted by michaf

Is it so that, for all k/n pairs we don't have any residues on, we still will want to do them twice?

If not, I think it should be wise to do so.
If so, I think it should be wise to make certain two were done by different computers

Yes, eventually we'll be doublecheching everything. But like SOB, we'll not actively focus on doublecheck until we have some major progress for first time test.

[ltd]

I would suggest that we start to recover residues for all k/n pairs <50000 where we have no information within the database very soon. Lets say when sieving reached 1T for example. Axn1 found lots of missed primes on the riesel side.

We can do this any time we want as it only means one update within the database and one adjustement for the scripts to build a queue large enough.

Lars

[geoff]

I access the internet from a public computer where I have no ability to change the Windows configuration. Is there any way I can run LLRnet? The console says:

LLRnet current status :
Sleeping ...
LLR network client 0.9b7 started
Based on LLR version 3.5.0
Loading library 'win32' ...
winloop thread
LLRMain started
server dialog thread started ...
unknown host www.sr5.psp-project.de
unknown host www.sr5.psp-project.de