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)

mdettweiler 2010-03-04 17:12

Gary, I got your email with the latest client. Here's the uploaded packages:
[URL]http://nplb-gb1.no-ip.org/sieves/llrnet-script-perl-0.70-win32.zip[/URL]
[URL]http://nplb-gb1.no-ip.org/sieves/llrnet-script-perl-0.70-linux32.zip[/URL]
(Note that the links are different from before because I realized just now that I was previously uploading 0.70 clients to links that said 0.61 in the name. :smile:)

kar_bon 2010-03-04 21:27

cancelling: neverending st... no not really
 
here're some new findings:

primary note: as i can see from the source-code, llrnet-server will prune his joblist and knpairs files only when there's a request/result from any client.
so if the server dried and the joblist contains jobs in process and the results were sent, the server has to push for pruning, say calling 'llrserver -s' for simplifying.

what i have done:
i haven't made any change in the llrnet.lua (same as from Gary's mail sent today) or llrserver.lua.
i started the local server with 20 knpairs. the client WUChacheSize was set to 5.
calling do.bat and the first 5 pairs were tested and sent. from the next 5 pairs, cllr tested 2 and the script was cancelled with CTRL-C.
i converted the 2 results (manually) to tosend.txt and called 'llrnet' -> the 2 results were sent to the server (all now 7 results were in the server-result-file!). delete those 2 pairs from client-workfile.txt.
next i called [b]4[/b] times 'llrnet -c', 4 because one more than pairs in the workfile from the client! important!
now the 3 pairs cancelled from the client are listed in the server-joblist with
"status"="abandonned" and "result"="CANCEL"!

could someone please check this behaviour before i edit the luas!

perhaps a final 'llrserver -s' will do the same when 'llrnet -c' called 3times only.

kar_bon 2010-03-04 21:46

new test:

almost same procedure as before:
- 5 pairs done and sent to server
- [b]without[/b] removing those 2 pairs from the client-workfile, converting/submitting the 2 results to server and calling 'do -c' and a separate 'llrnet -c' again
-> server got 7 results, 3 cancelled pairs still in server-knpair-file, joblist contains 3 cancelled pairs with abandonned/CANCEL!

please check this, too.

so it seems, there's only an extra -c call from llrnetclient to do the cancelling correct, perhaps a server -s could be necessary.

short:
- submit all pairs done by cllr to the server
- calling llrnet -c 1times-more-than-pairs-in-workfile
- (perhaps call llrserver -s)

that seems all!

kar_bon 2010-03-04 23:30

ok, [url=www.rieselprime.de/dl/LLRnetV07.zip]here[/url] is the WIN-version of the local server/client with the above changes in the do.bat and a knpair-file in the server for testing.

how to:
- start the server by calling 'llrserver' (in folder LLRnet_server)
- start 'do.bat' (in folder LLRnet_client)
- let cllr do 5 pairs first and another 2
- stop the client with CTRL-C
- call 'do -c'
- stop server
- call 'simplify.bat' (in folder LLRnet_server)

check all files (server-result, job/knpair-files, client results) for completeness!

mdettweiler 2010-03-05 02:06

[quote=kar_bon;207394]ok, [URL="http://www.rieselprime.de/dl/LLRnetV07.zip"]here[/URL] is the WIN-version of the local server/client with the above changes in the do.bat and a knpair-file in the server for testing.

how to:
- start the server by calling 'llrserver' (in folder LLRnet_server)
- start 'do.bat' (in folder LLRnet_client)
- let cllr do 5 pairs first and another 2
- stop the client with CTRL-C
- call 'do -c'
- stop server
- call 'simplify.bat' (in folder LLRnet_server)

check all files (server-result, job/knpair-files, client results) for completeness![/quote]
Quick question: how is one supposed to check to see if a pair's been canceled when running simplify.bat at the end triggers a prune? That pretty much always removes any "canceled" records from joblist.txt--after all, there's no reason for the server to keep those around since there's no reservation whatsoever on the pair. I suppose one could just verify that no active reservation is still in place, but wouldn't it be easier to just search for all instances of the pair in question in joblist.txt and see what it's latest state is (reserved, canceled, or done)?

kar_bon 2010-03-05 06:20

the simplify.bat is only for persons running a server, not for 'normal' users doing work for NPLB.

so how it works now? if a pair is cancelled by a user, will the server instantly submit it to the next user requesting new pairs? could you determine this, please.

all submitted results in the result-file of the server (nothing lost), all not-done pairs are still in the knpairs.txt of the server (nothing lost, too) and the CANCEL-pairs in the joblist should be eliminated when jobMaxTime is over. or not?

i'll try this by setting the jobMaxTime to a small value and try to connect with another user, do work and submit pairs.

mdettweiler 2010-03-05 07:19

[quote=kar_bon;207426]the simplify.bat is only for persons running a server, not for 'normal' users doing work for NPLB.

so how it works now? if a pair is cancelled by a user, will the server instantly submit it to the next user requesting new pairs? could you determine this, please.

all submitted results in the result-file of the server (nothing lost), all not-done pairs are still in the knpairs.txt of the server (nothing lost, too) and the CANCEL-pairs in the joblist should be eliminated when jobMaxTime is over. or not?

i'll try this by setting the jobMaxTime to a small value and try to connect with another user, do work and submit pairs.[/quote]
Here's what happens:

-A pair is reserved and a notation of such is made in joblist.txt
-The same pair is canceled, and an additional notation is made in joblist.txt recording that. Note that both the reservation and cancellation joblist entries coexist, but the cancellation takes precedence since it has a newer timestamp.
-The pair is now considered immediately available for assignment just as if it was brand new.
-When the server does its next prune, it will remove both the reservation and cancellation records from joblist, since the latter negates the former and the pair is "good as new".

kar_bon 2010-03-05 12:44

i've tested more with that new version:
- all pairs done without stopping the script with CTRL-C
- script stopped and continued later
- script stopped, some pairs cancelled and continued
- script stopped, some pairs cancelled and continued with other user

all is ok as i can say now.
the only thing, that should be done on the server-side when dried is, calling 2 times "llrserver -s" to clear knpairs and joblist files!

[b]so this is it![/b] (only speak for WIN)
without processing a workfile (which pairs done and which to cancel) and without any 'empty' line!

i've uploaded the latest V7-Version to the former link (small change in do.bat)

mdettweiler 2010-03-05 17:11

[quote=kar_bon;207445]i've tested more with that new version:
- all pairs done without stopping the script with CTRL-C
- script stopped and continued later
- script stopped, some pairs cancelled and continued
- script stopped, some pairs cancelled and continued with other user

