Schweet! :smile:

I really would like to know who processed one candidate under my nickname...lol

[quote=em99010pepe;148091]I really would like to know who processed one candidate under my nickname...lol[/quote]
Ah, I think I have the answer to that. :smile: Yesterday I manually inserted the k/n pair shown on the nplb.ironbits.net status page as the lowest remaining k/n pair for port 5000, into my workfile.txt, so that it would get cleaned up faster--since it appeared to have been abandoned, and thus would eventually expire and be reassigned anyway. It appears that this k/n pair must have been assigned to you, because I've discovered that if one user processes a k/n pair that's assigned to another user, it will still be credited to the user it was originally assigned to (assuming, of course, that it was returned within the original user's deadline). This would also explain the very large Time value listed for that result. :smile:

Hey Lennart, a little push to reduce the drive end to 7 days?
596-600 is 70 % completed, more 3 days and I'll put the cores on IB5000 server.

[quote=mdettweiler;148100]Ah, I think I have the answer to that. :smile: Yesterday I manually inserted the k/n pair shown on the nplb.ironbits.net status page as the lowest remaining k/n pair for port 5000, into my workfile.txt, so that it would get cleaned up faster--since it appeared to have been abandoned, and thus would eventually expire and be reassigned anyway. It appears that this k/n pair must have been assigned to you, because I've discovered that if one user processes a k/n pair that's assigned to another user, it will still be credited to the user it was originally assigned to (assuming, of course, that it was returned within the original user's deadline). This would also explain the very large Time value listed for that result. :smile:[/quote]

That's very interesting to know. Thanks for discovering and explaining that. One thing to note: If you happen to discover a prime by doing that, the person whose name the pair is credited to would get to report the prime. Of course that is my opinion only but I base it on the fact that the pair is considered 'reservered' until it is returned to the server. If it ever comes up, I'm sure everyone will 'work it out' in an amicable manner.

That brings up something that would help us greatly: Whenever people stop processing a server or change servers, it would be greatly appreciated if you could clear out your queue (workfile.txt file) in the server that you are currently on, especially if you have multiple candidates in your queue. Here are some instructions for doing it:

If your WUCacheSize is > 1:
1. Kill your current LLRnet process as you would normally.
2. Change your WUCacheSize to 1.
3. Restart LLRnet and let it run until there is only 1 k/n pair left in the workfile.txt file. (You don't need to watch it. It will just keep right on processing 1 pair at a time even after the queue is down to 1.)
4. Kill LLRnet again.
5. Uncomment the --once=1 line by removing the 2 dashes at the beginning.
6. Restart LLRnet. It will process the final pair and then stop.

If your WUCacheSize = 1:
1. Kill your current LLRnet process as you would normally.
2. Uncomment the --once=1 line by removing the 2 dashes at the beginning.
3. Restart LLRnet. It will process the final pair and then stop.

After it is done, be sure and put the 2 dashes back in the once=1 line.

I realize that sometimes people won't have time for this but if everyone will make an effort to at least clear out their queues more often, it will make for less straggling pairs that have to wait 3 days to be reprocessed. There's no use to wait any longer to have a reported prime than we have to. :smile:


Gary

Or you could simply tell the server to cancel your reservations on the remaining pairs by running LLRnet with the -c switch. That is, you open a command window, go to your LLRnet folder, and run "llrnet -c" (or "./llrnet -c" on Linux) until it says "no more k/n pairs to cancel". :smile:

I've only ever tested this on Linux, though; does anyone know if this works on Windows?

[quote=mdettweiler;148148]Or you could simply tell the server to cancel your reservations on the remaining pairs by running LLRnet with the -c switch. That is, you open a command window, go to your LLRnet folder, and run "llrnet -c" (or "./llrnet -c" on Linux) until it says "no more k/n pairs to cancel". :smile:

I've only ever tested this on Linux, though; does anyone know if this works on Windows?[/quote]
Yep, works fine on Windows too. LLRnet probably needs to be killed before you do it though, and any progress will be basically lost (the save file should exist, but it won't finish it off). Plus it means a little less work for NPLB is done. :wink:

[quote=Mini-Geek;148151]Yep, works fine on Windows too. LLRnet probably needs to be killed before you do it though, and any progress will be basically lost (the save file should exist, but it won't finish it off). Plus it means a little less work for NPLB is done. :wink:[/quote]
Of course, I was assuming that LLRnet would be shut down prior to canceling the k/n pairs. (I guess I could have made that a bit more clear, though. :smile:)

What I often do to avoid losing work is to stop LLRnet, then run it with the "-1" option (that's a one, not an L) to tell it to do one k/n pair and then stop--essentially, finish the current k/n pair, return it to the server, and then exit before starting the next one. After that I then proceed with cancelling the remaining unprocessed k/n pairs. :smile:

I had no idea about the -c option. Very good. That's much easier.

[quote=mdettweiler;148167]What I often do to avoid losing work is to stop LLRnet, then run it with the "-1" option (that's a one, not an L) to tell it to do one k/n pair and then stop--essentially, finish the current k/n pair, return it to the server, and then exit before starting the next one. After that I then proceed with cancelling the remaining unprocessed k/n pairs. :smile:[/quote]
Ah, I didn't know about that option. I'll do that in the future instead of watching for it to finish and stopping it before it gets much work done. :smile:

Flags you can use (llrnet.lua):

-h :
print this message

-d :
detach client and run in background

-v :
set verbose mode on

-c :
cancel current work unit

-no-sse2 :
disable SSE2 instructions, may improve performance on athlon 64 CPUs

-1 :
perform just one test

-no-gui :
do not launch the gui