[quote=mdettweiler;206758]Hey, I didn't know that--I thought the password was still 6g:Qieoj. Where'd you get the new one?[/quote]
AFAIK it was the first password we ever used or at least used at onepoint.
It was the only one i remembered so i tried it and suceeded.
IMHO too much sorting stuff out(like upgrading llrnet here) is done in private by pm at NPLB and sometimes CRUS. Often it is an interesting read. Also sometimes extra opinions help.
Please do a rally at somepoint it was great fun us all piling our machines onto one server or at least one drive if one server can't cope. I miss it. Would Free-Dc consider joining us for a weekend rally?
Another idea to throw up is would NPLB be willing to run a rally on a CRUS server(maybe base 6?) or would CRUS do it's own rally?

[QUOTE=henryzz;206759]IMHO too much sorting stuff out(like upgrading llrnet here) is done in private by pm at NPLB and sometimes CRUS. Often it is an interesting read. Also sometimes extra opinions help.[/QUOTE]

this was done because we see what happens, when a program is not tested deeply (like prpnet):
it's in use but with many issues to live with before they are resolved.

after all is done and many tests run fine, then it's time to make it official and other users can suggest their opinions/needs to make it even better!

David,

We are alpha testing right now. Not beta testing. This is the way public software should be tested. That is alpha testing by a few very isolated and knowledgable users. Continuing to issue releases before proper alpha testing is done across all platforms is both time consuming and frustrating.

Within the next week after our final small bug is fixed, we will open it up to public beta testing.

Can you see the difference?

We were aware that some people would be able to access this thread but we've chosen to keep it semi-private so we are not attempting to coordinate 10s of users during alpha testing when there are numerous small bugs still present. It takes too long and is frustrating. We have just one remaining final small bug. After that, we'll open it up.

LLRnet will now be a tremendous piece of work and will give NPLB and other DC projects who search base 2 a tremendous lift.

We've spent nearly a year trying to get PRPnet up to par. It wasn't going to happen. It's just one thing after another and now I read that it has numerous memory leaks. We've been testing the new LLRnet for 2 weeks and I can guarantee you that it will handle an immense load with no problems. I have put 31 cores on n=~10K tests, which is the equivalent of 10,000+ cores running n>400K. It passed with flying colors.

The current plan is to do a rally not long after this is released and after the noprimeleftbehind pages are back up, the latter of which I estimate will be a week or so.


Thank you,
Gary

After much testing, it appears that the final bug related to pairs not being returned to the server when the server dries has been resolved. I think we have a keeper.

I'll be doing a little more testing on the Windows client tonight and doing verification that the Linux and Windows clients are properly synced up. Then it will be time for the big roll out.

Exciting times lie ahead! :smile:

I've made changes to the do.pl script and README.txt document for the Linux client as follows:

1. Change do.pl to allow for several different scenarios related to very small tests.

2. Change do.pl program comments and README.txt documentation from 1st to 3rd person and remove many "filler" words. I also updated the version to 0.7.

Attached are the updated versions.


Gary

large problem
 

Karsten,

I'm now running tests for Riesel and Proth bases 2 and 3 for a large k for n<=10K without sieving. This should cover all possible scenarios of k/n pairs that could happen.

There has been a problem that has existed, I believe, for the entire time that we've been testing but I had not realized it. The problem is caused by the fact that whenever there is a rejected pair, it writes out the statement: "The server refused your new result: (etc.)" in the lresults.txt file. It writes out a total of 4 lines.

Here is what happens: Whenever the script then goes to convert the lresults.txt to tosend.txt, these "rejected comment lines" in lresults cause a major problem. They cause MORE pairs to be rejected. Even if the code is otherwise good, this would be very bad in public use. If someone had a pair that was rejected because he waited too long to return it, it would cause subsequent good pairs to be rejected.

I didn't notice this problem before because whenever it wrote something to the lresults.txt saying that it had rejecting something, it was because of incorrect coding on special situations for pairs just prior to the rejected comments but now I realize that it is also rejecting pairs after that where the coding is good for them.

But here is the interesting part: The server is not actually rejecting the good or badly coded pairs, per se. It is just not accepting them but saying nothing about it. It's like the same issue where the pairs were being dropped at the very end of a dried server but the server never said they were rejected. They just end up going out into cyperspace somewhere.

To demonstrate this to yourself, test n=1 thru n=1000 for your k=100542585 without sieving but do the following:
1. Make sure you still have some "bad code" in place that doesn't account for all of the strange situations that come up for the teensy tests.
2. In the code, before the tosend.txt file is sent to the server (which automatically deletes it), add it (concatenate) to a tosend_hist.txt file like you would do for the lresults.txt to lresults_hist.txt file.
3. Set the cache to at least 25 because otherwise the communication time takes too long.