all is ok as i can say now.
the only thing, that should be done on the server-side when dried is, calling 2 times "llrserver -s" to clear knpairs and joblist files!

[B]so this is it![/B] (only speak for WIN)
without processing a workfile (which pairs done and which to cancel) and without any 'empty' line!

i've uploaded the latest V7-Version to the former link (small change in do.bat)[/quote]
Karsten, could you possibly re-post the link? I can't find it; I tried the one in the first post of this thread but got version 0.63.

kar_bon 2010-03-05 17:12

see post #198!

mdettweiler 2010-03-05 17:42

[quote=kar_bon;207465]see post #198![/quote]
Ah, thanks, got it now. :smile:

mdettweiler 2010-03-05 18:10

Okay, I tried testing the latest do.bat to cancel pairs, and it seems to have messed up somewhat. I tried it with 4 completed results and one incomplete test in queue, and it produced this output:
[code]+-------------------------------------+
| LLRnet client V0.9b7 with cLLR V3.8 |
| K.Bonath, 2010-02-10, Version 0.7 |
+-------------------------------------+
Current configuration:
server = "nplb-gb1.no-ip.org"
port = 1764
username = "mdettweiler"
WUCacheSize = 5
[2010-03-05 12:58:24]
The server refused your new result :
either someone else computed it already,
either the server is now configured to
work on other numbers.
The server refused your new result :
either someone else computed it already,
either the server is now configured to
work on other numbers.
The server refused your new result :
either someone else computed it already,
either the server is now configured to
work on other numbers.
The server refused your new result :
either someone else computed it already,
either the server is now configured to
work on other numbers.
The server refused your new result :
either someone else computed it already,
either the server is now configured to
work on other numbers.
The server refused your new result :
either someone else computed it already,
either the server is now configured to
work on other numbers.
The server refused your new result :
either someone else computed it already,
either the server is now configured to
work on other numbers.
The server refused your new result :
either someone else computed it already,
either the server is now configured to
work on other numbers.
Cancelling : 197/118072 (600000000000:M:1:2:258)
Could Not Find C:\Documents and Settings\All Users\Documents\prime\NPLB-llrnetnew\workfile
.res
[2010-03-05 12:58:26]
Fetching WU #5/5: 197 118072
Cancelling : 197/118094 (600000000000:M:1:2:258)
[2010-03-05 12:58:28]
Cancelling : 197/118102 (600000000000:M:1:2:258)
[2010-03-05 12:58:28]
Cancelling : 197/118142 (600000000000:M:1:2:258)
[2010-03-05 12:58:28]
Cancelling : 197/118154 (600000000000:M:1:2:258)
[2010-03-05 12:58:29]
Cancelling : 197/118072 (600000000000:M:1:2:258)
[2010-03-05 12:58:29]
No more job to cancel !
All jobs canceled![/code]
First of all, all four completed results are apparently sent but rejected. (I see that there's 8 rejected messages, but that's to be expected since LLRnet's duplicated those messages on the console for as long as I can remember; also as expected, only 4 rejected messages were shown in lresults_hist.txt.) After that, all five jobs were canceled, which I verified on the server was done correctly. The program beeped a few times then exited.

So it seems the cancellation part itself is working all right; the only problem is in sending the completed results before canceling the rest. Any idea why this isn't working? I looked in do.bat but couldn't find anything that could be a culprit, since it appeared that it was doing it in a pretty straightforward way: convert the results, add them to lresults_hist.txt, then run LLRnet to send them.

kar_bon 2010-03-05 18:41

ok, forgot to copy/create the workfile.bak in the cancel-routine!

update do.bat with one line:
[code]
:jobcancel

if not exist lresults.txt goto jobcancel1
[color=red]copy workfile.txt workfile.bak[/color]
gawk -f do_tosend.awk lresults.txt
[/code]

i'll upload the corrected zip immediately!

don't forget to call twice 'llrserver -s' after cancelling with 'do -c'!

mdettweiler 2010-03-05 18:52

[quote=kar_bon;207481]ok, forgot to copy/create the workfile.bak in the cancel-routine!

update do.bat with one line:
[code]
:jobcancel

if not exist lresults.txt goto jobcancel1
[COLOR=red]copy workfile.txt workfile.bak[/COLOR]
gawk -f do_tosend.awk lresults.txt
[/code]

i'll upload the corrected zip immediately!

don't forget to call twice 'llrserver -s' after cancelling with 'do -c'![/quote]Thanks! I'll give it a whirl.

mdettweiler 2010-03-05 19:02

Okay, I tried it in the exact same situation as before (4 pairs done, 1 pair in progress) and it seems to have worked correctly:
[code]+-------------------------------------+
| LLRnet client V0.9b7 with cLLR V3.8 |
| K.Bonath, 2010-02-10, Version 0.7 |
+-------------------------------------+
Current configuration:
server = "nplb-gb1.no-ip.org"
port = 1764
username = "mdettweiler"
WUCacheSize = 5
1 file(s) copied.
[2010-03-05 13:53:57]
Cancelling : 197/121718 (600000000000:M:1:2:258)
[2010-03-05 13:53:58]
Cancelling : 197/121768 (600000000000:M:1:2:258)
[2010-03-05 13:53:58]
Cancelling : 197/121772 (600000000000:M:1:2:258)
[2010-03-05 13:53:59]
Cancelling : 197/121784 (600000000000:M:1:2:258)
[2010-03-05 13:53:59]
Cancelling : 197/121846 (600000000000:M:1:2:258)
[2010-03-05 13:53:59]
No more job to cancel !
All jobs canceled![/code]
The only possible issue I found is a cosmetic one: after the four completed pairs are submitted, all five are then canceled despite there only being one left that's incomplete. Of course the server ignores the cancel requests on the first four since it already has results for them, but still, it might prove rather confusing for users.

The tricky part is how to have the batch file "know" how many WUs were completed and sent in. In do.pl that's done by incrementing a $numResults variable as each result is processed, but that would be impossible for do.bat since it doesn't actually do the processing but rather has gawk do it. Oh, I know! What if you had do.bat count the number of lines in tosend.txt before that's sent? If you take that number minus one (the newline at the end) it should give you the number of completed results done, and from there you can have it remove those from workfile.txt before beginning the actual cancellation process.

[B][COLOR=red]Edit: scratch that, looks like it didn't work. I just started up the client again and it grabbed exactly the same 5 pairs that it did before--including the ones that were already done. It seems the server didn't ignore the cancellation requests on the completed ones as I thought; somehow they were thrown back into the pool to be reassigned.[/COLOR][/B]
[B][COLOR=#ff0000][/COLOR][/B]
[B][COLOR=#ff0000]The fix would be the same as the one I presented above: the only difference being that it's no longer just a cosmetic issue but a real one.[/COLOR][/B]

mdettweiler 2010-03-05 19:06

[quote=mdettweiler;207486][B][COLOR=red]Edit: scratch that, looks like it didn't work. I just started up the client again and it grabbed exactly the same 5 pairs that it did before--including the ones that were already done. It seems the server didn't ignore the cancellation requests on the completed ones as I thought; somehow they were thrown back into the pool to be reassigned.[/COLOR][/B]

[B][COLOR=#ff0000]The fix would be the same as the one I presented above: the only difference being that it's no longer just a cosmetic issue but a real one.[/COLOR][/B][/quote]
Update: it gets even messier. Apparently this confused the server to the extent that it "forgot" entirely that the 4 completed pairs had been done after receiving cancellation requests for them. Now that those pairs have been completed a second time, they're duplicated in results.txt.

kar_bon 2010-03-05 19:10

wordprocessing/counting in dos-batch is not easy to do. gawk is possible to solve that problem, but another .awk to handle.

to the issue:

do again the same test, but be sure delete all files created on client/server.
what i think:
you did 'do -c' and instantly 'do' again! the server have to get (commit) the cancellation first and must given the chance to prune the knpairs and joblist!

try again:
- do
- do -c
- llrserver -s
- llrserver -s
- do

this should work!

mdettweiler 2010-03-05 19:20

[quote=kar_bon;207488]wordprocessing/counting in dos-batch is not easy to do. gawk is possible to solve that problem, but another .awk to handle.

to the issue:

do again the same test, but be sure delete all files created on client/server.
what i think:
you did 'do -c' and instantly 'do' again! the server have to get (commit) the cancellation first and must given the chance to prune the knpairs and joblist!

try again:
- do
- do -c
- llrserver -s
- llrserver -s
- do

this should work![/quote]
Yes, I agree that that should definitely work. But the problem is, while it works in testing, in real use on a public server, a user is not going to be able to log on to the server and run "llrserver -s" every time he's canceled pairs. It's got to be able to work without needing any administrative action on the server. On a reasonably busy public server, somebody else is bound to connect sometime before the server does its next automatic prune--and he'll be assigned duplicate pairs.

kar_bon 2010-03-05 19:27

but than how it work's now?

as i said, pruning could only be done when a command was submitted to the server like requesting new pairs or submitting results.

perhaps we should test this on an 'old' server/client to verify this!

as long the server did no pruning, the pairs just cancelled are still in the joblist as 'working' and 'CANCEL' for the same user, and the 'lowestKnPair' is determined as a pair not in status working/cancelled by another user.
that lowestKnPair is set every time a AskPair hits the server.

mdettweiler 2010-03-05 19:32

[quote=kar_bon;207491]but than how it work's now?

as i said, pruning could only be done when a command was submitted to the server like requesting new pairs or submitting results.

perhaps we should test this on an 'old' server/client to verify this![/quote]
In the old client, all results are submitted as soon as they're done, so theoretically there will be no completed workunits in workfile.txt to worry about when canceling. All it has to do is cancel whatever's up next in workfile.txt, no questions asked.

kar_bon 2010-03-05 19:47

so your suggestion: simulate more the normal llrclient with script!?

means:
- receive number of pairs
- test one pair
- submit that result when test complete and delete pair from workfile.txt
- next test

- if no workunits = workfile.txt empty
-> receive next pairs

so when the script is stopped, the workfile.txt only contains pairs not done yet.

perhaps this could work.

mdettweiler 2010-03-05 20:06

[quote=kar_bon;207493]so your suggestion: simulate more the normal llrclient with script!?

means:
- receive number of pairs
- test one pair
- submit that result when test complete and delete pair from workfile.txt
- next test

- if no workunits = workfile.txt empty
-> receive next pairs

so when the script is stopped, the workfile.txt only contains pairs not done yet.

perhaps this could work.[/quote]
No, that's not quite what I was thinking. What I was trying to say is that since the script works differently than the old LLRnet client, the old client's not going to give us any help in solving this.

Here's what I'd suggest we have it do:
-Continue to use the gawk script to process the lresults files as always.
-However, before the cancellation code sends in the newly-produced tosend file, have it count the # of lines in it first. Let this be x for the purposes of this description.
-Then, remove the first x k/n pairs from workfile.txt. Possibly a second gawk script could be used to do this.
-Then, proceed to cancel whatever's left.

That's essentially what do.pl does, but adapted to the fact that do.bat uses gawk to do the processing.

kar_bon 2010-03-05 20:09

ok, i can do this the next hour, i think.

kar_bon 2010-03-05 21:35

i've got a second gawk-script to delete the first processed pairs of the workfile.txt.
i also changed the do.bat for this.

i've just uploaded the new version for testing!

mdettweiler 2010-03-05 22:39

[quote=kar_bon;207511]i've got a second gawk-script to delete the first processed pairs of the workfile.txt.
i also changed the do.bat for this.

i've just uploaded the new version for testing![/quote]
Tested and--it works! :banana:

Both scripts should be all set now--I believe the only thing left to do is the big stress test Gary had planned, hmm?

kar_bon 2010-03-05 22:46

i have to test the new cancel-functionality with 0/5, 2/5 or 5/5 tests done from reserved and cancelling. also cancel and just get new pairs.

and the n=1-1000 test from Gary, too.

kar_bon 2010-03-07 12:28

i've done these tests:
- Riesel Base 2 and 3 for n=1 to 1000, unsieved
- Sierpinski Base 2 and 3 for n=1 to 1000, unsieved

for the Sierp-base3 some pairs were rejected because of this:
[code]
5000000000000:M:1:2:258 111546435 1 -2 trial_factored
5000000000000:M:1:2:258 111546435 2 -2 trial_factored
5000000000000:M:1:2:258 111546435 3 -2 trial_factored
5000000000000:M:1:2:258 37182145 5 -2 00000000D2576673
5000000000000:M:1:2:258 37182145 6 -2 00000002A13F8C65
5000000000000:M:1:2:258 37182145 7 -2 00000000DAF1D0B3
5000000000000:M:1:2:258 37182145 8 -2 0000000000000003
5000000000000:M:1:2:258 37182145 9 -2 0000005B8EA2792F
5000000000000:M:1:2:258 37182145 10 -2 000000B90D033B33
5000000000000:M:1:2:258 37182145 11 -2 000002BE41FF18BF
5000000000000:M:1:2:258 37182145 12 -2 00000E0DEA87A431
5000000000000:M:1:2:258 37182145 13 -2 000023D502B963B3
5000000000000:M:1:2:258 37182145 14 -2 0000136EA66DF8C3
5000000000000:M:1:2:258 37182145 15 -2 0000C22287CBEA43
5000000000000:M:1:2:258 111546435 15 -2 00009DDFFF61E0CF
5000000000000:M:1:2:258 111546435 16 -2 0002743D96B041CB
5000000000000:M:1:2:258 111546435 17 -2 0000372E14DB2E1B
5000000000000:M:1:2:258 111546435 18 -2 000000000000001B
5000000000000:M:1:2:258 111546435 19 -2 00438DE7AFF3AA87
5000000000000:M:1:2:258 111546435 20 -2 000000000000001B
[/code]

LLR changed the kn-value (111546435 divisible by 3 so exponent +1).

so as we assumed: this has to be done by the person filling in the knpairs.txt into the sever: be sure the k-values are 'normalized'.

but i found another issue in WIN-(c)LLR:
Riesel base 3 caused an error, stopping LLR, the same in cLLR.
the first error occurs when n=89 from starting at n=1. it does not occur whit n=89 alone!

i've sent Jean a mail about this!

i've also tested Gary 'big testfile' with 179883 knpairs: i found 533 primes (no rejected pairs).

gd_barnes 2010-03-07 22:30

[quote=mdettweiler;207319]@Gary: sounds like a plan. I've uploaded the latest files to the web.

Could you also send me your latest README.txt file for do.pl? I must not have the latest as mine still has the "code" in three places in one sentence. :smile: I looked in my PM box but couldn't find a PM from Karsten detailing changes that needed to be made to the readme; when I get your latest one I'll read it over in depth and fix any problems I find.[/quote]


Please reread the last post about README. Thanks.

gd_barnes 2010-03-07 22:38

I just don't have time to read the tremendous amount of info. that came through in the last 2-3 days. Can someone pleae give me a synopsis? It looks like there were quite a few server file changes.

The main thing: Will the Windows cancellation process act just like (or very similar to the Linux cancellation process)?

I just don't want the user to have to do several runs to return processed results and cancel remaining pairs.

I'm sorry if this causes extra work but: Can one of you post both the new Windows and Linux server and client (all files)? I'm ask for both because I am assuming that a couple of the server files were changed also.


Thanks,
Gary

kar_bon 2010-03-07 22:45

the latest version is available under the link in post #198.

the cancelling in my WIN-version was implemented only by changing the do.bat and a new gawk-script/-call:

- submitting results in tosend.txt by the client
- delete these pairs from the client-workfile.txt
- cancelling the remaining knpairs in workfile.txt

(i think the same way like the do.pl)

nothing else!

mdettweiler 2010-03-08 04:02

[quote=gd_barnes;207684]I just don't have time to read the tremendous amount of info. that came through in the last 2-3 days. Can someone pleae give me a synopsis? It looks like there were quite a few server file changes.

The main thing: Will the Windows cancellation process act just like (or very similar to the Linux cancellation process)?

I just don't want the user to have to do several runs to return processed results and cancel remaining pairs.

I'm sorry if this causes extra work but: Can one of you post both the new Windows and Linux server and client (all files)? I'm ask for both because I am assuming that a couple of the server files were changed also.


Thanks,
Gary[/quote]
As Karsten said, the only change was to the Windows script, and yes, it now works just like the Linux one with regard to the cancellation process.

As for the server and client, I'm pretty sure that absolutely no changes were made to the server. Karsten, is that correct?

Here are the links to the latest do.pl packages:
[URL="http://nplb-gb1.no-ip.org/sieves/llrnet-script-perl-0.70-win32.zip"]WIN32[/URL]
[URL="http://nplb-gb1.no-ip.org/sieves/llrnet-script-perl-0.70-linux32.zip"]Linux32[/URL]

And here's the link to the latest do.bat package:
[URL]http://www.rieselprime.de/dl/LLRnetV07.zip[/URL]
Note that this includes a copy of the server as well (preconfigured for a test scenario Karsten was using) but I'm pretty sure there are no differences in it from the standard server code that we're using on all the NPLB servers, aside from the date/time formatting.

mdettweiler 2010-03-08 04:10

[quote=gd_barnes;207682]Please reread the last post about README. Thanks.[/quote]
Yes, I read [url=http://www.mersenneforum.org/showpost.php?p=207339&postcount=193]that[/url]. However, while I have the version of the readme from you that changed the wording to 3rd person, my latest copy still has the word "code" in the first sentence rather redundantly, which you mentioned you fixed; as such I'm not sure if I have your latest rewrite to use as a starting point for further changes.

gd_barnes 2010-03-08 07:21

[quote=mdettweiler;207701]As Karsten said, the only change was to the Windows script, and yes, it now works just like the Linux one with regard to the cancellation process.

As for the server and client, I'm pretty sure that absolutely no changes were made to the server. Karsten, is that correct?

Here are the links to the latest do.pl packages:
[URL="http://nplb-gb1.no-ip.org/sieves/llrnet-script-perl-0.70-win32.zip"]WIN32[/URL]
[URL="http://nplb-gb1.no-ip.org/sieves/llrnet-script-perl-0.70-linux32.zip"]Linux32[/URL]

And here's the link to the latest do.bat package:
[URL]http://www.rieselprime.de/dl/LLRnetV07.zip[/URL]
Note that this includes a copy of the server as well (preconfigured for a test scenario Karsten was using) but I'm pretty sure there are no differences in it from the standard server code that we're using on all the NPLB servers, aside from the date/time formatting.[/quote]


Thanks for posting all of those Max.

OK, that was what I was wondering about on the servers. The date/time formatting. I don't think I mentioned that in my "guidelines" post about who does what. Has the Linux server date/time been synced up with the Windows server date/time formatting?

I suppose that might be a dumb question. Maybe the code is exactly the same on both since it's an LUA file. If so, just let me know.

What I'll want to make sure is that we get the exact correct files posted for everyone for both Windows and Linux. I don't want to end up with one set of server files on one and a different set of server files on the other. (Well, in this case, it would [I assume] be only one file difference if we didn't get the date-time formatting updated on the Linux server.)


Gary

gd_barnes 2010-03-08 07:43

[quote=mdettweiler;207702]Yes, I read [URL="http://www.mersenneforum.org/showpost.php?p=207339&postcount=193"]that[/URL]. However, while I have the version of the readme from you that changed the wording to 3rd person, my latest copy still has the word "code" in the first sentence rather redundantly, which you mentioned you fixed; as such I'm not sure if I have your latest rewrite to use as a starting point for further changes.[/quote]

That's not the right one. Obviously I'm beating my head against the wall.

Clearly you're misunderstanding my points:

1. I never said I corrected "code". Can you show where I said that? I asked you to do that.

2. You have the latest version of README. It's in the client that I sent by Email right before I left. Can you show where I said that's not the latest one?


I was quite frustrated by all of this misremembering that is going on. If you wanna see why, just read my deleted posts. If not, don't worry about it.

The bottom line is that what you have is what needs to be updated to correct one paragraph and remove so many "codes" in another sentence. That's all. Nothing more...nothing less. :smile:


Gary

kar_bon 2010-03-08 08:32

first of all:

i've corrected the do.pl-links in both recent posts: they were done with (...) in it!

and again to the date-format:

the only change of 'code' is the entry in the llr-serverconfig.txt.

this file [b]must[/b] contain the lines:
[code]
function DisplayDate()
return date("%Y-%m-%d\ %H:%M:%S")
end
[/code]

when the server is started, the function is in the llrserver.lua declared.
but then the llr-serverconfig.txt will be loaded and the 'internal' function is
overwritten by the 'external' one!

no changes in LUA's!!!!!

so this is in the hand of the server-guy, not the client!

kar_bon 2010-03-08 17:10

Gary, i know you don't want much more changes before releasing this working script.

so decide if you/we want this one, too:

as we know, llrnet-server will write the time of a test as the timeframe from submitting the pair to the client and getting back the result from the client.

so timings for your current G6000-work says about 2400 seconds for a test, but you got a WUCacheSize of 5 (if i'm right) and therefore the correct timings has to be about 480 secs!

yesterday/today i've changed 4 files (client.lua, llrnet.lua, do_tosend.awk, llserver.lua) and the right timings will be saved in the llrserver-result-file!

i have to do some more tests with 'exceptions' and cancelling but it seems to work fine!


what i want to do before making the script official (with or without the above):

tidy up the llrclient- and llrserver-folders:
llrserver don't need for example gui.lua, so why is this file in there!?

(my) other wish is to release a 'minimum' server/client-pair: the less the user have to look at, the less errors occurs and the easier to install such package:
- no GUI
- no SQL
- no proxy
- minimum config-files

but this can wait (Note: the latter 3 i've done so far!)

kar_bon 2010-03-08 21:01

ok, guys. look and test a little bit with some new things mentioned above.

a new Version 0.8 is [url=www.rieselprime.de/dl/LLRnetV08.zip]here[/url].

see the ReadMe for some notes.

for testing under Unix, the do.pl have to be changed (a little bit easier now, see notes).


PS: Jean has uploaded a new developer-version for LLR3.8 [url=http://jpenne.free.fr/Development/]here[/url], which should handle the error with the Riesel Base 3 test (n=1-1000) i mentioned. i will test this.

gd_barnes 2010-03-08 23:58

I'm now taking the time to read all posts in detail. Before I post any more questions, I'll be sure and read them all, since sometimes a question is answered in a later post.

Sorry about the lack of time since Thursday.

mdettweiler 2010-03-09 00:14

[quote=gd_barnes;207711]That's not the right one. Obviously I'm beating my head against the wall.

Clearly you're misunderstanding my points:

1. I never said I corrected "code". Can you show where I said that? I asked you to do that.

2. You have the latest version of README. It's in the client that I sent by Email right before I left. Can you show where I said that's not the latest one?


I was quite frustrated by all of this misremembering that is going on. If you wanna see why, just read my deleted posts. If not, don't worry about it.

The bottom line is that what you have is what needs to be updated to correct one paragraph and remove so many "codes" in another sentence. That's all. Nothing more...nothing less. :smile:


Gary[/quote]
Oh, okay, I get it now. :smile: In that case, then, I'll make the changes to the one I've got.

mdettweiler 2010-03-09 00:16

[quote=kar_bon;207731]Gary, i know you don't want much more changes before releasing this working script.

so decide if you/we want this one, too:

as we know, llrnet-server will write the time of a test as the timeframe from submitting the pair to the client and getting back the result from the client.

so timings for your current G6000-work says about 2400 seconds for a test, but you got a WUCacheSize of 5 (if i'm right) and therefore the correct timings has to be about 480 secs!

yesterday/today i've changed 4 files (client.lua, llrnet.lua, do_tosend.awk, llserver.lua) and the right timings will be saved in the llrserver-result-file!

i have to do some more tests with 'exceptions' and cancelling but it seems to work fine!


what i want to do before making the script official (with or without the above):

tidy up the llrclient- and llrserver-folders:
llrserver don't need for example gui.lua, so why is this file in there!?

(my) other wish is to release a 'minimum' server/client-pair: the less the user have to look at, the less errors occurs and the easier to install such package:
- no GUI
- no SQL
- no proxy
- minimum config-files

but this can wait (Note: the latter 3 i've done so far!)[/quote]
Hmm...interesting idea. However, the tricky thing with that is it makes the server not compatible with older "original" LLRnet clients, which are quite widely disseminated and which I imagine will continue to be for a while. Gary, what do you think?

gd_barnes 2010-03-09 01:23

OK, guys, I've taken the time to read all of the posts in detail. My head is totally spinning right now. I wish I had had time to be involved on a daily basis.

First, Karsten, was Max's answer to the Frobenius PRP issue satisfactory? That is: We just show it as "Prime!" in the server results. I think that is acceptable and requires no script changes anywhere. People need to know if they are running such small tests that they may need to do primality proofs on their PRPs. At this point in time anyway, the server will not differenciate between PRPs and primes.

Second, Karsten, I've "kind of" asked that we please stop the "scope creep". We can keep improving and correcting, improving and correcting, testing, testing, improving, correcting, etc. until the end of time. We need to stop somewhere. Clearly we're ready to go now and I don't want Max or me to have to make any more changes to the Linux client. So in answer to your comments about changing the testing time on the server: No, please don't do that.

Third, Max, 3 questions about the clients that you posted on March 7th:
(1) Are they the latest ones? (Don't count any subsequent changes that Karsten is making for the servers results testing time.)
(2) Do both clients have the date format changes that Karsten requested?
(3) Are they completely synced up? That includes all script and .lua files.

Sorry if I'm not understanding anything. I still have a lot to do on the CRUS pages and couldn't spend any more time re-reading posts that may have confused me just a little.


Gary

mdettweiler 2010-03-09 02:43

[quote=gd_barnes;207776]Third, Max, 3 questions about the clients that you posted on March 7th:
(1) Are they the latest ones? (Don't count any subsequent changes that Karsten is making for the servers results testing time.)[/quote]
Yes.
[quote](2) Do both clients have the date format changes that Karsten requested?[/quote]
The date format changes are for the server only; they don't apply at all for the client. And to answer the question I know you're going to have next, yes, all of our servers are completely correct as far as the date formats go; we standardized on our current format a while back and now it's specified in all of our llr-serverconfig.txt files.
[quote](3) Are they completely synced up? That includes all script and .lua files.[/quote]
Yes. The latest (0.7) do.pl is synchronized with the latest do.bat (the latest 0.7 version of it, that is, not 3.8 which is for the testing-time changes).

kar_bon 2010-03-09 06:49

so we are ready to roll out?

what about the ReadMe for the WIN-script? the used options are slightly different named as in the do.pl. are those explained in the ReadMe, too?

is there a note for k's multiple of bases in the ReadMe, or bases like Riesel-16?
small n-values with bigger k-values?

next question:

where should we announce this new script? only here in NPLB-subforum, or in the Software-thread, (too)?

another thought that came up yesterday:
because of the new step of the script (LLR do the work, saves a lresults-file, and the conversion to tosend.txt is done after all) there's a more easier way to manipulate the result-files. so edit the value "-2" in the tosend.txt into "0" and that pairs would be send as prime to the server!
suggestion for NPLB: confirm all non-Top5000 primes by a seperate test after submitting to the server! (evil in me out :smile:)

so this whole script was done for Win and Linux in about 4 weeks with many testings an error-eliminating and it could even be better in the future. so i have time for new things to do. thanks to all for testing!

Karsten

mdettweiler 2010-03-09 17:54

[quote=kar_bon;207797]so we are ready to roll out?

what about the ReadMe for the WIN-script? the used options are slightly different named as in the do.pl. are those explained in the ReadMe, too?[/quote]
I was writing my readme.txt just for do.pl; I figured you'd write one for do.bat.

[quote]is there a note for k's multiple of bases in the ReadMe, or bases like Riesel-16?
small n-values with bigger k-values?[/quote]
Yeah, it probably would be good to make note of the multiple-of-base k's in the readme. Original LLRnet needed to have those pre-converted as well for optimal speed, but it wasn't strictly necessary as it would still at least work without it, so it would be a good thing to note. I'll do that when I touch up the readme.

[quote]next question:

where should we announce this new script? only here in NPLB-subforum, or in the Software-thread, (too)?[/quote]
From what Gary was saying before I think we'd want to do it just here in the NPLB forum. Client/server software like this has always had a bit lower profile than the manual versions of the applications anyway; LLR and PFGW, for instance, have been announced in the Software forum but not LLRnet and PRPnet. Gary, what are your thoughts on this?

[quote]another thought that came up yesterday:
because of the new step of the script (LLR do the work, saves a lresults-file, and the conversion to tosend.txt is done after all) there's a more easier way to manipulate the result-files. so edit the value "-2" in the tosend.txt into "0" and that pairs would be send as prime to the server!
suggestion for NPLB: confirm all non-Top5000 primes by a seperate test after submitting to the server! (evil in me out :smile:)[/quote]
Hmm, you're right. I'd thought the same thing before, that we should try to confirm all non-top-5000 primes separately since they're not being verified by the top-5000 site. I suppose they'll eventually be done in doublechecking but it might be good to do them more immediately, especially considering as how it would be just a wee bit easier to "fake" a prime with these new scripts. (Actually, it's possible to do using a similar process with the old LLRnet client, and in fact probably just as easy...but, nontheless, that just underscores the importance of verifying primes. :smile:)

kar_bon 2010-03-09 23:19

i've just uploaded a 'new' version 0.70 to the known address.

new is only the ReadMe.txt for my Win-version.

please check this for typos or 'bad' English! thanks.

gd_barnes 2010-03-10 22:28

[quote=kar_bon;207883]i've just uploaded a 'new' version 0.70 to the known address.

new is only the ReadMe.txt for my Win-version.

please check this for typos or 'bad' English! thanks.[/quote]


Max,

Having you check the Windows ReadMe for grammar/English is the only thing I'd see left to do. Karsten is OK with that. I'd only ask that it be kept in 3rd person.


Gary

gd_barnes 2010-03-10 22:32

[quote=kar_bon;207797]
another thought that came up yesterday:
because of the new step of the script (LLR do the work, saves a lresults-file, and the conversion to tosend.txt is done after all) there's a more easier way to manipulate the result-files. so edit the value "-2" in the tosend.txt into "0" and that pairs would be send as prime to the server!
suggestion for NPLB: confirm all non-Top5000 primes by a seperate test after submitting to the server! (evil in me out :smile:)
Karsten[/quote]


I'm sorry but I just cannot figure out what this means at all. If someone's machine finds a prime, it's a prime, and it's sent to the server as a prime. We don't need to double check anything right away. We do that several years down the road.

Why would we ever edit -2 to 0 in the tosend.txt file to make the server think that a composite is a prime?

Max, why we would need to "confirm" all non-top 5000 primes? Think about it. The only primes that "might" be PRPs are n<1000. We never check n-values that low. Anything from n=1K to ~490K is definitely a non-top-5000 prime if someone's machine says it is a prime. It won't be "confirmed" until it is eventually double checked.

Are you guys referring to very small primes/PRPs such as Frobenius PRPs? We certainly don't need any more code in there for checking those in some fashion.

Max, you may have to explain this one to me. :-)


Gary

gd_barnes 2010-03-10 22:40

[quote=kar_bon;207797]where should we announce this new script? only here in NPLB-subforum, or in the Software-thread, (too)?
Karsten[/quote]

As Max alluded to, let's keep it somewhat low key and let others "find" it. I suggest simply putting it in the LLRnet servers for NPLB thread. Technically it will still be in a "beta" test phase because we haven't put a "real" 100 cores on it yet. I tried to simulate that by putting 30 cores on small tests but the # of sockets that are opened at once is still limited to the # of requests received at the same time by all cores. So that's not quite a "real" stress test, even if the testing time makes it like several 1000 cores.

If you guys disagree, I understand. Let's let the majority rule here so I'll place the 1st vote to keep it low key in the LLRnet servers thread. The other main option would be to put in the "News" thread with a link to a new thread about the new client. That would make it much more highly visible.

Karsten, you came up with the idea. If you feel strongly enough about a certain way to roll it out, I'll step aside and let you decide.


Gary

kar_bon 2010-03-10 22:42

[QUOTE=gd_barnes;208012]I'm sorry but I just cannot figure out what this means at all. If someone's machine finds a prime, it's a prime, and it's sent to the server as a prime.[/QUOTE]

i'm just inserting the 'small' primes from the 12th drive into rieselprime.de for n=50k-250k.
i found many k's done by T.Ritschel some years ago with the note, the range from n=200k-350k were done by him. but i found many missing pairs in this range.

so if we don't test any non-Top5000 prime as prime, we are not sure about it! those are first-time testings without any old results to compare.

kar_bon 2010-03-10 22:45

[QUOTE=gd_barnes;208013]The other main option would be to put in the "News" thread with a link to a new thread about the new client. That would make it much more highly visible.[/QUOTE]

i prefer this option most:
- post in news with link to separate thread
- own thread for these script, to collect suggestions/issues/notes/meanings/...

mdettweiler 2010-03-10 23:12

[quote=gd_barnes;208012]I'm sorry but I just cannot figure out what this means at all. If someone's machine finds a prime, it's a prime, and it's sent to the server as a prime. We don't need to double check anything right away. We do that several years down the road.

Why would we ever edit -2 to 0 in the tosend.txt file to make the server think that a composite is a prime?

Max, why we would need to "confirm" all non-top 5000 primes? Think about it. The only primes that "might" be PRPs are n<1000. We never check n-values that low. Anything from n=1K to ~490K is definitely a non-top-5000 prime if someone's machine says it is a prime. It won't be "confirmed" until it is eventually double checked.

Are you guys referring to very small primes/PRPs such as Frobenius PRPs? We certainly don't need any more code in there for checking those in some fashion.

Max, you may have to explain this one to me. :-)


Gary[/quote]
I think what Karsten was meaning to say was that it would be slightly easier for someone with malicious intent to game the system with this new client: only a small change to the script would be required to have it send fake primes to the server. Since we've had malicious attacks on our servers in the past (read: Carlos) I think it would be wise to verify non-top-5000 primes to make sure they're good. (This could be done, say, at the end of a n=100K range when you're matching up master results files to the corresponding sieve files.)
[quote=gd_barnes;208013]If you guys disagree, I understand. Let's let the majority rule here so I'll place the 1st vote to keep it low key in the LLRnet servers thread. The other main option would be to put in the "News" thread with a link to a new thread about the new client. That would make it much more highly visible.[/quote]
I'm inclined to agree with Karsten here--it would probably be best to give it the visibility of its own thread and an announcement in the News thread. It's kind of tempting to keep this as NPLB's "ace in the hole" for a while to give us an edge over other top-5000 projects but in reality it won't really affect us much (since our main competitors, RPS and PrimeGrid, don't use LLRnet in any form or fashion anyway).

gd_barnes 2010-03-12 21:34

OK, thanks Max. That makes sense to me now about verifying all non-top-5000 primes. Actually, I think I did that in the past for k<2000; at least for n<200K. But I didn't do it for k=2000-3000 for n=50K-250K. Good idea Karsten.

I had thought about what you guys said here a little late last night and today. I agree now. It makes sense to give it good visibility. Good thinking there. I like the idea of posting it in the news with a link to its own thread. There's enough in the "LLRnet servers for NPLB thread" already. The new "Updated/improved (or whatever) LLRnet client" thread can be used as both a question/answer thread as well as for large-scale beta testing with associated issues ironed out.

Assuming the Linux README has been tweaked as per the previous issues and Max has reviewed Karsten's documentation for grammar/English and made any appropriate changes, do it!

Exciting times lie ahead!

Karsten, once again, thank you for a great idea! Your original design really only needed a small amount of modifications from the time that you conceived of it. Max, once again, thank you for quickly converting Karsten's Windows logic into a very workable Linux client that also only needed small modifications to make it work completely correctly. The original concept and design on both sides was excellent to start with and when that happens, it usually makes for relatively easy testing and good software at the end. As many issues as we found, they were really very small ones.

This was a smashing success in just a month and now we have something that we'll be able to use for years to come! :smile:

It even deserves a few of my favorite dancing Georges:

:george::george::george::george::george:


Let's rock!


Gary

kar_bon 2010-03-12 21:40

ok then.

which title for the script-thread?

"(NPLB's version of) LLRnet with LLR V3.8"?

"The Raiders Ark is here: LLRnet supports LLR V3.8!"

"A new Dimension in Prime-Hunting: LLRnet combined with LLR V3.8"

any others?

gd_barnes 2010-03-12 21:41

Just a note for you guys:

Weekends on business trips are insanely busy for me. I'll likely only make it on to answer pressing questions in the forums and in Email and to report primes; perhaps for a half-hour at most.

I will be back late Monday but have some family matters to tend to. By Tuesday, I'll be back in full swing of the projects. I kind of had to "pay the piper" finally for spending 3-4 hours/day on the projects almost non-stop for the month before I left and this busy time is my payment. lol Unfortunately I'm not retired just yet but I know I'll stay busy when I am. :-)

Either one of you, if you can help answering any others questions or anything else adminstratively on the proejcts at this time, that would be greatly helpful.

Max, you might keep an eye on the public and private servers. I think you usually do anyway. It appears that port 6000 will need loading up before Monday.

Thanks again guys.


Gary

gd_barnes 2010-03-12 21:48

[quote=kar_bon;208203]ok then.

which title for the script-thread?

"(NPLB's version of) LLRnet with LLR V3.8"?

"The Raiders Ark is here: LLRnet supports LLR V3.8!"

"A new Dimension in Prime-Hunting: LLRnet combined with LLR V3.8"

any others?[/quote]

I like the last one and can't think of any others off the top of my head. Max, any ideas?

One thing that I thought of: I wonder if the original design of LLRnet was the way it was for security reasons. In other words, was it "static" in its LLR version so that people could not easily "fake" primes? Well, they could but it wouldn't be as easy. So...for security reasons, I wonder if for a future release, there would be an easy way to make the Awk and Perl scripts into only an executable/binary for the client with no source code available for them? That way, it would take some serious effort for someone to reverse-engineer it back to the source code and change the code in order to fake results and/or primes or non-primes.


Gary

kar_bon 2010-03-12 21:53

[QUOTE=gd_barnes;208205]I like the last one and can't think of any others off the top of my head. Max, any ideas?

One thing that I thought of: I wonder if the original design of LLRnet was the way it was for security reasons. In other words, was it "static" in its LLR version so that people could not easily "fake" primes? Well, they could but it wouldn't be as easy. So...for security reasons, I wonder if for a future release, there would be an easy way to make the Awk and Perl scripts into only an executable/binary for the client with no source code available for them? That way, it would take some serious effort for someone to reverse-engineer it back to the source code and change the code in order to fake results and/or primes or non-primes.

Gary[/QUOTE]


i've found a batch-script 'compiler' but not tested it yet (it makes in WIN-Dos a *.com from a batch file).
OTOH i even don't know why there's a llrnet.exe (with LLRV3.5 included/compiled) but there exists the *.lua files also! perhaps all could be compiled in one exe!?

so i will create that new thread the next hour (with note in News, too).
the name could be changed later if we find a better one!

i take the last links of the downloads: 2 from Max and the one from me.
could be changed later, too!

gd_barnes 2010-03-12 22:18

[quote=kar_bon;208206]i've found a batch-script 'compiler' but not tested it yet (it makes in WIN-Dos a *.com from a batch file).
OTOH i even don't know why there's a llrnet.exe (with LLRV3.5 included/compiled) but there exists the *.lua files also! perhaps all could be compiled in one exe!?

so i will create that new thread the next hour (with note in News, too).
the name could be changed later if we find a better one!

i take the last links of the downloads: 2 from Max and the one from me.
could be changed later, too![/quote]

I don't have time to check them. Has Max tweaked the Linux README and reviewed your documentation for grammar/English?

kar_bon 2010-03-12 22:19

[QUOTE=gd_barnes;208207]I don't have time to check them. Has Max tweaked the Linux README and reviewed your documentation for grammar/English?[/QUOTE]

i don't know, he has nothing said about that!

mdettweiler 2010-03-12 22:42

[quote=gd_barnes;208207]I don't have time to check them. Has Max tweaked the Linux README and reviewed your documentation for grammar/English?[/quote]
No, sorry, I haven't done that yet. I'm really busy today and tomorrow; can it by chance wait until after then?

I don't think we need to worry about "statifying" the program to make it more secure. That's not really a particularly big deal and it defeats the whole purpose of making the application modular so that new LLR versions can be used. At any rate, if someone's really set on faking primes, they can do it with the old LLRnet client if they want. It might be a tad harder but not much so--I can think of a way right off the top of my head that would work and be reasonably easy.

gd_barnes 2010-03-14 09:44

Max,

No it CANNOT wait any longer than the 10 days that it has already waited. The clients have been released! Nor can loading port 6000 wait.

But the CRUS results that I didn't really need, those got processed right away. Priorities straight please!

I'll do both of them on Sunday during my business trip.


Gary

mdettweiler 2010-03-14 20:24

[quote=gd_barnes;208349]Max,

No it CANNOT wait any longer than the 10 days that it has already waited. The clients have been released! Nor can loading port 6000 wait.

But the CRUS results that I didn't really need, those got processed right away. Priorities straight please!

I'll do both of them on Sunday during my business trip.


Gary[/quote]
Thanks, that works. (I ididn't know about port 6000 though. :smile:)

As for the CRUS results, whoops, sorry about that...I'd completely forgotten about the readme thing. I've been especially busy over the last week or so and that's why I didn't remember, whereas the results processing jobs came to mind right when I had just enough time to squeeze them in...hence why they got done and the readme didn't. :rolleyes:

gd_barnes 2010-03-14 21:43

1 Attachment(s)
[quote=gd_barnes;208204]Just a note for you guys:

Weekends on business trips are insanely busy for me. I'll likely only make it on to answer pressing questions in the forums and in Email and to report primes; perhaps for a half-hour at most.

I will be back late Monday but have some family matters to tend to. By Tuesday, I'll be back in full swing of the projects. I kind of had to "pay the piper" finally for spending 3-4 hours/day on the projects almost non-stop for the month before I left and this busy time is my payment. lol Unfortunately I'm not retired just yet but I know I'll stay busy when I am. :-)

Either one of you, if you can help answering any others questions or anything else adminstratively on the proejcts at this time, that would be greatly helpful.

Max, you might keep an eye on the public and private servers. I think you usually do anyway. It appears that port 6000 will need loading up before Monday.

Thanks again guys.


Gary[/quote]

So I guess the above was not clear enough about port 6000, huh?

Doing the README would have taken 10-15 mins. Are you telling me that the results would have taken less? I think not. The README was asked for 3 different times. How could it keep getting forgotten?

Priorities please!

So I've now lost an hour out of my business trip. I've now loaded up port 6000 and updated the drive, which took way longer than it should have because of the terrible remote access that I now have. That's why I asked you to do it.

Karsten is busier than either of us. Maybe we need to give him remote access to my machines to load up servers. You know, if you need something done, give it to a busy person. It will get done! :smile:

Attached is the updated Linux README. Karsten, can you review the 1st line of the 1st para. and the updated para. about your patches to the Windows binary values. I made sure to note that the any Linux changes would be "similar" but not necessarily the same as the example that Max originally put in there. After doing the review, can you update it in your Linux client link? That's what I've been hoping for all along.

I don't have any more time to review the Windows documentation. I'll do that late Tuesday. Max, you don't need that on your plate. In the future, if I need something non-technical done, I'll just do it myself. It's far easier. I've spent 30 mins. in reminders and explanations about what we needed on the README and it only took me 10 mins. to change it. That's a no-brainer.


Gary

kar_bon 2010-03-14 21:56

[QUOTE=gd_barnes;208399]Attached is the updated Linux README. Karsten, can you review the 1st line of the 1st para. and the updated para. about your patches to the Windows binary values.[/QUOTE]

1st line looks better now!

the patches are ok, too.
i've decided not to show the addresses of the patches (will be different with new cLLR-version!), only the texts supressed in an extra note.

mdettweiler 2010-03-15 00:27

[quote=gd_barnes;208399]So I guess the above was not clear enough about port 6000, huh?

Doing the README would have taken 10-15 mins. Are you telling me that the results would have taken less? I think not. The README was asked for 3 different times. How could it keep getting forgotten?

Priorities please!

So I've now lost an hour out of my business trip. I've now loaded up port 6000 and updated the drive, which took way longer than it should have because of the terrible remote access that I now have. That's why I asked you to do it.

Karsten is busier than either of us. Maybe we need to give him remote access to my machines to load up servers. You know, if you need something done, give it to a busy person. It will get done! :smile:

Attached is the updated Linux README. Karsten, can you review the 1st line of the 1st para. and the updated para. about your patches to the Windows binary values. I made sure to note that the any Linux changes would be "similar" but not necessarily the same as the example that Max originally put in there. After doing the review, can you update it in your Linux client link? That's what I've been hoping for all along.

I don't have any more time to review the Windows documentation. I'll do that late Tuesday. Max, you don't need that on your plate. In the future, if I need something non-technical done, I'll just do it myself. It's far easier. I've spent 30 mins. in reminders and explanations about what we needed on the README and it only took me 10 mins. to change it. That's a no-brainer.


Gary[/quote]
Ah, that would explain it...I believe I semi-skimmed that post (very bad habit :smile:) and thought "oh, Monday, that's a ways off". DUH. :rolleyes:

The readme looks good. I'll upload it right now...yes, really, right now. lol :smile: Edit: done


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

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