LLRnet servers for NPLB

[Razor_FX_II]

Am i doing something wrong?
I keep getting this on port 9000

1725*2^339056-1 is not prime.  Res64: 1F52B94C7E7360CD  Time : 103.018 sec.
Working on : 1725/339057 (5000000000000:M:1:2:258)
Starting Lucas Lehmer Riesel prime test of 1725*2^339057-1
Using Irrational Base DWT : Mersenne fftlen = 16384, Used fftlen = 24576
V1 = 5 ; Computing U0...
V1 = 5 ; Computing U0...done.
Starting Lucas-Lehmer loop...
Successfully connected to server!
LOGGED ON
LOGGING OUT
The server refused your new result :
either someone else computed it already,
either the server is now configured to
work on other numbers.
The server refused your new result :
either someone else computed it already,
either the server is now configured to
work on other numbers.

Edit: now I'm starting to get it on port 8000 also

[PCZ]

You are probably trying to return results on the wrong port.
What is the result your trying to return ?

If you got work from one port you cant return it on a different port.

[AMDave]

As above:

If you wish to change port then the process goes thus:
1 stop the client
2 change the cache down to 1 (if it was higher)
3 run the client to exhaust the cache until only 1 pair is left (you can observe this in workfile.txt [do not count the top line - that is the search depth setting])
4 stop the client
5 uncomment runonce=1 (true)
6 run the client to complete the last pair after which it will stop and close
7 re-comment runonce=1 and change the port (and cache if you prefer)
8 restart and away you go on the new port

An alternative presentation of this issue is when you have the cache set too large and the pair expires before your client processes it.
You need to keep the client cache low enough that your machine will complete the pairs before they are handed out to another client.
You can check this by looking at the jobMaxTime on the server:
http://stats.ironbits.net/statsnew/n...rver_status_ib
This can be changed by the project admins for various reasons, but usually an advice is given somewhere in the forums when it is going to occur.

Alternatively if you do not want to tinker with the settings too much then just wait for the cache to finish processing.
The error messages will stop when the client runs out of work from the old port and the client will start picking up the new work on the new port.
The pairs that did not get returned to the old port by your client will expire on the server and will get sent out to another client that is still operating on that port.

No worries mate

[Razor_FX_II]

Returned the work on the same port that i got it from.
Both clients that gave me that error were started with no work pending.

first client was configured for port 9000 and second was configured for port 8000, both with these options:
--once = 1
WUCacheSize = 10

I stopped them after a few units error and changed them both to:
--once = 1
WUCacheSize = 1

I then let the workfile.txt run down to a single work unit for each client then changed in both:
once = 1

Both clients finished there work (all worked error) and exited then changed both clients to port 5000 and 4000 respectively with these options:
--once = 1
WUCacheSize = 1

Restarted both clients and they run fine.

Edit: thats funny AMDave - you must type faster then me - you beat me to it. To respect that i must complete them fast enough.. unless they are handing them out to someone else 15 minutes later there is no problem there.

[gd_barnes]

Port 9000 shows that it is awaiting your results on both:

1725 339056
1725 339057

As of 1 PM GMT.

The only way that it should be rejecting them is if you changed the port # before completing the testing of them and returning them to the server.

If you change from port 8000 to port 9000 or vice-versa, after stopping the port that you are currently running, it's easiest just to delete the workfile.txt file before starting on the next port.

The only problem with that is that it won't send the pairs out for re-testing by someone else for 3 days. If you'd like to be kind, you can cancel them by going to the command prompt and typing:
llrnet -c
one time for each pair in your workfile.txt file. After you do that, your workfile.txt file should be empty. Then you can change the port # and start processing on the new port.

If you'd like to complete the current k/n pair(s) that are in your workfile.txt file and not receive any more of them for a port that you'd like to stop work on, you can do the following:
1. Kill the processing in the usual manner.
2. In llr-clientconfig.txt, change the WUCacheSize to 1 (if not already at 1) and change the --once=1 line to remove the dashes.
3. Restart the processing. This will process one k/n pair and stop when it is done.
4. Repeat steps 2 and 3 once for each pair in your workfile.txt file. Obviously if the # of pairs in the file is large, it's best to cancel them using the llrnet -c command. AFAIK, there is no way to tell it to process 3 or 5 or 10 pairs and then stop. It has to be done one at a time.

After the above is done, then change to the new port but MAKE SURE you put the dashes back in the once=1 line (and change WUCacheSize to your desired number). Otherwise you'll only process one pair from the new port. I've had this happen and lost a full day's processing.

I generally avoid the above problems by having separate folders for each port that I work on. That way I never return a pair to the wrong port. But I also always return all pairs to the server after stopping work on a port.

I hope this helps.