You should see in your tosend_hist.txt that it is trying to send residues that contain some of the verbiage of the rejected comments in lresults.txt.

This is very bad. There is already now quite a bit of code for special situations when converting lresults.txt to tosent.txt. This will require several more lines of special code. But it doesn't seem right. It's as if the program has to code around a problem that itself is creating.

I believe this is something that none of us ever thought of. We just assumed that the results would always be just that: results. But now we are coming to realize that the lresults.txt file can contain a ton of different things: Regular residues, OLD residues, primes, PRP lines, factor lines that show the factor but not the "no prime" verbiage, factor lines that do not show the factor and DO show the "no prime" verbiage, lines that show "we can only do a PRP test" (because the k is bigger than 2^n), lines that contain "is base 3-strong PRP", lines that contain "Frobenius PRP!", etc. (That's all that I can think of right now.)

I'm beginninng to wonder if we should just make LLRnet only applicable to tests where n>1000. That would also resolve the problem of k>2^n.

What's somewhat maddening about this is that I now have code in place (not yet posted here) that takes into account all of the above scenarios (except the rejected comments) because I encountered all of them in my testing of your k-value for n<10K and I believe you encountered most of it also. After getting all of the correct code in place, visually, I now have a clean test. But the problem where a pair would be rejected still exists. I just did not happen to encounter it when I accounted for all of the above situations.

The problem that I am having is that after taking into account all of the scenarios above, now having to code around the "rejected" comment lines in the lresults.txt; that's getting a little ridiculous. It's too much complication and forces the server to test a lot of things that will happen in the "real world" < 0.1% of the time.

My question is: Is there a way to make it NOT write the rejected message to the results. If that is possible, is that something that we really want to do? If it is not possible, can you think of an easy way to code around those lines without having to check for 3-4 more different sets of verbiage?


Gary

i did the test with cllr-input like this:
[code]
43228319159:M:1:2:258
100542585 1
100542585 2
100542585 3
100542585 4
100542585 5
100542585 6
100542585 7
100542585 8
100542585 9
100542585 10
[/code]

up to n=1000.

i ran cllr on that as input and got this as 'lresults.txt':
[code]
100542585*2^1-1 = 201085169 is not prime. (trial divisions)
100542585*2^2-1 = 402170339 is prime! (trial divisions)
100542585*2^3-1 = 804340679 is not prime. (trial divisions)
100542585*2^4-1 = 1608681359 is not prime. (trial divisions)
100542585*2^5-1 = 3217362719 is not prime. (trial divisions)
100542585 > 2^6, so we can only do a PRP test for 100542585*2^6-1.
100542585*2^6-1 is not prime. RES64: 00000000654D5CE7. OLD64: 000000012FE816B2 Time : 14.823 ms.
100542585 > 2^7, so we can only do a PRP test for 100542585*2^7-1.
100542585*2^7-1 is base 3-Strong Fermat PRP! Time : 15.818 ms.
100542585*2^7-1 is Frobenius PRP! (P = 5, Q = 2, D = 17) Time : 17.631 ms.
100542585 > 2^8, so we can only do a PRP test for 100542585*2^8-1.
100542585*2^8-1 is base 3-Strong Fermat PRP! Time : 4.035 ms.
100542585*2^8-1 is Frobenius PRP! (P = 5, Q = 2, D = 17) Time : 34.765 ms.
100542585 > 2^9, so we can only do a PRP test for 100542585*2^9-1.
100542585*2^9-1 is not prime. RES64: 0000000082AE6185. OLD64: 00000001880B248C Time : 13.268 ms.
100542585 > 2^10, so we can only do a PRP test for 100542585*2^10-1.
100542585*2^10-1 is not prime. RES64: 0000000DAC3640D5. OLD64: 000000110C00DE7D Time : 18.761 ms.
[/code]

then i used this lresults.txt as input in my conversion script 'do_tosend.awk' and got this as 'tosend.txt':
[code]
5000000000000:M:1:2:258 100542585 1 -2 trial_factored
5000000000000:M:1:2:258 100542585 2 0 0
5000000000000:M:1:2:258 100542585 3 -2 trial_factored
5000000000000:M:1:2:258 100542585 4 -2 trial_factored
5000000000000:M:1:2:258 100542585 5 -2 trial_factored
5000000000000:M:1:2:258 100542585 6 -2 00000000654D5CE7
5000000000000:M:1:2:258 100542585 7 0 Frobenius_PRP
5000000000000:M:1:2:258 100542585 8 0 Frobenius_PRP
5000000000000:M:1:2:258 100542585 9 -2 0000000082AE6185
5000000000000:M:1:2:258 100542585 10 -2 0000000DAC3640D5
[/code]

i've also tested it with my local server/client-installation and the server 'lresults.txt' is:
[code]
user=kar_bon
[03/01/10 12:50:59]
100542585*2^1-1 is not prime. Res64: trial_factored Time : 2.0 sec.
user=kar_bon
[03/01/10 12:50:59]
100542585*2^2-1 is prime! Time : 2.0 sec.
user=kar_bon
[03/01/10 12:50:59]
100542585*2^3-1 is not prime. Res64: trial_factored Time : 2.0 sec.
user=kar_bon
[03/01/10 12:50:59]
100542585*2^4-1 is not prime. Res64: trial_factored Time : 2.0 sec.
user=kar_bon
[03/01/10 12:50:59]
100542585*2^5-1 is not prime. Res64: trial_factored Time : 2.0 sec.
user=kar_bon
[03/01/10 12:51:00]
100542585*2^6-1 is not prime. Res64: 00000000654D5CE7 Time : 1.0 sec.
user=kar_bon
[03/01/10 12:51:00]
100542585*2^7-1 is prime! Time : 1.0 sec.
user=kar_bon
[03/01/10 12:51:00]
100542585*2^8-1 is prime! Time : 1.0 sec.
user=kar_bon
[03/01/10 12:51:00]
100542585*2^9-1 is not prime. Res64: 0000000082AE6185 Time : 1.0 sec.
user=kar_bon
[03/01/10 12:51:00]
100542585*2^10-1 is not prime. Res64: 0000000DAC3640D5 Time : 1.0 sec.

(...)
user=kar_bon
[03/01/10 12:52:26]
100542585*2^340-1 is not prime. Res64: small_factor Time : 1.0 sec.
[/code]

although the results 'Res64' for trial factored/small factor (small or not sieved n-values) look a bit strange (llrserver only differs prime (Res64=0) or not prime (Res64 set to given value)), all 1000 n-values are there and none in the rejected.txt!

the 'primes.txt' contains all 44 primes in that range.

so, please check my conversion awk-script i PM'ed yesterday in the V07-zip!

Karsten

PS: as you can see i forgot to change back the date-format on my local server!

@Gary regarding the rejected pairs issue: how about something like this?
[code] if($JustRead =~ "\*") {
if($JustRead =~ "not prime") {
if($JustRead =~ "LLR Res64") {
($foo, $res64time) = split(/Res64: /, $JustRead);
($res64, $time) = split(/ Time /, $res64time);
}
else {
($foo, $res64time) = split(/RES64: /, $JustRead);
($res64, $time) = split(/. OLD64/, $res64time);
}
print TOSEND "$header $k $n -2 $res64\n";
}
elsif($JustRead =~ "prime!" or $JustRead =~ "probable") {
print TOSEND "$header $k $n 0 0\n";
}
elsif($JustRead =~ "is base") {
# Skip PRP line by doing nothing.
# Next line will prove primality of same pair.
}
elsif($JustRead =~ "factor") {
print TOSEND "$header $k $n -2 factored\n";
}
else {
print TOSEND "$header $k $n -2 error\n";
}
}[/code]
Essentially what I did was wrap the whole thing in an if() statement that checks whether the line contains a * character. I don't believe there's anything that would be put in lresults.txt containing that that isn't an actual number (that is, it's matching on the * in k*b^n+-c). That should screen out the "rejected comment lines" as well as any other unexpected such lines.

