Testing....

[gd_barnes]

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]

Originally Posted by gd_barnes

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.


Gary

Oh, okay, I get it now. In that case, then, I'll make the changes to the one I've got.

[mdettweiler]

Originally Posted by kar_bon

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!)

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]

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]

Originally Posted by gd_barnes

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.)

Yes.

(2) Do both clients have the date format changes that Karsten requested?

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.

(3) Are they completely synced up? That includes all script and .lua files.

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]

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 )

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]

Originally Posted by kar_bon

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?

I was writing my readme.txt just for do.pl; I figured you'd write one for do.bat.

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?

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.

next question:

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

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?

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 )

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. )

[kar_bon]

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]

Originally Posted by kar_bon

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.

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]

Originally Posted by kar_bon

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 )
Karsten

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]

Originally Posted by kar_bon

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

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