Edit: I now see that my post is redundant. I'll delete it later.


Gary

[Razor_FX_II]

Yeah I know better than to switch the port around while they have work so that wasn't the problem.
From now on if there is a problem I'll use the llrnet -c command on them.

Edit: Yes I have a seperate folder for each port: had 4 of them set up in different directories: ports 9000,8000,5000,4000.
Now there are 2x5000 and 2x4000 directories

And if its still waiting for work from me on ports 9000 or 8000 then its not going to get them. My work files are empty

[AMDave]

ps - just on the off-chance you might be running your clients as services on the same machine you'd need to specify different service names for each client running on the same machine
I usually number them like so
serviceName = "nplb_1"
If they all have the same service name then things can go a bit haywire.

But it sounds like you have it under control.

Happy crunching

[Razor_FX_II]

Just checked all 4:
username = "Razor_FX_II"
serviceName = "NPLB1"

username = "Razor_FX_II"
serviceName = "NPLB2"

username = "Razor_FX_II"
serviceName = "NPLB3"

username = "Razor_FX_II"
serviceName = "NPLB4"

Nope that isn't it. But great suggestion.
I really don't think I did anything wrong. I am extremely careful about this stuff. It simply appears to me that the server handed me the wrong work or something.

Is there anyway to check server logs and see if in fact I was returning work on the same port that it was assigned from and if I was then why did the server refuse it?
It's really not that big a deal for me just curious as to why it happened to try to avoid this in the future or possibly there is a problem on the server end.

Edit: Is there anything wrong with my .bat file?

@echo off
start "NPLB-1" /D C:\NPLB\NPLB1 /I /MIN /LOW /AFFINITY 1 cmd.exe /C llrnet.exe
start "NPLB-2" /D C:\NPLB\NPLB2 /I /MIN /LOW /AFFINITY 2 cmd.exe /C llrnet.exe
start "NPLB-3" /D C:\NPLB\NPLB3 /I /MIN /LOW /AFFINITY 4 cmd.exe /C llrnet.exe
start "NPLB-4" /D C:\NPLB\NPLB4 /I /MIN /LOW /AFFINITY 8 cmd.exe /C llrnet.exe

[IronBits]

Script looks just like the Getting Started Guide, http://www.free-dc.org/forum/showthread.php?t=18526
in the section for Vista 64bit/Windows 64bit, so ya done good.

I see you added two switches,
one to Minimize the windows and one to use low priority (which it already does so not needed)
Just like the /I switch, not really important.
You can open a cmd window and type start /?<enter> to see all the switches you can use and the proper way to use them.
The /Affinity switch only works on 64bit OS

Or, you could simply use this basic line
start "NPLB-1" /D C:\NPLB\NPLB1 cmd.exe /C llrnet.exe
Or
start "NPLB-1" /D C:\NPLB\NPLB1 /MIN cmd.exe /C llrnet.exe
and achieve the same thing and minimize the windows, especially with a 32-bit OS.

You can also choose to go into each folder where a client is (easy to do with 2 or 4 cores and a couple of computers) and double click the llrnet.exe
This way you would have an ICON is the System Tray (one for each client) and no DOS cmd windows on the Task bar.

[gd_barnes]

Max,

I have now posted all results from our 1st 3 drives on my machine called Crunchford. They will be in obviously named folders on the desktop. The results that were processed manually are ready for conversion and ultimate loading into the stats database.

To all: This is the start of a huge undertaking to import all manually processed results into our stats database on the entire project.

Next will probably be any manually processed files for the 8th/9th/10th drives followed up by the individual-k drive. The latter should be a fun one!

Max, this will be a difficult and time-consuming task; requiring looking at who did what n-ranges and what ranges the servers have already done. Good luck and may the force be with you!


Gary

[mdettweiler]

Originally Posted by gd_barnes

Max,

I have now posted all results from our 1st 3 drives on my machine called Crunchford. They will be in obviously named folders on the desktop. The results that were processed manually are ready for conversion and ultimate loading into the stats database.

To all: This is the start of a huge undertaking to import all manually processed results into our stats database on the entire project.

Next will probably be any manually processed files for the 8th/9th/10th drives followed up by the individual-k drive. The latter should be a fun one!

Max, this will be a difficult and time-consuming task; requiring looking at who did what n-ranges and what ranges the servers have already done. Good luck and may the force be with you!


Gary

Okay, thanks! I'll get started on it right away.

To all: expect to see various people's scores rise in spurts over time as manual results are added. Even if things may seem to be a little unbalanced for a while in there, rest assured, when all is said and done, the stats will be a true and accurate representation of all the LLR work everyone has ever done on this project.

AMDave, you can expect an email about this sometime within the next day or two (depending on when I get the first batch ready to load up).

Max