[quote=mdettweiler;207017]@Gary regarding the rejected pairs issue: how about something like this?
[code] if($JustRead =~ "\*") {
if($JustRead =~ "not prime") {
if($JustRead =~ "LLR Res64") {
($foo, $res64time) = split(/Res64: /, $JustRead);
($res64, $time) = split(/ Time /, $res64time);
}
else {
($foo, $res64time) = split(/RES64: /, $JustRead);
($res64, $time) = split(/. OLD64/, $res64time);
}
print TOSEND "$header $k $n -2 $res64\n";
}
elsif($JustRead =~ "prime!" or $JustRead =~ "probable") {
print TOSEND "$header $k $n 0 0\n";
}
elsif($JustRead =~ "is base") {
# Skip PRP line by doing nothing.
# Next line will prove primality of same pair.
}
elsif($JustRead =~ "factor") {
print TOSEND "$header $k $n -2 factored\n";
}
else {
print TOSEND "$header $k $n -2 error\n";
}
}[/code]Essentially what I did was wrap the whole thing in an if() statement that checks whether the line contains a * character. I don't believe there's anything that would be put in lresults.txt containing that that isn't an actual number (that is, it's matching on the * in k*b^n+-c). That should screen out the "rejected comment lines" as well as any other unexpected such lines.[/quote]

