mersenneforum.org

mersenneforum.org (https://www.mersenneforum.org/index.php)
-   Raiders of the Lost Primes (https://www.mersenneforum.org/forumdisplay.php?f=87)
-   -   Testing.... (https://www.mersenneforum.org/showthread.php?t=13099)

kar_bon 2010-02-18 16:46

Testing....
 
[center][size=+2]Backgrounds and purposes[/center][/size]

LLRnet is a Client/Server program to calculate primes with LLR.
LLRnet was programmed in 2004-2005 by Vincent Penne in the language LUA. It uses internally the program LLR of Version 3.5 programmed by Jean Penne.

The latest LLR-Version available is 3.8, which is 10%-20% faster than V3.7, with more possibilities in testing different values and less issues in small n-values.

Vincent do not support a newer version of LLRnet, so the idea is to make both (LLRnet and LLR) working together with a script, using the feature for the client/server communication and the speed of the new LLR V3.8!

The LLRnet-client consists of an EXE-file with some other LUA-source files (like Pascal or C), which easily can be edited.


[center][size=+2]First attempts[/center][/size]
The idea was, to skip the primetest in the lua-source by commenting out that line.
So LLRnet will reserve some workunits from the server, saves them in a test-file and quit.
Now LLR take this test-file and do the primetest. After completion the LLR-resultfile have to be converted into the format LLRnet can read. In the next step LLRnet uses the converted resultfile and send it to the server and grabs new workunits again.

That's the (quite easy) theory.

The first small version of the script looked like this:
[code]
1 :start
2 if exist z* goto do_cllr
3 gawk -f do_tosend.awk lresults.txt
4 type lresults.txt >>lresults_hist.txt
5 del lresults.txt workfile.res workfile.txt llr.ini
6 llrnet
7 del tosend.txt
8 :do_cllr
9 cllr -d workfile.txt
10 goto start
[/code]

2 if there is a cllr-savefile, continue the test
3 convert the cllr-resultfile 'lresults.txt' into 'tosend.txt' for submitting with LLRnet
4 append the current results to a history-file
5 delete all not used files (will be written at every call of do.bat)
6 calling LLRnet to receive new pairs and send old results
7 delete the old LLRnet submit-file
9 calling cLLR and testing all workunits in 'workfile.txt'
10 begin from start

[center][size=+2]Downloads[/center][/size]

The current official Version V0.7 can be downloaded [url=www.rieselprime.de/dl/LLRnetV07.zip]here[/url].
The zip contains all files for the latest LLRnet WIN-version 0.9b7 (client and server) and also the scripts and gawk.exe.

A UNIX version of the script will be done by M.Dettweiler.

The package is pre-configured for a local server (127.0.0.1) and with my user name.
To test start the server (llrserver.exe in server-folder) and then run 'do' (in client-folder).
You can interrupt the script by pressing CTRL-C when cLLR is running (testing a pair).
To restart only call 'do' again or cancel jobs by calling 'do -c'.

ToDo: ReadMe.txt for Win-Version to include.

kar_bon 2010-02-18 19:01

[center][size=+2]ToDo list and suggestions for latter versions[/center][/size]

[b]ToDO[/b]:

[strike][b]1.[/b] The choice-command in WIN are different in XP and Vista, so the waiting for reconnecting to the server in the script with the command (waiting for 60 seconds):[code]choice /t 60 /d j >nul[/code]
won't work under XP![/strike]
[color=red][b]Solved on 2010-02-19.[/b][/color]

[strike][b]2.[/b] If the workfile.txt contains > 1 workunits and cllr didn't tested all pairs yet, stopping the script and cancelling with "do -c" will cancel [b]all[/b] reserved pairs! -> only not tested pairs to cancel![/strike]
[color=red][b]Solved in Version 0.7 from 2010-03-06[/b][/color]

[b]Suggestions[/b]:

1. when cancelling, print the pairs in the lresults.hist.txt with date/time.
-> only counting is printed in lresults-hist.txt, which pairs are displayed only on screen

2. make a sound, if script ended (imagine PC is running offline, no/off monitor -> aware when ends)
-> done with a script option the user can set

3. set the LLR-option OutputIterations by parameter to the script
-> done with a script option the user can set

4. manipulate LLRnet options "WUCacheSize" and "once" by seperate script -> stopping LLRnet
-> not needed: 'once' is not used anymore -> cancelling pairs with script is working

5. submitting LLR-timings to server, rather than time between receive-submit in server-results
-> done in Version 0.8

kar_bon 2010-02-18 19:02

[center][size=+2]Test cases[/center][/size]

[b]1.[/b] Receiving workunits from server and server crashes.

[b]2.[/b] Cancelling workunits with LLRnet -c with the script.

[b]3.[/b] Starting script when server dried.

[b]4.[/b] Processing a different type of primesearching (normally k*2^n-1 30000000000000:M:1:2:258), so perhaps twins or Sophie-Germain.

[b]5.[/b] Process different n-values with many cores (stress-test).

[b]6.[/b] Processing small-n/big-k-values with LLR and the conversion script.

kar_bon 2010-02-18 19:03

[center][size=+2]Version history[/center][/size]

2010-03-08 V0.8 cancel all jobs at once in llrnet.lua, submitting LLR-timings to server
2010-03-06 V0.7 cancelling works, new script to clean workfile.txt, new option to set by user
2010-02-21 V0.61 waitloop set before loop, comment out 2 lines in llrnet.lua (grabbing new pair although once=1)
2010-02-20 V0.6 cancel-option works, some more changes in llrnet.lua
2010-02-19 V0.51 using sleep.exe (renamed to waits.exe here) from MS Resource Kit
2010-02-17 V0.5 Option -c to cancel jobs (not working properly)
2010-02-14 V0.4 printing date/time in lresults.txt with set, beep when prime found, 5 attempts if no connection to server, primes.txt only created/added when prime found
2010-02-12 V0.3 Printing found primes in extra file, commenting out in llrnet.exe, date/time in lresults.txt
2010-02-11 V0.2 Error handling included, commented LLRnet-outputs, llr.ini with OutputIterations set
2010-02-10 V0.1 First small version worked

kar_bon 2010-02-18 22:34

CANCEL jobs issue
 
[strike]i'm currently working on the cancel-issue. a first test seems (almost) perfect checked by Max: the reserved pairs were all canceled from/at the server.
one thing: yesterday i've changed the reservation-loop in the lua and now the first pair was written twice in the workfile.txt and also cancelled twice! (seems not possible but it was so).[/strike]


2010-02-20:
first tests with some changes in llrnet.lua the cancel-function seems to work! some more testing needed!

2010-02-21: the version 0.61 now got the fully working code for cancelling reserved pairs.
those were tested by different users without any issue.

kar_bon 2010-02-19 14:02

CHOICE - waiting in script for n seconds
 
Because CHOICE behave different on my XP and Vista box, i will try another tool.

Possibilities:

[b]1.[/b] With PING:
ping 127.0.0.1 -n 60 -w 1000>NUL

waits for 60 seconds.

[b]2.[/b] [url=http://www.microsoft.com/downloads/details.aspx?FamilyID=9d467a69-57ff-4ae7-96ee-b18c4790cffd&DisplayLang=en]Windows Server 2003 Resource Kit Tools[/url]:
sleep.exe

[b]3.[/b] [url=ftp://ftp.microsoft.com/Services/TechNet/samples/ps/win98/reskit/scrpting/SLEEP.EXE]Win98 Resource Kit[/url]:
sleep.exe

[b]4.[/b] [url=http://unxutils.sourceforge.net/]UnixTools[/url]:
sleep.exe

I think, no.3 is the best choice instead of CHOICE! :grin:

[quote=mdettweiler]Confirmed, number 3 works on my Windows XP setup as well. If it was designed for Win98, and works on XP and Vista as well, then it should work on pretty much anything. :smile:[/quote]

With Win Vista it's ok, too, so this tool is used in the Win-Version of the script.
I've renamed it to 'waits.exe' (wait seconds), because there're other tools around named 'sleep' which put the PC in sleepmode! But this is not what we want! :smile:

gd_barnes 2010-02-19 21:29

Karsten,

I need to get a good idea of where we are at in all of this on the Windows client testing. Can you answer the following questions:

1. Please post remaining problems and how they will be resolved.
2. When should I get involved in a Windows test?
3. Can you make all Linux changes except for the script?
4. If no to #3, please post the files/programs changed in Windows.
5. If no to #3, please post the files/programs that are stable right now so that we can begin making changes on the Linux side.

On #2, I'm holding off a little until the files/programs stablize. Once that happens, I can get my new I7 connected and add that to my 2 slow laptop cores for a better test than what I could do before.

#'s 4 & 5 will allow Max or me to start making changes to the Linux client so that we can speed things up a little.

Please don't add any more new features at this point. We want to get this rolled out fairly soon.


Thank you,
Gary

kar_bon 2010-02-20 01:04

[QUOTE=gd_barnes;206109]
1. Please post remaining problems and how they will be resolved.[/quote]
The major problem (oh, wait, the only problem) now is to cancel jobs with LLRnet. to comment out the LLRMain()-call in llrnet.lua is the way i used and my Quad is working fine with this for serveral days now. to cancel jobs with LLRnet i only have to comment out the real primetest-call but this don't work by now. i'm just understanding more in lua and the way the job-queue is handled. i think, i can fix this problem this weekend!

[QUOTE=gd_barnes;206109]
2. When should I get involved in a Windows test?[/quote]
as above, i think this weekend we could test a little bit more.

[QUOTE=gd_barnes;206109]
3. Can you make all Linux changes except for the script?[/quote]
yes. as i mentioned the lua-files for WIN and LINUX are the same so if i got the WIN-version running, this should be no problem for the LINUX-side. but this has to be tested on LINUX also.

[QUOTE=gd_barnes;206109]
4. If no to #3, please post the files/programs changed in Windows.[/quote]
i will upload the new version of the script and all files needed when the above issue is solved.

[QUOTE=gd_barnes;206109]
5. If no to #3, please post the files/programs that are stable right now so that we can begin making changes on the Linux side.[/quote]
for a point of start for Max/you i can upload also the version i'm running the last days.

[QUOTE=gd_barnes;206109]
On #2, I'm holding off a little until the files/programs stablize. Once that happens, I can get my new I7 connected and add that to my 2 slow laptop cores for a better test than what I could do before.[/quote]
sure, a maxload-test should be done, also. i will add my Quad for this test, then.

[QUOTE=gd_barnes;206109]
#'s 4 & 5 will allow Max or me to start making changes to the Linux client so that we can speed things up a little.

Please don't add any more new features at this point. We want to get this rolled out fairly soon.[/QUOTE]

me, too. there're no more features to add, i think. to support some other non-normal uses of that script can be added later.

kar_bon 2010-02-20 09:51

can someone please check, if these pairs have been canceled correctly:

[code]
2001/84577
2001/84579
2001/84619
[/code]

i think, those were not canceled! (find just the error).

so try these:
[code]
2001/84686
2001/84689
2001/84709
[/code]

hope these ok!


further check, if these pairs have been submitted correctly:
[code]
2001*2^84543-1 is not prime. LLR Res64: E10FDBF18C77D779 Time : 7.978 sec.
2001*2^84559-1 is not prime. LLR Res64: AAC6FB72FD70DD13 Time : 7.962 sec.
2001*2^84561-1 is not prime. LLR Res64: 6EC9994879661F83 Time : 8.007 sec.
[/code]

i think, the latter is correct as usual.
if the former is correct (crossing fingers) that would be version 1.0!

thanks

mdettweiler 2010-02-20 18:08

[quote=kar_bon;206155]can someone please check, if these pairs have been canceled correctly:

[code]
2001/84577
2001/84579
2001/84619
[/code]

i think, those were not canceled! (find just the error).[/quote]
These are all listed as "in progress" for user kar_bon.

[quote]so try these:
[code]
2001/84686
2001/84689
2001/84709
[/code]

hope these ok![/quote]
The first one (84686) is listed as "in progress" under user kar_bon. The other two are complete, by user MyDog. (Presumably, they were properly canceled, then reassigned.)


[quote]further check, if these pairs have been submitted correctly:
[code]
2001*2^84543-1 is not prime. LLR Res64: E10FDBF18C77D779 Time : 7.978 sec.
2001*2^84559-1 is not prime. LLR Res64: AAC6FB72FD70DD13 Time : 7.962 sec.
2001*2^84561-1 is not prime. LLR Res64: 6EC9994879661F83 Time : 8.007 sec.
[/code]

i think, the latter is correct as usual.
if the former is correct (crossing fingers) that would be version 1.0!

thanks[/quote]
Yes, all three of those results are present in the results file from user kar_bon.

kar_bon 2010-02-20 22:51

@anyone: please check the server if those pairs were reserved by me and canceled properly:
[code]
2001 94893
2001 94899
2001 94901
[/code]

thanks.

gd_barnes 2010-02-21 00:08

[quote=kar_bon;206211]@anyone: please check the server if those pairs were reserved by me and canceled properly:
[code]
2001 94893
2001 94899
2001 94901
[/code]thanks.[/quote]

Here is what I have in the joblist (all times CST U.S. or GMT-6)
2001 94893:
reserved by kar_bon 16:48:41
canceled by kar_bon 16:49:05
reserved by mdettweiler 16:56:59
solved by mdettweiler 16:57:36
(Checked in results; confirmed completed by mdettweiler 16:57:36)

2001 94899:
reserved by kar_bon 16:48:42
canceled by kar_bon 16:49:06
reserved by mdettweiler 16:57:36
(Max still has it for testing as of this moment at ~18:05)

2001 94901:
reserved by kar_bon 16:48:42
canceled by kar_bon 16:49:07
(At ~18:05, pair has not been handed back out yet.)

All 3 pairs are still in the knpairs file. The only one that should have been pruned out at this point is 2001 94893. I'm sure it will get pruned out within the next 1-2 hours.

As far as I can tell, this looks very good! :smile:


Gary

kar_bon 2010-02-21 00:15

very good!

seems, i got it!

i reserved those pairs and immediatly canceled them and the timings from the server say this, too!

i'll clear some things (additional output and commented lines) and will upload the next hour this new version for more testing.

gd_barnes 2010-02-21 00:38

Excellent! So I don't have to dig back through 30-40 PM's, can you provide that link to the Windows client again?

Will you have the changes for the Linux client (except the script) ready tonight? If not, I understand. If so, can you provide a link for that one too?

This is exciting! :smile:

kar_bon 2010-02-21 01:02

new version V0.6 uploaded, for download see post #1 first link: cancel-option in Win works fine!

mdettweiler 2010-02-21 02:24

[quote=gd_barnes;206216]Will you have the changes for the Linux client (except the script) ready tonight? If not, I understand. If so, can you provide a link for that one too?[/quote]
I've been working on the script throughout the day and have a mostly working version at this point. I should be able to finalize it tonight. BTW, as for the Linux version of the modified client, I believe all the substantial modifications are in the .lua files, right? If so, then all we have to do is swap those in and they'll work with the existing Linux client.

kar_bon 2010-02-21 02:25

[QUOTE=mdettweiler;206223]I've been working on the script throughout the day and have a mostly working version at this point. I should be able to finalize it tonight. BTW, as for the Linux version of the modified client, I believe all the substantial modifications are in the .lua files, right? If so, then all we have to do is swap those in and they'll work with the existing Linux client.[/QUOTE]

correct!

gd_barnes 2010-02-21 05:43

OK, I did a fairly extensive Windows test with 4 cores on a new I7 with the following conditions:
1. Set the cache to 25 pairs on 4 cores.
2. Ran all 4 cores for 15-20 mins.
3. Hit ctl-C to stop on all of them.
4. Ran do -c to cancel all of the pairs.
5. Changed cache to 3 pairs on 4 cores.
6. Ran all 4 cores for 5-10 mins.

After I read the thread a little closer and used the do -c command instead of llrnet -c to cancel the pairs, everything looked excellent!

I now have just one concern and a nitpick:

Nitpick:
When hitting Ctl-C to stop the client, it should stop right away and not ask another question. As it is now, it asks you if you want to with: "Terminate batch job (Y/N)?". I don't believe any other version of LLRnet or PRPnet that I'm aware does this so I just thought I'd bring it up. It is something we could live with but a real novice user would be somewhat confused by the question.

Concern:
When you run do -c, it appears to cancel ALL pairs that are in the cache. This means that pairs already processed and sitting in lresults.txt waiting to be sent to the server appear to be ignored and that testing will be potentially lost if you don't start the same client up again in the near future. This also means possible rejected pairs either by you or someone else since the pairs have been sent back to the server for reprocessing.

Am I understanding everything right with the concern?

Excellent work Karsten! I particularly like the primes file in the main directory one level above the clients. Very cool! :smile:


Gary

mdettweiler 2010-02-21 06:09

[quote=gd_barnes;206232]Nitpick:
When hitting Ctl-C to stop the client, it should stop right away and not ask another question. As it is now, it asks you with you if you want to with: "Terminate batch job (Y/N)?". I don't believe any other version of LLRnet or PRPnet that I'm aware does this so I just thought I'd bring it up. It is something we could live with but a real novice user would be somewhat confused by the question.[/quote]
That's a built-in function of Windows' batch file processing engine. Sometimes Windows will just go right ahead and not ask, though most of the time it will, and I don't believe there's anything you can do about it. :mellow:

In other news: I have a mostly working Perl script that has passed a decent amount of testing on my dualcore. (There's still a few more scenarios I'd like to test, though, before posting it, including a test on an actual Linux machine. All the testing I've done so far has been on Windows/Cygwin.)

The only thing that doesn't work is the cancellation mechanism. I tried to implement it from the get-go based on my earlier suggestion to Karsten of generating a tosend.txt file myself, then submitting it with LLRnet, but it wasn't working too well. For whatever reason, it kept messing up big time and instead of canceling a job, it would just throw it out the window and grab a new one. :confused: I ended up throwing the whole subroutine out the window and tried to have it just use "llrnet -c" instead as a bare-minimum option, but even that didn't work. It's too late for me to do any more work on it today, but tomorrow I'll try it with Karsten's latest LLRnet modification, which should work that way. I should be able to implement it successfully in a manner similar to how Karsten did it.

P.S.: One thing I've been planning to address (before Gary mentioned it in fact) was his concern about pairs being canceled even if they have results already completed for them. That shouldn't be too hard as long as I can get the actual cancellation working properly.

gd_barnes 2010-02-21 06:32

[quote=mdettweiler;206233]That's a built-in function of Windows' batch file processing engine. Sometimes Windows will just go right ahead and not ask, though most of the time it will, and I don't believe there's anything you can do about it. :mellow:

P.S.: One thing I've been planning to address (before Gary mentioned it in fact) was his concern about pairs being canceled even if they have results already completed for them. That shouldn't be too hard as long as I can get the actual cancellation working properly.[/quote]

Great on getting close on a working Linux client! :-)

That's typical Windows for you. Forcing something on you that you cannot get around or that is very difficult to get around.

I think the best way to address the straggling results that get canceled issue is to not address them at cancellation at all. They should be addressed when processing is stopped. So if you hit Ctl-C, I think the client should right away send all completed pairs as processed to the server. Logically, it would go something like this:

1. Ctl-C is hit with a response of "Y" subsequently pressed.
2. Pairs in lresults.txt are converted to LLRnet format and sent to the server.
3. Pairs in lresults.txt are moved to lresults_hist.txt and removed from workfile.txt.


If you think about it, that's the way it should happen. If someone stops LLRnet in order to run something else for a few hours or to shut the machine off for the night, LLRnet should send everything already processed, even though the current batch is not done yet.

By doing this, it completely separates the issue from the cancellation of pairs. In effect, it's an issue completely separate from it that can be addressed on its own.

BTW, I could "kind of" fudge my away around the issue although the possibility of rejected pairs would still exist. It would just be very small. Here is what I would do:
1. Stop the client with Ctl-C.
2. Change the cache to 1.
3. Cancel all of the pairs with do -c.
4. Quickly after #3, restart the client.

Almost immediately after restarting in #4, it would send all pairs in lresults.txt to the server, move them to lresults_hist.txt, and request a single new pair immediately after that. I would then stop the client and cancel that one final pair with do -c. Everything got sent, nothing was lost, and all unused pairs were returned to the server. There was only a miniscule chance that there would be a rejected pair somewhere in there. It doesn't take long and is a few hoops to jump through but wasn't bad for 4 cores. But it's a matter of magnitude. I certainly don't want to be doing it on 30-50 cores at any one time so I hope we can automate the sending of fully processed pairs to the server right away when a client is stopped.


Gary

MyDogBuster 2010-02-21 06:37

I've tested everything locally using my own DB and cannot bust it. Nice work Karsten. I have NO nitpicks. LOL

The only problem I see in the future is if a newer version of LLR is released.
That would require changing LUA files and could get messy. I guess as long as you specify what version of LLR the scripts work with, it won't be all that bad.

I especially like the very low amount of output verbage. I don't have to read War and Peace to find something. It's also neat that the #1 test is offset in the results file showing where a server communication began. Also, that primes.txt file 1 level up is really nice.

5 gold stars for Karsten

Edited: I didn't test the do -c so I'll attack that in the AM. I agree with Gary. If there is a way to process all completed pairs when ctrl-c is hit, then that is the best scenario.

mdettweiler 2010-02-21 07:35

[quote=MyDogBuster;206235]The only problem I see in the future is if a newer version of LLR is released.
That would require changing LUA files and could get messy. I guess as long as you specify what version of LLR the scripts work with, it won't be all that bad. [/quote]
Actually, that shouldn't be a problem at all. The only changes Karsten made to cllr.exe were cosmetic (removing a couple extra output lines); I've verified that the stock version of cllr does indeed work just as well. Thus, when new versions of LLR are released, we should be able to just swap them in without a problem.

@Gary: good idea about sending the results first of all regardless. I'll have to give some thought to how to implement that. Actually, though, that might be better saved for the 1.0 version; considering as how my script should be able to do at least everything that standard LLRnet can do without having that feature, and you'd like to have this tested and released before you leave town Tuesday, it should be OK to get it out like this (especially alongside Karsten's version which doesn't have that feature either).

kar_bon 2010-02-21 09:11

@all here.

some notes to the above posts:

1.
the problem with the -c option that completed pairs in the current run will canceled, too -> read post #2.
i'm aware of this and will solve this soon, should'nt be too hard.

2.
as Max said, WIN handles CTRL-C as it is: asking the user break the batch.
i'll search for this, but i think, too: there's no chance to suppress it.

here're a suggestion, how to handle:

export the cancel-option in a seperate batch for submitting the pairs done and cancelling the others.

3. a newer cLLR version:
you only have to exchange the cllr.exe in the folder and all will as it is (until Jean won't change for example the standard output-filed name 'lresults.txt').
if you do so without patching the new exe, there'll only be 2 lines of output more:
a) V1 = ... ; Computing U0...done.
b) Starting Lucas Lehmer Riesel prime test of...

so nothing to concern about!

any other suggestions?
i got one: protocolling the pairs canceled in the lresults-file (and then history!):
the awk script to convert the lresults file into the tosend-file only will process lines with the word 'Time' in it (-> testing time of a pair). so this could be done easily, too:
output in the lresults like:

[2010-02-21 1:28:15] 5000000000000:M:1:2:258 985 748099 was canceled!

other things to do? anyone?

Karsten

kar_bon 2010-02-21 11:30

new version with these changes:

1.
altough i set
[code]
WUCacheSize = 0
once = 1
[/code]
in the llr-clientconfig.txt, LLRnet reserved one new pair!

-> 2 lines in llrnet.lua (in function Work()) commented out:
[code]
-- print("Requesting new job from the server ...")
-- t, k, n = GetPair()
[/code]

2.
in do.bat the loop, when no connection was found, was endless!
-> set the waitloop-counter [b]before[/b] the loop:
[code]
set /a waitloop=0
:do_llrnet
llrnet
[/code]

the new version is online!

to the CTRL-C issue:
1. with BREAK ON/OFF the user can cancel this is DOS, but not in WIN!
2. think about: you started a batch you could never break?! that makes no sense!
every dos-command can canceled by CTRL-C and the errorlevel can be determined.

with the above:
- "edit" WUCacheSize and once in llr-clientconfig.txt so LLRnet will stop and the script stops after the loop.
this "edit" could be done by a small batch which set those 2 parameters as needed (and of course back again!).

suggestions?

what bout this:
a new option for the do.bat, say '-x'
-> submit all work done (lresults.txt contains results) and cancel the other reserved jobs (and clear the folder from the temporary files, sure!).

mdettweiler 2010-02-21 14:38

@Karsten: Great! Those additional changes to LLRnet should prove rather helpful when I try again to implement -c (probably later today).

kar_bon 2010-02-21 15:05

batch to set 'WUChacheSize' and 'once'
 
here is an option to 'edit' per batch the entry "WUChacheSize" in the llr-clientconfig.txt:

[code]
if exist llr-clientconfig.new del llr-clientconfig.new
if exist llr-clientconfig.bak del llr-clientconfig.bak
type llr-clientconfig.txt | find /v "WUCacheSize" > llr-clientconfig.new
echo WUCacheSize=0%1>> llr-clientconfig.new
ren llr-clientconfig.txt llr-clientconfig.bak
ren llr-clientconfig.new llr-clientconfig.txt
[/code]

make a batch-file called "setWU.bat" and call it with 'setWU 10' and this option will be changed to 10 in llr-clientconfig.txt.

the same could be done with the option 'once' (or perhaps both at once).

only some checking in the script makes it complete (like value to high or no number).

advantage:
- the user can make his own batch for setting a number, say
call a batch which contains "setWU 10" and name it wu10.bat, a call with wu10 makes it easy as can be.
- this batch (edit the llr-clientconfig.txt) could be done, when the do.bat is running (during the LLR-test) without stopping do.bat!

Note:
if you try
echo WUCacheSize=%1>> llr-clientconfig.new
(without leading zero) and the parameter is 0, the command will not work!?

gd_barnes 2010-02-21 17:20

Please be careful about adding any more new features. The only very small issue that we had was that it would return already processed pairs to the server when canceling them. But even that could be ignored for the time being.

The reason why is that we have a huge stress test that I would like to run late Sunday or on Monday if possible. To do that, the Linux client has to be stable and ready to go. I don't want to be too concerned about the above one small issue because it takes a long time to update software on 30-50 cores. (That's why I'd get so frustrated with Rogue and his multiple releases of PRPnet and PFGW.)

In other words, I'd prefer that:
1. We not add any more new features right now.
2. We stabilize the Windows client.
3. Create an equivalent Linux/Unix client.
4. Test the heck out of the Linux client including full stress testing.
5. Contact most of our loyal searchers so that they can start using the new clients.
6. Add the new features to the Windows client within 2-3 days.
7. Test the new features in #6.
8. Add the equivalent new features to the Linux client.
9. Test the new features in #8.

One more thing: New software should not be rushed to the public without proper testing. If the Sunday night or Monday time frame that I'm suggesting is too much of a rush, then we shouldn't attempt to complete it so quickly, with or without any more new features.


Gary

kar_bon 2010-02-21 17:39

ok, agreed.

a new option for changing WUCacheSize/once or handling the cancel/undone pairs are not needed yet and can handled manually if needed.

so the stress-test will be done with the latest version V0.61, right?

as Ian said, he got no issues on his private server with the WIN-client.

give a signal to start this test and for WIN i can contribute, too, than.

MyDogBuster 2010-02-21 20:52

[QUOTE]as Ian said, he got no issues on his private server with the WIN-client.[/QUOTE]

Also, I tested do -c and that is also okay by me. As an old(er) legacy programmer like Gary, I totally agree with his approach to testing and releasing. We both spent way too much of our lives debugging features that could have waited. It's best to introduce a solid fully tested program and THEN add features. It will make life much easier in the long run. Besides, some of the best features I ever added on a program were suggested by users running a well tested base program.

kar_bon 2010-02-21 22:17

just a clue:

i'm edititng from time to time the first few posts, to be on the actual state of the art so be sure to read them, too.

gd_barnes 2010-02-22 00:25

You guys will have to do a Windows stress test. I could only put 4-6 cores on Windows at the most.

Do we want to do the Windows stress test before we create a Linux client?

kar_bon 2010-02-22 01:39

i don't know how much Ian has tested on his own server?
which workload? how much clients running? how much workunits reserved at what n-range?

Ian, can you please post here some more details.

mdettweiler 2010-02-22 05:39

Behold: the long-awaited Linux/Perl version of the script is ready! :w00t: I've tested it somewhat heavily on a Windows machine, though I haven't yet tested it on Linux. I'm pretty sure it will work, though; there's not really any OS-specific code in there and it works great on Windows. Gary and Ian, feel free to stress test the heck out of it. :smile:

Here's download links for Windows and Linux versions. The only difference between the two is which OS the LLR and LLRnet binaries are compiled for; swap those out and you can quite easily turn one into the other. :smile: All necessary instructions are included in readme.txt.
Windows: [URL]http://www.noprimeleftbehind.net/downloads/llrnet-script-perl-0.61-win32.zip[/URL]
Linux: [URL]http://www.noprimeleftbehind.net/downloads/llrnet-script-perl-0.61-linux32.zip[/URL]

kar_bon 2010-02-22 06:54

you can delete the "do_tosend.awk" in your distribution!

gd_barnes 2010-02-22 07:22

Outstanding and fast work Max! I can feel it. The end of our long, tortured wait is nearing an end for a server that will run a more up-to-date version of LLR.

I'm beat tonight and am going to bed shortly but my Monday afternoon will be dedicated to attempting to break it in every way possible. I'll also fiddle around by loading different size tests in the server. I may even set up a 2nd test server to make it easier to go back and forth between the 2. I'll probably load some super small n=5K or 10K tests in there and run a gob of cores on it just to see what happens. :-)


Gary

MyDogBuster 2010-02-22 07:31

[QUOTE]
Ian, can you please post here some more details. [/QUOTE]

I ran some CRUS stuff thru a test. 4 cores - range was from n=2.5K to n=10K about 9500 tests in all. I had 2 cores doing 5 tests each in a cache and the other 2 cores doing 100 tests each in a cache. I stopped them many times and restarted them with no problems. I even made sure I had 2 cores looking for work at the same time. I even tested all 4 error messages at the end of the script and each message showed up when it should have and the tests restarted where they should have. Found 3 primes and ran them against PFGW to verify.

I also ran about 1500 tests against the NPLB setup that came with the download. There I had a cache of 100 tests. Even found a prime on that one.

At the present time I don't have any cores available to test anymore. I'm trying to cleanup my CRUS stuff so that I can go back to NPLB and the upcoming k>300<400 drive. Time to go prime hunting again.

kar_bon 2010-02-22 08:12

@Ian:
thanks for the information and an amazing wide range of testing. thanks.

@Max;
i had a closer look to you WIN-perl script.
if i understand perl correct, the function checkForPrimes will write found primes in the dedicated file when $individualPrimeLog = true. but you test to if($line != "") so if i'm right every time (workfile.res exists when cllr is done but if no prime is found, contains only the header line!) the header will be backuped, too!
i've not tested it running yet, but will do today.
nice quick work!

mdettweiler 2010-02-22 15:21

[quote=kar_bon;206329]@Max;
i had a closer look to you WIN-perl script.
if i understand perl correct, the function checkForPrimes will write found primes in the dedicated file when $individualPrimeLog = true. but you test to if($line != "") so if i'm right every time (workfile.res exists when cllr is done but if no prime is found, contains only the header line!) the header will be backuped, too!
i've not tested it running yet, but will do today.
nice quick work![/quote]
That's what this is for a few lines earlier:
[code] # Open workfile.res and throw out the first line (the NewPGen header) - we don't need it
open(RES, "workfile.res");
$foo = <RES>;[/code]
It reads the first line of workfile.res to the variable $foo, which isn't used later.

Meanwhile, I just uncovered an actual bug: looking at the if($line != "") part (which is intended to copy off any line in workfile.res after the header that isn't blank), I see that it should be if($line ne "") instead (you use eq and ne instead of == and != for strings in Perl). It's been a little while since I last used Perl for anything big, as you might have noticed. :wink:

I'll have a fix online in a moment.

Edit: I've uploaded the fix, same places as before. Note that this prime-logging code is one area that I haven't been able to test, so be prepared for possible errors. If I can I'll do some additional testing of my own on it today.

kar_bon 2010-02-22 18:01

so when will we start a major test?

say 10000 kn-pairs with one third at about n=5k,100k and 500k or something like this and many primes, too.
other testcase: at rieselprime, there's a file with all primes. what about a piece of that.
what about testing for twins: different header not tested yet with the script!

mdettweiler 2010-02-22 19:14

[quote=kar_bon;206369]so when will we start a major test?

say 10000 kn-pairs with one third at about n=5k,100k and 500k or something like this and many primes, too.
other testcase: at rieselprime, there's a file with all primes. what about a piece of that.
what about testing for twins: different header not tested yet with the script![/quote]
Agreed, all of those would be good test cases. Gary, what do you say we try to do a big test later today with all of those worktypes? We could load them all in together (under the twin header, to test that).

We've already tested Karsten's batch script quite a bit, though it surely won't hurt to test it more. I'll test both it and my Perl script on my Windows box here.

gd_barnes 2010-02-22 19:50

OK, guys, here's the timeframe:

It's 1:45 PM CST here now. I've had a good night's rest and am going to go eat some breakfast now. :-)

At about 2:15 PM I'll start copying the latest client to all of my Linux machines. I've got the equivalent of about 3 Linux quads on CRUS right now so I won't bother those for now. But that still leaves 8 Linux quads for this test. This process will take take about 30 mins.

So at ~2:45-3 PM, it will take me ~20-45 minutes to set up the servers with the proper test cases. I'll also create a 2nd test server for this, which will save quite a bit of time and allow specific situations to be tested more easily if there is a problem with one of them.

So the bottom line is that I'll start the cores up around 3:30 PM CST. That would be around 10:30 PM in Germany.

Nice work on the test cases Karsten. That's exactly what I like to see. I will be testing every one of those situations. I'll put something like 60-70 primes at the beginning of one of the tests so that each core is likely to get more than one prime. I want to see it write to the prime file with more than one prime per core all combined into one big primes file on a machine. That will be interesting. It's important that it works if primes come in from 2 different cores at the same time. I don't want to see it overlay itself if that happens and inadvertantly drop a prime.


Gary

gd_barnes 2010-02-22 20:28

[quote=mdettweiler;206313]Behold: the long-awaited Linux/Perl version of the script is ready! :w00t: I've tested it somewhat heavily on a Windows machine, though I haven't yet tested it on Linux. I'm pretty sure it will work, though; there's not really any OS-specific code in there and it works great on Windows. Gary and Ian, feel free to stress test the heck out of it. :smile:

Here's download links for Windows and Linux versions. The only difference between the two is which OS the LLR and LLRnet binaries are compiled for; swap those out and you can quite easily turn one into the other. :smile: All necessary instructions are included in readme.txt.
Windows: [URL]http://www.noprimeleftbehind.net/downloads/llrnet-script-perl-0.61-win32.zip[/URL]
Linux: [URL]http://www.noprimeleftbehind.net/downloads/llrnet-script-perl-0.61-linux32.zip[/URL][/quote]


OK, I'm a little confused. Will we be using Karsten's or Max's script for the Window's client? Regardless, I'll only be testing the Linux client this afternoon.


Gary

kar_bon 2010-02-22 20:36

i think there's one reason a prime would not be written in the general primes.txt:

if one client found a prime and writes it into that file it will be locked and a second client found a prime the same moment could not write the same file: perhaps an error like 'file not found' should occur.
i'm thinking of a later optimization about the primes.txt:
show the client in that file,too!
how to: the llr-clientconfig.txt contains an option 'serviceName' and i named them like "LLRnet-G 995x" with x the number of the core/client. so the primes.txt looks like:

[2010-02-18 00:25:38] LLRnet-G 9951 found 2001 58406

i'm with the test with my Vista Quad. hope all test are positive, so we can provide it to our standard users (not much by now, but if this works, perhaps there'll be more again).

kar_bon 2010-02-22 20:39

[QUOTE=gd_barnes;206385]OK, I'm a little confused. Will we be using Karsten's or Max's script for the Window's client? Regardless, I'll only be testing the Linux client this afternoon.
[/QUOTE]

i think, we should test all 3 versions! i'm with the normal DOS-script.
the reason i used this: perl has to be downloaded and installed first, an the customizing could call others errors a non-expert user could not handle!
so the normal DOS-version is ready to go on WIN-platforms without any external programs!

gd_barnes 2010-02-22 21:10

I'm getting more confused by the minute but I'll just push forth.

Unfortunately guys, you're going to have to completely ignore my prior timeframes. They were applicable only if I encountered no confusion but I immediately am having a problem with the Linux client.

This is on Jeepford only with the cache set to 5. I haven't tried the others yet.

1. When I type:
./do.pl
at the command prompt, I get:
[code]
bash: ./do.pl: /usr/bin/perl^M: bad interpreter: No such file or directory
[/code]2. When I type:
perl do.pl
at the command prompt, I get:

[code]
(general greeting message) followed by:

llr-clientconfig.txt.3: unexpected symbol near "="
llr-clientconfig.txt.3: unexpected symbol near "="
llr-clientconfig.txt.3: unexpected symbol near "="
llr-clientconfig.txt.3: unexpected symbol near "="
llr-clientconfig.txt.3: unexpected symbol near "="
Error: could not connect to server after 5 tries.
Most likely there is a problem either with your connection or the server.
Sleeping 60 seconds.
[/code]Jeepford has been running LLRnet on gb port 6000 so I know its connection is good.

I'll look into a little more but I just wanted people to know it's going to be a while before I get the real test cases loaded into the server and even longer before I get all machines going.

Max, on more thing. I don't see how you could truly test a Linux client on a Windows machine. The executables (binaries) are entirely different except for the Perl script. I would have thought that you would have used one of my quads to test it. I'm mentioning this because the above errors appear to be related to the fact that it was not tested on a Linux machine. (sorry if I'm wrong; just a feeling) I read the README but I can't see anything that I missed.

Assuming that I get these problems on a 2nd machine, I'm going have to ask that Max run a test on a Linux machine before I load it on any more of my machines.


Gary

kar_bon 2010-02-22 21:15

check this:
in Unix the textfiles are formatted different than in WIN: CR versus CR+LF!

username properly set?
LLRnet will quit when user is nobody!

gd_barnes 2010-02-22 21:43

I thought the same thing Karsten but haven't found that makes any difference.

BUT...I did find my problem. I had assumed that Max put a server in there. It was left blank causing the bad unexpected symbol near "=" message. I could not figure out where that was coming from right away. I completely missed it so my bad. When I put in 9950, it worked.

That said, it only worked with the command:
perl do.pl

But still gave the same error message about a bad command or interpreter when I tried:
./do.pl

Max, I checked that Perl is in the appropriate usr/bin directory. I also checked that the properties allow the do script to be executed as a program. Is there some other setting that needs to be tweaked on my machines? I've actually run Perl scripts before on my machines using that structure of command with no problem. I think that most experienced Linux users will expect the ./do.pl command to work.

I'm loading it onto the lion's share of my machines now. After that, I'll then set up the appropriate test cases in the servers.

kar_bon 2010-02-22 21:50

that's why i used 'standard' DOS-batch in WIN! gawk and wait are small programs without any setup.

when the servers ready, give the server/port details!

gd_barnes 2010-02-22 22:32

OK, after various interruptions from "real life", I have all of the clients on my machines. I'm working on the servers now.

Karsten, the ports will be 9950 and 9975.

I'll let you know when they are ready to go.

I will shut down 9950 shortly so that I can reload it with some different stuff.

gd_barnes 2010-02-22 23:18

OK, guys I have ports 9950 and 9975 loaded with various misc. tests.

Note on 9950: I've deleted all previous pairs and emptied out the joblist.txt. If you try to return a pair from before, it will be rejected. My suggestion is to delete your workfile.txt and tosend.txt files and begin anew.

Port 9950 has:
A whole bunch of small primes (I've already tested those; see problem below.)
A bunch of k=3 thru 99 pairs for n=5000 to n=7500.
A bunch of n=100K-120K tests.

Port 9975 has:
Essentially what is in the 11th drive. A bunch of n=~540K pairs.

Port 9950 is the stress test port.

Max, on your primes.txt file, it is in the incorrect place. It needs to be one level above the clients like what Karsten has. As it is, you would still have to look in all of your cores to see the primes. With the way Karsten has it, you would only have to look once per machine, regardless of the # of cores.

Sure got a lot of beeps...that's good. I put a lot of primes in there.


Gary

mdettweiler 2010-02-22 23:25

Okay, there's been way too many messages here since I last checked the forum for me to respond to each one individually, so I'll try to summarize:

@Gary: Both scripts should work on Windows equally well, but since Karsten's only uses bult-in Windows functions (as opposed to mind which requires Perl), I expect that his will be more readily usable for most Windows users. Mine's primarily targeted at Linux setups, where Perl is commonly available.

The reason why ./do.pl doesn't work is not entirely clear to me at this moment; obviously the privileges are set properly since it's at least attempting to interpret it, but something's amiss with the first line of the file. At any rate, though, don't worry about it; "perl do.pl" will always work, so if I can't get the problems with ./do.pl figured out in short enough order I'll just change that part of the documentation.

BTW, as for the stuff that needs to be configured in llr-clientconfig.txt: it's all right there in the documentation. :wink:

About how the client behaves when it finds a prime: yay, the beeps worked! :w00t: (Those don't work on my setup so I couldn't test them.) As for the primes.txt file being in the same directory, that's in the documentation too. :wink: My script has the option to do it either that way, or in the parent directory like Karsten's script does.

gd_barnes 2010-02-22 23:45

Max,

I read the documentation but it was so long that I missed the part about where the primes would be written. :) Cool option. Gonna have to remove some of the "fluff" there. Regardless, nice work on all of the details. Sorry I missed that one and the fact that the clients didn't already have the port in them.

OK, I found what appears to be a "real" problem:

When the server is offline and you try to start a client, it just sits there with a few cryptic messages and won't exit to the command prompt. Multiple attempts at hitting Ctl-C wouldn't cause it to properly exit. It took 3 kills from the system manager to finally really kill it. That's probably something that needs to be looked into.

I have 31 cores running port 9950 right now.

Unfortunately I gotta go now and will be way for about 5 hours.

Max, can you check port 9950. My 31 cores are blowing through it. It may need to be reloaded with some stuff. Not sure what at this point.

Also, can you load up NPLB port 6000? It's running a little low. It would be critically low if my cores weren't pulled off of it right now.

Sorry, gotta run but my cores will be on 9950 for the next few hours.


Gary

mdettweiler 2010-02-23 00:14

[quote=gd_barnes;206420]Max,

I read the documentation but it was so long that I missed the part about where the primes would be written. :) Cool option. Gonna have to remove some of the "fluff" there. Regardless, nice work on all of the details. Sorry I missed that one and the fact that the clients didn't already have the port in them.

OK, I found what appears to be a "real" problem:

When the server is offline and you try to start a client, it just sits there with a few cryptic messages and won't exit to the command prompt. Multiple attempts at hitting Ctl-C wouldn't cause it to properly exit. It took 3 kills from the system manager to finally really kill it. That's probably something that needs to be looked into.[/quote]
Okay, I'll look into it.

[quote]I have 31 cores running port 9950 right now.

Unfortunately I gotta go now and will be way for about 5 hours.

Max, can you check port 9950. My 31 cores are blowing through it. It may need to be reloaded with some stuff. Not sure what at this point.[/quote]
I just looked at it and it's at about n=153K on k=2009 (which appears at first glance to be the only k loaded in for that range). My guess is that it will last for the 5 hours until you get home and can make a decision as to what to put in there after that. I'll keep an eye on it, though; if it runs out, I've got a sieve file of smallish base 3 numbers that I use for testing PRPnet that I can load in there. That would be quite an interesting test, though the server would have to dry before I could load it due to the change in NewPGen header.

Of course, that's assuming I can even find the base 3 file on my hard drive somewhere...it seems to have gotten lost. Oh well, if I can't find it then I'm sure there's plenty of base 2 stuff I could come up with.

[quote]Also, can you load up NPLB port 6000? It's running a little low. It would be critically low if my cores weren't pulled off of it right now.[/quote]
Okay, I'll do that later today if I get the chance. (If it isn't done by ~1 AM your time tonight, go ahead and load it yourself. :smile:)

kar_bon 2010-02-23 03:31

just getting an error after k=2009 at port 9950 is done:

llrnet.lua:80: bad argument #3 to `format' (string expected, got nil)

the line is

print(format(" Fetching WU #1/%d: %s %s",WUCacheSize,k,n))

so k/n is empty!

no pairs? other header in the server?
restart brings up the same error!

the script ended after 5 retries to getting a new job from the server but this error in llrnet.lua i have to look at then!

about 1650 pairs were done with WUCacheSize=2 without error!

it's 4:30 AM here and only woke up 20 min ago and thought i should look at the test!
and nobody else is online :-(

where're the admins when they needed! i think we have to talk about this :mad: :grin:

i have to go to bed again. up again in 3 hours!

mdettweiler 2010-02-23 05:20

[quote=kar_bon;206426]just getting an error after k=2009 at port 9950 is done:

llrnet.lua:80: bad argument #3 to `format' (string expected, got nil)

the line is

print(format(" Fetching WU #1/%d: %s %s",WUCacheSize,k,n))

so k/n is empty!

no pairs? other header in the server?
restart brings up the same error!

the script ended after 5 retries to getting a new job from the server but this error in llrnet.lua i have to look at then!

about 1650 pairs were done with WUCacheSize=2 without error!

it's 4:30 AM here and only woke up 20 min ago and thought i should look at the test!
and nobody else is online :-(

where're the admins when they needed! i think we have to talk about this :mad: :grin:

i have to go to bed again. up again in 3 hours![/quote]
There seem to be quite a number of candidates in the server, though perhaps they just haven't been pruned yet. Gary, I'm guessing you're home by now; I'll leave it up to you to decide what to load in there next.

gd_barnes 2010-02-23 06:02

Just got home now. Looking at things now.

Sorry you missed all the admins online when you were on a couple of hours ago Karsten. I was on for 3-1/2 hours this afternoon and will be on for another 3 hours now.

Max, this pruning thing is really starting to bother me but I think it's something that's existed in LLRnet for a long time. It seems that it takes far longer to prune pairs than it should.

Anyway, here is what I'm not understanding:
1. The first few pairs of the file that were all small primes for k=3 (n=1K-10K primes) were shown as immediately rejected by the client.
2. When I look in the rejected file on the server for the rejected client results in #1, they aren't there.
3. When I look in the regular results on the server for the rejected client results in #1, 1 out of 5 of them ARE there.
4. When I look in joblist.txt for the rejected client results in #1, 4 out of 5 of them ARE there.

The rejected client pairs are:
3 1274
3 3276
3 4204
3 5134
3 7559

Pairs still in joblist.txt and knpairs.txt:
3 3276
3 4204
3 5134
3 7559

Pair in results.txt on the server:
3 1274

So for some reason, the server wouldn't "take" 4 out of the 5 small k=3 primes results.

Please note that these are NOT In the rejected SERVER pairs. They only show as rejected on the client.

I think what I'm going to do is stop the server, clear everything out completely, and reload the server. Unfortunately I didn't save the pairs that I loaded. (Big mistake. I don't know what I was thinking.) I'll make sure I save them this time and possibly post them here. I'll also keep the files from this first big run. I'll put a file name extension of "-1st" on them. I'm also changing that primes.txt file option. I'd like to see all of the primes from all 4 cores in one directory on each machine. That will be cool. :-)


Gary

kar_bon 2010-02-23 06:27

so it's a pruning error?

i thought of this: the knpairs-file on the server contains a blank line or something else because this error occurs almost instantly when k=209 was at n=250k (with your 31 cores grabbing pairs my last results not sent was 30000000000000:M:1:2:258 2009 249720 -2 0AE06F5C6CAB155A).

i started the script for G4000 then and just got connection errors half an hour ago!
why?

can't connect to G4000!

mdettweiler 2010-02-23 06:46

[quote=gd_barnes;206430]Just got home now. Looking at things now.

Sorry you missed all the admins online when you were on a couple of hours ago Karsten. I was on for 3-1/2 hours this afternoon and will be on for another 3 hours now.

Max, this pruning thing is really starting to bother me but I think it's something that's existed in LLRnet for a long time. It seems that it takes far longer to prune pairs than it should.

Anyway, here is what I'm not understanding:
1. The first few pairs of the file that were all small primes for k=3 (n=1K-10K primes) were shown as immediately rejected by the client.
2. When I look in the rejected file on the server for the rejected client results in #1, they aren't there.
3. When I look in the regular results on the server for the rejected client results in #1, 1 out of 5 of them ARE there.
4. When I look in joblist.txt for the rejected client results in #1, 4 out of 5 of them ARE there.

The rejected client pairs are:
3 1274
3 3276
3 4204
3 5134
3 7559

Pairs still in joblist.txt and knpairs.txt:
3 3276
3 4204
3 5134
3 7559

Pair in results.txt on the server:
3 1274

So for some reason, the server wouldn't "take" 4 out of the 5 small k=3 primes results.

Please note that these are NOT In the rejected SERVER pairs. They only show as rejected on the client.

I think what I'm going to do is stop the server, clear everything out completely, and reload the server. Unfortunately I didn't save the pairs that I loaded. (Big mistake. I don't know what I was thinking.) I'll make sure I save them this time and possibly post them here. I'll also keep the files from this first big run. I'll put a file name extension of "-1st" on them. I'm also changing that primes.txt file option. I'd like to see all of the primes from all 4 cores in one directory on each machine. That will be cool. :-)


Gary[/quote]
I'm not entirely sure what happened here so agreed, probably best to clean out and reload the server to make sure this wasn't a fluke from some boo-boo in one of the files or something like that. BTW, when you restart the server, try changing prunePeriod to 15 minutes in llr-serverconfig.txt. That should make the pruning less of an issue.

mdettweiler 2010-02-23 06:46

[quote=kar_bon;206432]so it's a pruning error?

i thought of this: the knpairs-file on the server contains a blank line or something else because this error occurs almost instantly when k=209 was at n=250k (with your 31 cores grabbing pairs my last results not sent was 30000000000000:M:1:2:258 2009 249720 -2 0AE06F5C6CAB155A).

i started the script for G4000 then and just got connection errors half an hour ago!
why?

can't connect to G4000![/quote]
Man, you're right, that is weird...I can't connect to the server machine at all. I wonder if something went kapooey over on Gary's end?

kar_bon 2010-02-23 06:52

want receive 100 WU's for offline pc, got only 50 at once, and error that pairs won't accepted: someone others did them. and i could not send all results!

got to go to work and no new pairs for my i7 and laptop! sh...

mdettweiler 2010-02-23 06:55

[quote=kar_bon;206436]want receive 100 WU's for offline pc, got only 50 at once, and error that pairs won't accepted: someone others did them. and i could not send all results!

got to go to work and no new pairs for my i7 and laptop! sh...[/quote]
Eh? That's weird. I'm not even getting into the server, so I'm not sure how you even got 50 workunits, let alone 100.

gd_barnes 2010-02-23 07:11

1 Attachment(s)
OK, guys, you way jumped the gun on me. From my last post, I hadn't stated that I had cleared everything out and reloaded the server yet. I've been playing around with some things; starting and stopping the server a couple of times and re-clearing some things. I didn't think anyone was around. Sorry.

Anyway, port 9950 has now been officially loaded back up and will remain going now. Max, attached are the pairs that I loaded into it.

2 problems:

1. I changed the appropriate option to false in the do.pl program but the primes are still writing to primes.txt in the individual directories instead of one directory above. Can you run a specific test on that on your end?

2. I changed the iterations to 1000000 in do.pl yet it's still displaying every 10000 iterations. (This sure seems like a tough thing to get rid of! Why is the default so small?) The continual extra display is driving me batty. lol Anyway, I made sure there was no previously existing .ini file in each directory.

One more thing: Don't forget about the problem trying to quit out of the clients when they can't get pairs. It is a serious major hassle to stop them and is part of the reason it took me a while to stop-start all of my clients. What I finally had to do after hitting Ctl-C several times on each (which turned out to not be necessary) is go to the system manager and kill all 4 instances of do.pl followed by killing all 4 instances of llrnet. If I only killed do.pl, the clients would try to "come back". It was really weird.


Gary

mdettweiler 2010-02-23 07:54

[quote=gd_barnes;206438]OK, guys, you way jumped the gun on me. From my last post, I hadn't stated that I had cleared everything out and reloaded the server yet. I've been playing around with some things; starting and stopping the server a couple of times and re-clearing some things. I didn't think anyone was around. Sorry.

Anyway, port 9950 has now been officially loaded back up and will remain going now. Max, attached are the pairs that I loaded into it.

2 problems:

1. I changed the appropriate option to false in the do.pl program but the primes are still writing to primes.txt in the individual directories instead of one directory above. Can you run a specific test on that on your end?[/quote]
Oh! Duh, I see it now. You see this bit of code down in the checkForPrimes() subroutine?
[code] # If individualPrimeLog is set to true, we put primes.txt in the working directory.
# Otherwise, we put it in the parent directory.
if([B]individualPrimeLog[/B]) { open(PRIMELOG, ">>primes.txt"); }
else { open(PRIMELOG, ">>", "../primes.txt"); }
print PRIMELOG $line . "\n";
close(PRIMELOG);
# If beepOnPrime is set to true, then beep (note: may not be supported on all configurations)
print "\a";[/code]
The part that I put in bold needs to be [B]$individualPrimeLog[/B] instead. I had a brain fart and forgot I was programming in Perl for a moment. :rolleyes: I'll upload corrected files shortly.

[quote]2. I changed the iterations to 1000000 in do.pl yet it's still displaying every 10000 iterations. (This sure seems like a tough thing to get rid of! Why is the default so small?) The continual extra display is driving me batty. lol Anyway, I made sure there was no previously existing .ini file in each directory.[/quote]
Did you stop and restart do.pl after making the change? It won't take effect until you do so. Also, keep in mind that it won't take effect until the next k/n pair [i]after[/i] the one currently in progress when you stopped the program to change it; the script only writes out llr.ini at the beginning of each batch (otherwise it would mess up processing of the batch).

[quote]One more thing: Don't forget about the problem trying to quit out of the clients when they can't get pairs. It is a serious major hassle to stop them and is part of the reason it took me a while to stop-start all of my clients. What I finally had to do after hitting Ctl-C several times on each (which turned out to not be necessary) is go to the system manager and kill all 4 instances of do.pl followed by killing all 4 instances of llrnet. If I only killed do.pl, the clients would try to "come back". It was really weird.[/quote]
Yes, as I mentioned before, I'll look into that; I haven't had time just yet but hopefully can do it tomorrow.

BTW, on a completely different topic, I never did get the chance to load up G6000; can you do that? Thanks. :smile:

gd_barnes 2010-02-23 07:57

OK on #1. Glad that's an easy fix.

On #2, I've started-stopped clients many times in all of this. I changed the # of iterations way earlier in the evening. There is definitely an issue there.

I'll load port 6000 tomorrow. Vaughan has pulled most cores off of it also and without me on it until tomorrow, it can wait now.

mdettweiler 2010-02-23 08:38

[quote=gd_barnes;206440]OK on #1. Glad that's an easy fix.

On #2, I've started-stopped clients many times in all of this. I changed the # of iterations way earlier in the evening. There is definitely an issue there.

I'll load port 6000 tomorrow.[/quote]
After some further discussion with Gary over chat, I was able to squash #2. Gary, as you saw I applied the fix to the clients on jeepford, but those don't have #1 fixed; I'd recommend downloading the latest do.pl (which I just uploaded) and swapping them out.

gd_barnes 2010-02-23 08:50

[quote=mdettweiler;206443]After some further discussion with Gary over chat, I was able to squash #2. Gary, as you saw I applied the fix to the clients on jeepford, but those don't have #1 fixed; I'd recommend downloading the latest do.pl (which I just uploaded) and swapping them out.[/quote]

I thought you fixed #1 on Jeepford also.

gd_barnes 2010-02-23 09:17

Holy cow. It looks like port 9950 had already dried out again. That's 30K+ pairs. I'm not going to load it again because that was a sufficient stress test. If you guys want, try port 9975. It has a bunch of pairs at n=~540K from the 11th drive and will NOT dry out. :-)

Max, I'm going to be curious as to what pairs the server couldn't process overall. Clearly it cannot seem to handle the small k=3 pairs that are prime right at the beginning of the file. Like before, my client shows them as processed but as rejected yet the server shows no rejected pairs with them just sitting in the joblist. I suspect we encountered a load-related issue with LLRnet there. The tests are all n=1K-10K primes.

I'm pretty sure the above is an already existing LLRnet issue. What I will do is set up another personal server and run the same initial tests through it to recreate the problem. I'll then run an "old" client on the same file to make sure that we have not introduced a new problem here. If not, we can let it go. Few people would ever use LLRnet for testing n<10K.

I'll go ahead and start up port 6000 up on all of my machines again for the night. There's no reason to let them sit idle over night.

Excluding the issue with the server not "taking" the small k=3 tests right at the beginning, with this testing, we've identified 3 issues on the Linux client. Max has now fixed 2 of them and it appears he'll look into the 3rd issue on Tues. related to stopping a client when the server is down.

I know that on the Window's side, the primes.txt file was being written correctly. What we'll also still need to do there is see if the # of iterations and stopping a client when the server is dried/down issues still exist in Windows.


Gary

kar_bon 2010-02-23 09:30

good work!

the cLLR-option OutputIterations works fine in my DOS-version: stop script, edited that line to 100000 iterations, started script and the next load of workunits, cLLR will display that new iteration-counting properly.

to G4000: so i will try to submit the other results to the server when i'm home again.

while testing port 9950 i've found no prime, because of Gary's 31 cores :grin:
but my prime-logging works, too.

to your last post:
- iterations ok
- server down/dried see post #54

mdettweiler 2010-02-23 17:08

[quote=gd_barnes;206445]I thought you fixed #1 on Jeepford also.[/quote]
No, I didn't, sorry.

kar_bon 2010-02-23 18:08

issue from post #54 solved:

in function DialogWithServer() change some lines this way:
[code]
t, k, n = GetPair()
if t and k and n then
print(format(" Fetching WU #1/%d: %s %s",WUCacheSize,k,n))
changed = 1
else
return
end
[/code]

so the output "Fetching..." will only displayed, when getting a new pair was successful, otherwise exit the function.

mdettweiler 2010-02-23 18:40

[quote=kar_bon;206480]issue from post #54 solved:

in function DialogWithServer() change some lines this way:
[code]
t, k, n = GetPair()
if t and k and n then
print(format(" Fetching WU #1/%d: %s %s",WUCacheSize,k,n))
changed = 1
else
return
end
[/code]

so the output "Fetching..." will only displayed, when getting a new pair was successful, otherwise exit the function.[/quote]
Okay, I've applied that fix in the llrnet.lua file for my Perl script as well (just finished uploading).

Meanwhile, I also clarified the documentation a bit: Gary mentioned that it was a tad wordy and thus he missed some key setup instructions, so I added a bit saying "start here if you just want to find out how to get started". :smile:

gd_barnes 2010-02-23 20:07

Hey guys. Excellent work! What a great team effort!

I feel I messed up on the stress test yesterday a little bit. I was rushing somewhat because I had somewhere I needed to be from 6-11 PM. Today I'm free.

Here is why I think I messed up a bit:

I had a bunch of pairs in there for n=1000 to 10K. That's too intense and I see in looking in the knpairs.txt file and joblist.txt file that 552 of them got handed out but for some reason the server wouldn't accept them even though I'm seeing them in the results for my clients. Many of them are shown as "rejected" on the client side but there is no rejected.txt file on the server side.

This is obviously something LLRnet cannot handle. But the point is, we are testing OUR changes. We're not trying to find existing problems in LLRnet; we're only trying to verify that we did not negatively impact its ability to handle huge loads. Observe this load that I effectively put on it:

A pair at n=500K should take 10,000 times as long to test as a pair at n=5K; that is (500K/5K)^2. So by putting 31 cores on pairs processing around n=5K, it was the effect of a stress test with 310,000 cores at n=500K or 3,100 cores at n=50K!!!!!!

The true objective of our stress test here is to make sure that OUR code did not cause any stress related issues. I feel confident that it hasn't but that cannot be assumed.

Based on this, here is what I'd like to do:

Run another stress test today with a better thought out set of test data. Here is what I'll do:

Port 9950:
Some k=3 to 50 primes for n=10K-50K.
Some k=3 to 100 sieved pairs for n=10K-50K. (I'll run a quick sieve on those k's to get the pairs.)
(So that I don't dry the server so fast, I'll make sure we get at least 100,000 pairs in there this time around.)

Port 9975:
Some primes for k=2000-2200 for n=50K-100K.
Some "regular" pairs for k=2000-2020 for n=50K-125K.
Like before, pairs from the 11th drive for n=~539K.

Note that this is different than yesterday in that I'm putting the k=2000-2020 "medium" sized primes and tests in port 9975 ahead of the n=~540K tests from the 11th drive. Karsten and others, although I'm loading a lot more pairs in port 9950 this time around, having the "medium" sized tests on a separate port than my super stress test will make sure that you can do some testing, find some primes, etc. before I suck up all the pairs. :-)

I realize that with tests in that range for port 9950, we'll still have the equivalent of several thousand cores on there running at n=500K but it won't be several hundred thousand. It would be good if we could verify that LLRnet would handle 1000-2000 cores for a rally so I feel we're in the ball park of a useful test at this level. If there is still a problem with some pairs not coming through, I'll move up to n=25K-75K (or perhaps n=50K-100K) tests. If there is still a problem at that level, I'll be a bit concerned that we've affected something. (Seems unlikely.)

Bottom line recommendation for testing:
Port 9950; I'll run most of that but others are welcome to join in with a few cores if you want.
Port 9975; mostly intended for everyone except me.

In effect, port 9950 is the "legitmate" super stress test and port 9975 is the more "normal" test to finallize that the fixes in the last day are working correctly.

Time line: About like yesterday except that I'll be around all evening. I'll go eat now and start working on the servers within the hour. This time around; allowing time for problems; let's look at about 3:30-4:00 PM CST (10:30-11 PM in Germany) for having the servers ready to go. Although I have to copy the updated clients to all my cores, I know what I'm doing this time so it should go much faster.

...hope you guys aren't too blery eyed from the late nights. :-) Thanks for all of your hard work. :smile:


Gary

mdettweiler 2010-02-23 20:36

Sounds like a good plan. BTW, I'll be out of the house from about 5:30-10:30 EST; that works out to 4:30-9:30 CST. Not that it makes much of a difference since I don't really have enough cores to contribute meaningfully to any stress test, but I figured I'd let you guys know. :smile:

Way cool on being able to figure out the equivalent # of cores at 500K where we start running into problems with LLRnet. Once we've narrowed it down to a more exact figure with these stress tests, that should be immensely helpful for future rallies. Come to think of it, I should be able to apply a similar method to determine more exactly the load of PRPnet 2.4.6 at n=500K; that way we can find out whether a PRPnet rally would even be feasible prior to the perfecting of 3.x.

kar_bon 2010-02-23 20:50

[QUOTE=gd_barnes;206492]Hey guys. Excellent work! What a great team effort!

(...)

...hope you guys aren't too blery eyed from the late nights. :-) Thanks for all of your hard work. :smile:
[/QUOTE]

yep, great work and another issue solved (not that bad, only a cosmetic operation).

no, not really hard work for me! just 2 weeks ago i begun to test this idea and after the first script run fine, it was fun to do this nobody thought before of this option!

and it's working great! (ok, small n-values could be tested by individuals in few days).
and what about other possibilities? think about it! taking LLRnet only as server/client and with changing the script other programs should run as well.

now [b]we[/b] are able to use LLRnet's abilities and we're independent from others!
that's the great chance we must use! although we should inform Jean (and he informs Vincent) of this new use of LLRnet!

gd_barnes 2010-02-23 22:22

Port 9975 is loaded up and ready to go with the previously mentioned pairs. There's a bunch of primes at the beginning.

I'm still working on port 9950.

gd_barnes 2010-02-23 23:25

Port 9950 is loaded up and ready to go.

The delay was caused because I'm having tremendous difficulty getting my main machine, Jeepford, to connect to the server. (It's internet access is fine because I'm typing from it right now.) It keeps saying "could not connect to server after 5 tries". I've checked everything in the llr-clientconfig.txt file and it looks good. I've stopped and restarted the server; no luck. I've stopped and restarted the clients; no luck. I'm going to try loading the client on some other machines now. FYI, I'm using the "Perl do.pl" command.

I thought it would be easier and faster today. I was mistaken as usual. It's always something. Ergh.

kar_bon 2010-02-23 23:33

[QUOTE=gd_barnes;206510]I thought it would be easier and faster today. I was mistaken as usual. It's always something. Ergh.[/QUOTE]

check, if you deleted all old files like tosend.txt, workfile.txt, workfile.res and check the entries in llr-clientconfig.txt again!

gd_barnes 2010-02-23 23:47

[quote=kar_bon;206511]check, if you deleted all old files like tosend.txt, workfile.txt, workfile.res and check the entries in llr-clientconfig.txt again![/quote]

Oh, I started completely fresh. I've isolated it to a problem in the client code. Here is the message I'm getting coming from llrnet.lua:

./llrnet.lua:536: "end" expected (to close 'function' at line 61) near '<eof>'

It then tries 5 times and wait 60 seconds.

Max, did you change something in llrnet.lua without testing it or did I do something dumb? lol

I'm looking into it now.


Gary

kar_bon 2010-02-23 23:53

[QUOTE=gd_barnes;206513]Oh, I started completely fresh. I've isolated it to a problem in the client code. Here is the message I'm getting coming from llrnet.lua:

./llrnet.lua:536: "end" expected (to close 'function' at line 61) near '<eof>'

It then tries 5 times and wait 60 seconds.

Max, did you change something in llrnet.lua without testing it or did I do something dumb? lol

I'm looking into it now.


Gary[/QUOTE]

there's missing an 'end':

[code]
-- if no unfinished job, then ask a new job to the server
if not t or not k or not n then
--print("Requesting new job from the server ...")
t, k, n = GetPair()
if t and k and n then
print(format(" Fetching WU #1/%d: %s %s",WUCacheSize,k,n))
changed = 1
else
return
end
[color=red] end[/color]
[/code]

gd_barnes 2010-02-24 00:17

1 Attachment(s)
Thanks Karsten. I was also able to figure that out myself and got it working finally.

Max, please test any changes that you make before making a public posting. Nothing extensive. Just simply starting a client to make sure it runs would have saved me a lot of time here. You could connect to any server and start running a pair without completing it. Thanks.

The issue that won't go away: The primes.txt issue is still not working. It's still writing primes to the individual directories instead of one level up. Please test that one one of my Linux quads. It has to be tested on a Linux machine. Feel free to use Jeepford or whatever. You can see the options that I'm using in the clients on Jeepford.

Final thing: I was able to fix the problem with the execution of the ./do.pl command. That works now. I found the fix after googling it. Here is what I typed at the command prompt:

perl -i -pe's/\r$//;' do.pl

That did the trick. What must have happened is that it somehow changed the properties of the program itself. I say that because when I copied do.pl from the directory in which I executed the above command to the other directories, they all worked great.

Based on the above two corrections, I am attaching corrected llrnet.lua and do.pl programs to this posting. Please incorporate them with your Linux client and make the same changes to your Windows client.


Gary

gd_barnes 2010-02-24 01:18

1 Attachment(s)
All 31 cores are now finally running on port 9500. We'll see what happens. That's still a heck of a load and I can see the clients waiting several seconds in between the batches of 5 to get pairs; longer than what I would expect. So it's laboring to get them handed out.

It appears the server is still having issues with not accepting some pairs that it should. Even though the prune period is now set to only 15 mins., it's still showing some early pairs in the joblist.txt from over an hour ago by me and nearly 2 hours ago by Karsten. Only one pair has made it to the rejected.txt file so far.

This may be related to my own set up. Even with a commercial internet account, the inner workings of the server may not be robust enough to handle the load even if the LLRnet software could fully handle it. The highest socket that it has used so far is 29. All of the pairs were n=10K-25K with the exception of some initial primes that were n=10K-100K.

Amazingly, I'm going to blast through this in about 4 hours. Even though I loaded ~180K pairs this time around vs. ~30K last time, the tests just move so fast.

For everyone's reference, I'm attaching the knpairs that I loaded into port 9500 this time. IMPORTANT note: This is a tar.lzma compressed file. Linux chose that because it made it smaller than .bz2 or .gz compressed files that it typically creates. And the good news is that it made it just small enough to attach here. But there was still one problem: The attachments here don't accept a .lzma file extension so I had to change it to a .bz2 extension. The full name of the compressed file created was: knpairs-save.txt.tar.lzma. My guess is that you'll have to somehow get it renamed to that for your compression software to be able to read it. Hopefully someone will be able to read it. Please keep in mind that it's NOT a .bz2 compressed file!


Gary

mdettweiler 2010-02-24 03:21

[quote=gd_barnes;206515]Thanks Karsten. I was also able to figure that out myself and got it working finally.

Max, please test any changes that you make before making a public posting. Nothing extensive. Just simply starting a client to make sure it runs would have saved me a lot of time here. You could connect to any server and start running a pair without completing it. Thanks.

The issue that won't go away: The primes.txt issue is still not working. It's still writing primes to the individual directories instead of one level up. Please test that one one of my Linux quads. It has to be tested on a Linux machine. Feel free to use Jeepford or whatever. You can see the options that I'm using in the clients on Jeepford.

Final thing: I was able to fix the problem with the execution of the ./do.pl command. That works now. I found the fix after googling it. Here is what I typed at the command prompt:

perl -i -pe's/\r$//;' do.pl

That did the trick. What must have happened is that it somehow changed the properties of the program itself. I say that because when I copied do.pl from the directory in which I executed the above command to the other directories, they all worked great.

Based on the above two corrections, I am attaching corrected llrnet.lua and do.pl programs to this posting. Please incorporate them with your Linux client and make the same changes to your Windows client.


Gary[/quote]
Whoa, what the heck? That's weird. For one, I haven't made any changes to any of the .lua files; that's strictly in Karsten's purview. As for the "perl -i -pe's/\r$//;' do.pl thing, now THAT is weird. I just tried doing a diff on your file to compare it to mine and it listed every line as different--yet there's no apparent difference.

Oh, wait a minute! Now I know what was up. Yours has Unix line endings, mine has DOS ones. I can see why that would be enough to throw off the ./do.pl thing. I'm not sure how the command you executed fixed it, but hey, I guess it did. :smile:

Now that I tried converting the line endings in my Linux script to Unix format with a text editor, a diff comparison of the two reveals only two very small differences:
[code]18,19c18,19
< $individualPrimeLog = true;
< $iniOptions = "OutputIterations=10000\n";
---
> $individualPrimeLog = false;
> $iniOptions = "OutputIterations=1000000\n";[/code]
Namely, just differences in configuration. So it seems the line endings were the issue; now that's fixed, and will remain so for future uploaded versions.

Speaking of the individual prime log, though, that's weird...I can see you have the latest version since the "diff" lined up with mine, and I could have sworn that you mentioned before that the fix I applied last night on jeepford did the trick. Are you sure you've got the latest version on whatever machine(s) you're seeing this on?

At any rate, though, yes, I'll test this on one of your quads, later tonight if I can. I can't see a reason why it shouldn't work but perhaps I'll turn something up. :smile:

gd_barnes 2010-02-24 05:14

1 Attachment(s)
No matter. I have to fix all of your problems. LMAO

And no, I didn't say the primes issue had been fixed. You found the variable suffix of $ problem and "thought" that was the problem. I didn't have a chance to test it before you left. Obviously the variable suffix was only part of the problem. Clearly it had something to do with the boolean TRUE. That was just NOT going to work no matter what was tried. See below.

I have now fixed and corrected the following 4 problems. 3 existing ones that have already been mentioned and another one:

1. The earlier issue with the missing END in llrnet.lua. (BTW you said you didn't mess with that. You must have. I pulled it right out of your latest upload and it was different than your upload from yesterday. Even Karsten pulled it right out of your upload and independently found the same problem.)

2. The problem with ./do.pl not working.

3. The problem with primes.txt not writing one level up.

4. New problem: You didn't have an IF statement around the beepOnPrime so it always beeped no matter what you set the variable to.

I fixed the primes issue by changing the variable definition to a literal "TRUE" and checking the value of the literal. I tried repeated different things using the way you did it with the boolean TRUE. No luck at all. I did the same with the beeponprime except that I simply had to add an IF statement. Where was that IF statement anyway?

But we have one potential MAJOR PROBLEM: The server appears to be rejecting a very large majority of primes. This does not appear to be a load related issue. I'm thinking that somehow the formatting that is sent to the server in the tosend.txt file for primes is incorrect.

Attached are updated do.pl and README.txt files. README had to be changed to put quotes around the "TRUE".

BTW, I'm going to suggest a defualt of "FALSE" on both of these. I think most people will want the beeps off and the primes all in one folder. That's the way I've set them in do.pl.

You don't need to mess with anything on Jeepford. The script is virtually perfect as is. I've been testing just on that box using a completely different server.

#1 PRIORITY NOW:

Now to see if I can figure out what is causing the server to not accept so many primes. Max, Karsten, and whomever is available; that is a deal breaker whereas these other things were nit picky issues. Please take a look at how a prime is being formatted on the Linux client when put into tosend.txt to send to the server. I'm fairly confident of that now and that it's a problem only on the Linux client. I was seeing all kinds of rejected messages on the client but virtually no pairs in rejected.txt on the server. Whenever that message occurred, I would look up in the group of 5 pairs processed and there it was; at least one prime every time. Interestingly, not all primes are rejected. But the reverse situation happens all of the time; that is: If there is a rejected message on the client, there is ALWAYS a prime in the group of pairs processed.


Gary

mdettweiler 2010-02-24 06:19

[quote=gd_barnes;206526]1. The earlier issue with the missing END in llrnet.lua. (BTW you said you didn't mess with that. You must have. I pulled it right out of your latest upload and it was different than your upload from yesterday. Even Karsten pulled it right out of your upload and independently found the same problem.)[/quote]
Actually, I didn't mess with it, all I did was swap in Karsten's then-latest llrnet.lua version for yesterday's upload, and didn't test it since I figured he'd already done that. Then when he pointed out the typo today, I fixed it and included that in my upload. :smile:

[quote]2. The problem with ./do.pl not working.

3. The problem with primes.txt not writing one level up.

4. New problem: You didn't have an IF statement around the beepOnPrime so it always beeped no matter what you set the variable to.

I fixed the primes issue by changing the variable definition to a literal "TRUE" and checking the value of the literal. I tried repeated different things using the way you did it with the boolean TRUE. No luck at all. I did the same with the beeponprime except that I simply had to add an IF statement. Where was that IF statement anyway?[/quote]
Ah, whoops, thanks for fixing the beepOnPrime thingy--not sure how I missed that one. :rolleyes: I'm not sure why the straight boolean shouldn't work, though. Sticking a boolean variable in a conditional test should work...unless I'm getting my programming languages confused and Perl can't actually do that. :geek: (It would be rather strange if it couldn't, though, as it would seem to be a basic programming concept.)

Come to think of it, though, I believe I did have similar issues with boolean variables in some earlier scripts I wrote (the GB server status page scripts, I think). I'm beginning to wonder if it really is just an idiosyncracy of Perl.

At any rate, okay, as long as the string literal's working, then we may as well stick with that.

[quote]But we have one potential MAJOR PROBLEM: The server appears to be rejecting a very large majority of primes. This does not appear to be a load related issue. I'm thinking that somehow the formatting that is sent to the server in the tosend.txt file for primes is incorrect.[/quote]
Oh, that's right! The code for generating tosend.txt is taken verbatim from an earlier standalone script I wrote a long while back to do that job for manually cached pairs; as I recall, it never did work well for primes, so I always had to submit those separately with "normal" LLRnet. It was a long enough time ago that I'd completely forgotten.

I'll try to cook up a solution (probably re-write the whole section, it's not too big) either tonight or tomorrow.

[quote]Attached are updated do.pl and README.txt files. README had to be changed to put quotes around the "TRUE".

BTW, I'm going to suggest a defualt of "FALSE" on both of these. I think most people will want the beeps off and the primes all in one folder. That's the way I've set them in do.pl.[/quote]
Okay. I set it to beep by default since Karsten's script does that (and it's not even configurable there). :smile: But I can see why many users wouldn't want that. As for the primes in one folder, I guess the reason why I set that to false was because that's how I'd use it--my clients are all in subfolders under a main prime/ directory, which includes folders for all my other prime search applications, so a primes.txt file would kind of get lost there. :smile:

I've updated the do.pl and readme.txt files on my local copy and uploaded the latest version to the web site. BTW, I changed OutputIterations back to 10,000 rather than 1,000,000 as it was in your version of the script; 1M is rather big for a default value in a client that's going to be distributed to users, since for tests of the sizes that NPLB is primarily doing, having no interim progress reports is definitely not what most people will want.

[quote]You don't need to mess with anything on Jeepford. The script is virtually perfect as is. I've been testing just on that box using a completely different server.

#1 PRIORITY NOW:

Now to see if I can figure out what is causing the server to not accept so many primes. Max, Karsten, and whomever is available; that is a deal breaker whereas these other things were nit picky issues. Please take a look at how a prime is being formatted on the Linux client when put into tosend.txt to send to the server. I'm fairly confident of that now and that it's a problem only on the Linux client. I was seeing all kinds of rejected messages on the client but virtually no pairs in rejected.txt on the server. Whenever that message occurred, I would look up in the group of 5 pairs processed and there it was; at least one prime every time. Interestingly, not all primes are rejected. But the reverse situation happens all of the time; that is: If there is a rejected message on the client, there is ALWAYS a prime in the group of pairs processed.[/quote]
As I mentioned above, I'm quite sure this is an issue with my script. I should be able to fix it pretty easily.

gd_barnes 2010-02-24 06:35

[quote=mdettweiler;206528]Actually, I didn't mess with it, all I did was swap in Karsten's then-latest llrnet.lua version for yesterday's upload, and didn't test it since I figured he'd already done that. Then when he pointed out the typo today, I fixed it and included that in my upload. :smile:


Ah, whoops, thanks for fixing the beepOnPrime thingy--not sure how I missed that one. :rolleyes: I'm not sure why the straight boolean shouldn't work, though. Sticking a boolean variable in a conditional test should work...unless I'm getting my programming languages confused and Perl can't actually do that. :geek: (It would be rather strange if it couldn't, though, as it would seem to be a basic programming concept.)

Come to think of it, though, I believe I did have similar issues with boolean variables in some earlier scripts I wrote (the GB server status page scripts, I think). I'm beginning to wonder if it really is just an idiosyncracy of Perl.

At any rate, okay, as long as the string literal's working, then we may as well stick with that.


Oh, that's right! The code for generating tosend.txt is taken verbatim from an earlier standalone script I wrote a long while back to do that job for manually cached pairs; as I recall, it never did work well for primes, so I always had to submit those separately with "normal" LLRnet. It was a long enough time ago that I'd completely forgotten.

I'll try to cook up a solution (probably re-write the whole section, it's not too big) either tonight or tomorrow.


Okay. I set it to beep by default since Karsten's script does that (and it's not even configurable there). :smile: But I can see why many users wouldn't want that. As for the primes in one folder, I guess the reason why I set that to false was because that's how I'd use it--my clients are all in subfolders under a main prime/ directory, which includes folders for all my other prime search applications, so a primes.txt file would kind of get lost there. :smile:

I've updated the do.pl and readme.txt files on my local copy and uploaded the latest version to the web site. BTW, I changed OutputIterations back to 10,000 rather than 1,000,000 as it was in your version of the script; 1M is rather big for a default value in a client that's going to be distributed to users, since for tests of the sizes that NPLB is primarily doing, having no interim progress reports is definitely not what most people will want.


As I mentioned above, I'm quite sure this is an issue with my script. I should be able to fix it pretty easily.[/quote]


What's up with that llrnet.lua bug Karsten? lol

I'm catching up with your Perl knowledge Max. Better watch out. lol (not likely) Regardless, in looking at the Perl tutorial I've been using, it says nothing about boolean variables like there are in other languages like C and Pascal. Clearly they either don't exist or you need to define them in an entirely different way.

You set the prime thingie to FALSE before? Haven't you had that as TRUE all along? It was me who just now set it to FALSE so it would finally write one level up after I fixed the code. It took forever to get it to write a level up like Karsten's script. Personally the only reason I could ever see for it to be set to TRUE is if you are only running one core on a machine.

Agreed on the beep default being the same as Karsten's script and the default being 10,000 iterations. Karsten, by chance, would you want to add an option to allow the user to turn the beep on or off on the Windows client? Personally I find the beep annoying especially if I was about to go to sleep and I was searching small n-ranges on my 2 machines in my bedroom. :-)

About the iterations, I'm not sure why people would want continual status updates on an individual pair. It only sucks CPU cycles. You have a good idea how long each pair takes by looking in lresults.txt. Now, if you're running tests that take > 1 hour, I could see it. But for our typical 7 to 20 minute tests, I can't see the point. Just my 2 cents. I guess you like to see the iterations so perhaps others do too.

I think the reason I don't like the beep is because it reaks of a warning or doing something wrong like a file being deleted or the delete key hit too many times. Other times, it means a program has gone astray.

It's nice to know that I wasn't hallucinating on the servers not processing many of the pairs. I was getting a little worried that we were getting some serious load-related issues. I could see just a couple of straggling missing pairs with that last load but not the several hundred that I was seeing. At first, I didn't realize that it was mostly primes. (It appears to be some composites too but we'll only know when the formatting of the tosend.txt file is fixed.)


Gary

kar_bon 2010-02-24 06:58

[QUOTE=gd_barnes;206529]Agreed on the beep default being the same as Karsten's script and the default being 10,000 iterations. Karsten, by chance, would you want to add an option to allow the user to turn the beep on or off on the Windows client? Personally I find the beep annoying especially if I was about to go to sleep and I was searching small n-ranges on my 2 machines in my bedroom. :-)
[/QUOTE]

yes, i can implement 2 options to do.bat:
- one for the iterations counting (10000 by default)
- second the beeping (ON/OFF)

and Gary, this beeping is the same thing as with snoring:
if you can't stand it, go to a side room! :grin:

for me it's quite good to beep when do.bat ends. my offline pc got a screen but it's not always switched on. so a beep tells me when do.bat is complete. i don't have to calculate the estimated time, when he is ready and not send much idle time, if i'm not aware of it.

other things to do for me?

mdettweiler 2010-02-24 07:35

[quote=gd_barnes;206529]What's up with that llrnet.lua bug Karsten? lol

I'm catching up with your Perl knowledge Max. Better watch out. lol (not likely) Regardless, in looking at the Perl tutorial I've been using, it says nothing about boolean variables like there are in other languages like C and Pascal. Clearly they either don't exist or you need to define them in an entirely different way.[/quote]
Yeah, that just about settles it then...no boolean variables in perl. That would explain why a lot of scripts I've seen use "1" and "0" integer variables instead.

BTW, way cool on catching up with Perl. It's a really powerful language and since you have somewhat more time available to you to do do such things than I do, I imagine you'll be coming up with all sorts of handy-dandy programs. :smile:

[quote]You set the prime thingie to FALSE before? Haven't you had that as TRUE all along? It was me who just now set it to FALSE so it would finally write one level up after I fixed the code. It took forever to get it to write a level up like Karsten's script. Personally the only reason I could ever see for it to be set to TRUE is if you are only running one core on a machine.[/quote]
Ah, whoops, I meant I set it to [i]true[/i], which meant it would [i]not[/i] put the prime log in the parent directory. :smile:

Yes, most of the time when I'm running an LLRnet or PRPnet client on my dualcore, it's just one core; since my dualcore generally does all my "specialty" jobs (as opposed to my quad which just does straight PRPnet), I rarely have both cores doing full-automatic stuff. The only time I do that is during rallies.

But yes, agreed that most people will probably want to have it in the parent directory. That's how I'd do it on my quad, for example. I guess my dualcore is more of a rare case in that regard, so "false" for that setting makes better sense as a default. :smile:

[quote]Agreed on the beep default being the same as Karsten's script and the default being 10,000 iterations. Karsten, by chance, would you want to add an option to allow the user to turn the beep on or off on the Windows client? Personally I find the beep annoying especially if I was about to go to sleep and I was searching small n-ranges on my 2 machines in my bedroom. :-)[/quote]
lol, yeah, I can see how it would be annoying. I'll sometimes use beeps as a way of telling myself that a job is done (since I usually turn off my monitor when I'm not actively using the computer), though that's fallen somewhat into disuse now that I've discovered just how handy stringing up multiple jobs on the command line can be. :smile:

[quote]About the iterations, I'm not sure why people would want continual status updates on an individual pair. It only sucks CPU cycles. You have a good idea how long each pair takes by looking in lresults.txt. Now, if you're running tests that take > 1 hour, I could see it. But for our typical 7 to 20 minute tests, I can't see the point. Just my 2 cents. I guess you like to see the iterations so perhaps others do too.[/quote]
Hmm, I actually guessed you'd want it the opposite way, so you can see the progress. Not having a somewhat-longish test (>30 seconds or so) give progress updates at least periodically kind of drives me nuts in the same sort of way really high n-ranges drive you nuts. :smile: I figure that even when updating every 10000 iterations on a 50K test, the extra CPU time used to do the updates is so negligible that it's not worth worrying about.

One other consideration that I can see being an issue with this is screen spam; the way LLR does its screen output, for most k*2^n-1 numbers the status line is just longer than the size of a standard console window, so each update rolls over into a new line. (This issue doesn't usually happen for PRP or Proth tests, since the word "bit" is a lot smaller than "iteration", which is enough to make it fit.) One way to fix this is to expand the console window to a larger width, say 90 characters (instead of the standard 80). Or one could just use the GUI LLR which I think has plenty of room to avoid rollovers anyway. :smile:

gd_barnes 2010-02-24 08:53

Max, you like to sit there and watch any test > 30 secs. update its iterations? You must have a lot of time on your hands. hardy-har-he-he

I believe I have the primes submission issue fixed. It appears to be just a matter of putting "something" in the residue field, which is subsequently ignored.

Current LLRnet just puts the residue from the previous pair in there. One problem with that: If the first pair or pairs in the file are prime, the residue field is blank and it loses the prime(s)! My solution: Put 16 x's in the residue field on every prime. I'm still testing to see if it works. Initial testing seems to indicate that it does.

Karsten, what about your Windows .awk script? How does it handle it? Will it work correctly if the first pair or pairs in the knpairs.txt file are prime? I don't remember it having a problem with any primes, even ones at the beginning of the file but I may not have been specifically looking for it because I didn't have the cores to stress test it a lot.

On another topic: Should we use Karsten's client with the "awk" script or Max's client with the Perl script for the public Windows client?

Yet another topic: I haven't yet tested the do.pl -c logic yet in the Linux client. I've encountered too many other issues to test it yet.

A mistake I made in all of this was assuming that the Linux client would be virtually perfect since the Windows client was but it turned out to have several problems. I started out assuming that many of the issues were load related, which took quite a bit extra time. What I should have done is just continue testing on one quad until all of the issues were out of the way. After encountering all of the pairs (that mostly turned out to be primes) not submitting on the big test today, I've found and been able to fix all 5 issues (including this prime submission one) just by testing on one quad.

I'll test this prime submission issue a little more tonight and if it looks good, I'll post an updated script. The defaults as discussed by Max will be set to 10000 iterations with the beep set to true and individualprime set to false. I'll then be able to (hopefully) get a clean major stress test on Weds.


Gary

kar_bon 2010-02-24 09:07

[QUOTE=mdettweiler;206532]One other consideration that I can see being an issue with this is screen spam; the way LLR does its screen output, for most k*2^n-1 numbers the status line is just longer than the size of a standard console window, so each update rolls over into a new line. (This issue doesn't usually happen for PRP or Proth tests, since the word "bit" is a lot smaller than "iteration", which is enough to make it fit.) One way to fix this is to expand the console window to a larger width, say 90 characters (instead of the standard 80). Or one could just use the GUI LLR which I think has plenty of room to avoid rollovers anyway. :smile:[/QUOTE]

i've not yet tested LLR-GUI version with this script because you have to put the llr.ini first to a minimum of the options set:
[code]
PgenInputFile=t17_b2.prp
PgenLine=1
[/code]

- the testfile
- and the line to begin

seems to work without script.
but: you have to end LLR-GUI by hand!?

the long line in the cLLR output is the result like:

7095*2^137576-1 is not prime. LLR Res64: 7E4DD3D5AA6CE447 Time : 15.954 sec.

and this is less than 80 characters only for smaller k-values.
there're two spaces, which could be omitted, so it's possible to do (but for greater k it's again longer than 80 chars).
so the best way is to set the output window to a width of 100 or so.
in Win the properties of a CMD-win can be set for all screens (i use it so no problems)!

kar_bon 2010-02-24 09:16

[QUOTE=gd_barnes;206534]Karsten, what about your Windows .awk script? How does it handle it? Will it work correctly if the first pair or pairs in the knpairs.txt file are prime? I don't remember it having a problem with any primes, even ones at the beginning of the file but I may not have been specifically looking for it because I didn't have the cores to stress test it a lot.
[/QUOTE]

i've just tested this:
lresults.txt contains this:
[code]
742837095*2^3190-1 is prime! Time : 38.325 ms.
742837095*2^3193-1 is not prime. LLR Res64: 9F1CECDF79EA85C4 Time : 37.998 ms.
742837095*2^3197-1 is not prime. LLR Res64: 711C29862057740B Time : 38.217 ms.
742837095*2^3201-1 is not prime. LLR Res64: 33EB063C96F7756C Time : 39.356 ms.
742837095*2^3205-1 is prime! Time : 39.301 ms.
742837095*2^3207-1 is not prime. LLR Res64: 689F3E5F8EA36E7F Time : 38.635 ms.
742837095*2^3210-1 is not prime. LLR Res64: 9876B6D0612180D6 Time : 38.365 ms.
[/code]

workfile.bak contains this:
5000000000000:M:1:2:258

and do.bat contains this:
gawk -f do_tosend.awk lresults.txt

put the awk-script (do_tosend.awk) and gawk.exe in the same folder and run it.
the resultfile for LLRnet, tosend.txt then contains:
[code]
5000000000000:M:1:2:258 742837095 3190 0 0
5000000000000:M:1:2:258 742837095 3193 -2 9F1CECDF79EA85C4
5000000000000:M:1:2:258 742837095 3197 -2 711C29862057740B
5000000000000:M:1:2:258 742837095 3201 -2 33EB063C96F7756C
5000000000000:M:1:2:258 742837095 3205 0 0
5000000000000:M:1:2:258 742837095 3207 -2 689F3E5F8EA36E7F
5000000000000:M:1:2:258 742837095 3210 -2 9876B6D0612180D6
[/code]

all is ok, nothing unusual!

gd_barnes 2010-02-24 09:41

Very good. So Karsten chose to put a "0" in the residue for a prime and I chose to put a "xxxxxxxxxxxxxxxx" in the residue for a prime. I chose that because I wasn't sure if it was expecting 16 digits.

Karsten, I got the same type of output as you did except with the 16 x's in the residue for primes.

I'll try it with just "0" also. If it works, I'll go with that to keep the Windows and Linux clients as close to the same as possible. "0" is technically more correct anyway since the residue really is zero if the number is prime.

Max, this confirms that the blank residue that you have in there doesn't work for primes. It just needs "something" in there.

One note of historical interest on all of this: We actually corrected a long-standing LLRnet bug with this. I confirmed by running the old client that if the first few pairs of the files were primes, the server would never get them because the residue came out as blank in tosend.txt file. Once a composite came through, then all future primes would be good because LLRnet just kept the previous pair's residue. That's pretty poor coding in the original design.


Gary

kar_bon 2010-02-24 10:29

[QUOTE=gd_barnes;206537]One note of historical interest on all of this: We actually corrected a long-standing LLRnet bug with this. I confirmed by running the old client that if the first few pairs of the files were primes, the server would never get them because the residue came out as blank in tosend.txt file. Once a composite came through, then all future primes would be good because LLRnet just kept the previous pair's residue. That's pretty poor coding in the original design.[/QUOTE]

i think, i found the reason why!

in llrnet.lua the call is
[code]
result, residue = primeTest(t, format("%s %s", k, n))
[/code]

in LUA it's possible to return more than one (even variable counts of results are possible)result by a function (see [url=http://lua-users.org/wiki/FunctionCallTutorial]here[/url]).

so the lua expect 2 return-values: result and residue.

in the LLRnet-source in llr2.c, the primtest-function is called
[code]
int primeTest (const char * type, const char * input, char * residue)
[/code]

and the end is

[code]
strcpy(residue, res64);
return retval;
[/code]

so in C only the result is returned as integer, the residue is give in the call-by-value-list.

perhaps a change of the lua-line in
[code]
result = primeTest(t, format("%s %s", k, n),residue)

[/code]

could do the job right!

i will test this afternoon.

gd_barnes 2010-02-24 13:14

1 Attachment(s)
I'll be interested to see what you come up with Karsten.

In the mean time, I have confirmed that putting a single "0" (vs. 16 x's) in the residue for primes works on the Linux side. Therefore I have made that an official modification to the Linux do.pl script. In that regard, the Windows and Linux clients are now in sync.

Max, attached is the updated do.pl script. Like discussed, I put it at 10000 iterations, beep at true, and individualPrimeLog at false.

I've calculated that a single quad running n=~20K tests is like 1000+ cores running n=~400K tests. Therefore a stress test with a single quad is not only sufficient, it's a lot easier to manage and find bugs from my perspective. I may try a 2nd quad for a while just to "feel like" I'm really stressing the server AFTER I can verify that all small bugs like what I've found so far are fixed.

Max, if you want to see what I've been running the last several hours, look at port 9985. There was 180K+ pairs in there when I started it 3-4 hours ago and it should dry out within the next 1-2 hours.

The last thing for me to test is the cancellation of pairs on the Linux client. I'll be fairly busy today (Weds.) but will make time to do that test.


Gary

mdettweiler 2010-02-24 15:37

[quote=gd_barnes;206534]On another topic: Should we use Karsten's client with the "awk" script or Max's client with the Perl script for the public Windows client?[/quote]
Definitely Karsten's--since mine requires Perl, it would be a pain in the butt for many Windows users to run. I mainly developed it with Linux in mind but since Perl is rather crosscompatible over both, figured that it should work just as well for both and that as such I'd test it on both platforms. As I said in the readme file, it never hurts to have options. :smile:
[quote=gd_barnes;206548]I'll be interested to see what you come up with Karsten.

In the mean time, I have confirmed that putting a single "0" (vs. 16 x's) in the residue for primes works on the Linux side. Therefore I have made that an official modification to the Linux do.pl script. In that regard, the Windows and Linux clients are now in sync.

Max, attached is the updated do.pl script. Like discussed, I put it at 10000 iterations, beep at true, and individualPrimeLog at false.[/quote]
AMAZING! :w00t: Thanks for fixing that--I should have figured it was something simple like that. :smile: This should end up saving me quite a bit of time since I imagine it would have taken me a little while to find that.

I'll get the new version uploaded shortly. (Edit: done)

[quote]I've calculated that a single quad running n=~20K tests is like 1000+ cores running n=~400K tests. Therefore a stress test with a single quad is not only sufficient, it's a lot easier to manage and find bugs from my perspective. I may try a 2nd quad for a while just to "feel like" I'm really stressing the server AFTER I can verify that all small bugs like what I've found so far are fixed.[/quote]
Okay, that's good. Two quads, I'd think, would be good to make sure we account for even the biggest rally (I think our biggest ones so far may have gone over 1000 cores, with you, Lennart, Beyond, IronBits, and quite a number of others all banging away full-steam).

mdettweiler 2010-02-24 15:47

[quote=kar_bon;206535]i've not yet tested LLR-GUI version with this script because you have to put the llr.ini first to a minimum of the options set:
[code]
PgenInputFile=t17_b2.prp
PgenLine=1
[/code]

- the testfile
- and the line to begin

seems to work without script.
but: you have to end LLR-GUI by hand!?

the long line in the cLLR output is the result like:

7095*2^137576-1 is not prime. LLR Res64: 7E4DD3D5AA6CE447 Time : 15.954 sec.

and this is less than 80 characters only for smaller k-values.
there're two spaces, which could be omitted, so it's possible to do (but for greater k it's again longer than 80 chars).
so the best way is to set the output window to a width of 100 or so.
in Win the properties of a CMD-win can be set for all screens (i use it so no problems)![/quote]
Ah, whoops, that's not quite what I meant...when I said "or one could just use the GUI LLR" I was referring to it in the more general context of running manual LLR. Not that that's used that commonly nowadays, though...

I had actually intended to try the GUI-LLR version with the script just for the fun of it; I hadn't gotten around to it yet with all the "real" issues to worry about, but I imagine it could still be done if you set NoTrayIcon=0 and NoIcon=1 (I think those are the correct options) in llr.ini to have LLR run without a tray icon, and without displaying any window whatsoever. I think the combination of those two should do the trick; at any rate, I know it worked for Riesel Sieve and PrimeGrid, who had to use the GUI LLR in their BOINC setups prior to the introduction of cllr. Of course, they may well have been using a modified version of the GUI LLR.

Anyway, though, not a particularly big deal...as you said, it's not hard to just make the command window bigger. I imagine a similar "permanent" setting should be possible on Linux as well.

mdettweiler 2010-02-24 15:58

Hmm, I just discovered something interesting. It turns out you CAN kill the do.pl script when it can't connect to a server. You just have to get it while it's in "sleeping 60 seconds" mode, which it does after every 5 failed tries. :smile: Guys, which do you feel would be a better way to handle this: just have the script try 5 times then exit (like Karsten's script) or keep trying over and over like it does now (so that unattended clients don't go kapooey after a longish temporary outage)?

Or, the best of both worlds: add another option for it! :grin: That shouldn't be too hard...

P.S. @Gary: I have a Windows client running do.pl on 9975 now and I just ran into a pair with a small factor. :razz: It seemed to handle it pretty well, though--from what I can tell it only rejected the one with the small factor and accepted the rest. I don't have time right now as I'm leaving the house in 15 minutes, but can you check to see if all of these were received (except the small factor of course)?
[code]2013*2^221147-1 is prime! Time : 73.842 sec.
2015*2^50601-1 has a small factor : 3 !!
2015*2^56660-1 is prime! Time : 3.520 sec.
2015*2^63662-1 is prime! Time : 4.571 sec.
2015*2^104784-1 is prime! Time : 15.064 sec.
Submitted to server at [2010-02-24 10:56:39][/code]

kar_bon 2010-02-24 18:24

[QUOTE=kar_bon;206541]i think, i found the reason why!

in llrnet.lua the call is
[code]
result, residue = primeTest(t, format("%s %s", k, n))
[/code]
[/QUOTE]

it's not so easy as thought, but the following lines will do the trick.
[code]
result, residue = primeTest(t, format("%s %s", k, n))
if result == 0 then
residue = "0"
end
[/code]

so, if a prime is found, set the residue to '0' and all is ok!

Note: not needed for the script, only for the 'old' version of the LLRnet-client.


All times are UTC. The time now is 08:36.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2022, Jelsoft Enterprises Ltd.