Testing....

[kar_bon]

@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]

new version with these changes:

1.
altough i set

  WUCacheSize = 0
  once = 1

in the llr-clientconfig.txt, LLRnet reserved one new pair!

-> 2 lines in llrnet.lua (in function Work()) commented out:

 --      print("Requesting new job from the server ...")
 --      t, k, n = GetPair()

2.
in do.bat the loop, when no connection was found, was endless!
-> set the waitloop-counter before the loop:

  set /a waitloop=0
  :do_llrnet
  llrnet

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]

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

[kar_bon]

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

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

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]

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]

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]

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

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]

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]

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]

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]

Behold: the long-awaited Linux/Perl version of the script is ready! 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.

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. All necessary instructions are included in readme.txt.
Windows: http://www.noprimeleftbehind.net/dow...0.61-win32.zip
Linux: http://www.noprimeleftbehind.net/dow...61-linux32.zip