I went off the deep end a little. I was pretty concerned about finding such a deal breaker this late in the game and continuing to add complication to the results condition checking.

Max, my objective is to always execute the most commonly occurring condition first within the large if statement to optimize program speed. Therefore, I came up with a better way. Just remove the "error" check at the very end, which effectively causes it to write nothing. If it doesn't hit one of the prior conditions, it simply does not create a TOSEND record. I'd hate to check for the "*" condition (actually I was initially thinking "^" after I got up today but either way would work), because it is well < 0.1% of all lines would be rejected lines in the results.

In the new code that I will post later tonight, I end up checking for "64: " instead (vs. LLRes64) so that both Riesel and Proth results are taken into account. That will occur 99.9%+ of the time. If that is true, then I check for "OLD64" to determine how to pull the residue out of the line. If it is false, then I check for other various conditions that have come out as a result of doing teeny Riesel and Proth tests on large k's.

In doing this, I realized I had a bug in my $numresults++ code. That is the counter for the number of results if the user decides to cancel pairs. I had it above all of the if statements. But because there are some situations where a record will not be written to the TOSEND file, it must be within the if's, right at the time that a record is written to TOSEND.

Karsten, I've now done extensive changes to that section and we'll definitely want to sync up yours with mine. Later tonight, I'll post mine. Our code doesn't have to look the same. It just has to be logically the same. Shortly after posting mine, I'll code review yours.

My testing of Risel and Sierp bases 2 and 3 for all n=1 to 10K with no sieving on a large k that is much larger than b^n has helped resolve all possible final scenario issues. Thanks Karsten, for putting us on the right path with that.

It is now my hope that LLRnet will be the fastest that it can be and will work for any sized Riesel or Proth tests for any base.

Perhaps in the future, it could test k*b^n-c and k*b^n+c where c is > 1. I think sr(x)sieve would have difficulty sieving those where k>1 and c>1 so we'll do that some other year. :-)


Gary

Reference the date issue that we have been talking about in PMs.

As previously discussed, Karsten had to make some changes to the Windows server so that the date shows up correctly in Windows results files (either on the server or client; can't remember which). We do know that the date on all Linux servers and clients has been showing up correctly for a long time. Since NPLB has always used Linux servers, this has not been an issue.

Karsten made the point that the two formatting methods should probably be synced up; I believe because a person with a Windows client running a Linux server could get incorrect date formats on his client. Or perhaps in case a Windows user ends up getting ahold of the Linux script and using part of its files for setting up Windows servers and clients on his machines. I'm not extremely clear on that.

I'm sorry if I'm missing the reason here because it's so difficult to follow everything in PMs.

I will re-review the PMs and make the change to the Linux server to be like the Windows server. Presumably this will have no effect on the Linux date formats in the results of either a Linux server of client. Of course I will test it to be sure. Hopefully this will fix any existing issue if a Windows client runs a Linux server; assuming that has been the problem. If I have time, I will also run a Windows test against the Linux server.


Gary

[quote=gd_barnes;207036]Reference the date issue that we have been talking about in PMs.

As previously discussed, Karsten had to make some changes to the Windows server so that the date shows up correctly in Windows results files (either on the server or client; can't remember which). We do know that the date on all Linux servers and clients has been showing up correctly for a long time. Since NPLB has always used Linux servers, this has not been an issue.

Karsten made the point that the two formatting methods should probably be synced up; I believe because a person with a Windows client running a Linux server could get incorrect date formats on his client. Or perhaps in case a Windows user ends up getting ahold of the Linux script and using part of its files for setting up Windows servers and clients on his machines. I'm not extremely clear on that.

I'm sorry if I'm missing the reason here because it's so difficult to follow everything in PMs.

I will re-review the PMs and make the change to the Linux server to be like the Windows server. Presumably this will have no effect on the Linux date formats in the results of either a Linux server of client. Of course I will test it to be sure. Hopefully this will fix any existing issue if a Windows client runs a Linux server; assuming that has been the problem. If I have time, I will also run a Windows test against the Linux server.


Gary[/quote]
NO! Don't do that. :smile: If anything, we should change the Windows server to be like the Linux one. The database is already set up to parse and import stuff in the Linux format.

BTW, clients and servers are completely separate as far as date formats go. They don't have to be synced up; the only thing that really needs to be consistent is on the server end, so that when we import it into the DB it works right. On the client end, it's entirely for human reading since there'd be no reason to have that imported into the DB.