Dead project?

[mdettweiler]

As Karsten said, the new LLRnet clients aren't limited to base 2. In fact we actually did some testing on base 3 in the alpha-test phase, so we have confirmed it should definitely work with other bases. Most of our testing was on base 2 but, unless you're doing very small tests (n<100 or so) where LLR does some weird things with its lresults.txt output, it should work.

[ltd]

The statement was that the OLD llrnet client which is based on llr3.5x does not work without a patch and its the communication part of the software and not llr itself that had the limitation.

As the new llrnet client works with a perl script and the latest llr3.8 exe there would only a limitation if the perl scripts had one which is not the case.

[kar_bon]

ok, you're right. i've tested the old llrnet version with non-base-2 pairs and it's not working!

the note shown in the source above was shown and the results were saved in the server-joblist-file with status = ERROR!

[mdettweiler]

I just saw this on the PrimeGrid forums here:

As for SR5, we are unaware of any pending collaboration at this time. However, informally, Lennart hosted a PRPNet port for them. In the near future, we'll reserve another range from SR5 and open it for PG users to test. It's a project that would make a good fit here at PrimeGrid. :)

Though it might prove a little hard to reserve a range without masser around...

[gd_barnes]

I guess my point about saying "I hope not" when asking whether this project is still using the "old" LLRnet 3.5 server and client is that it is doing a great disservice to anyone connecting to the server. We're talking 2-3 hour tests vs. likely 30-40 min. tests. It's a tremendous waste of resources.

The server/client that NPLB uses should work for any base with the small modification to one of the .lua server files as indicated by Karsten.

I'm not sure why there is this debate about whether the old LLRnet server works with non-base-2 without a patch. Of course it doesn't. But when using the new scripts that Karsten, Max, and I have developed which run the latest LLR and interface between the server and client, it works for any base. Karsten and I have tested it on bases 2, 3, and 5.

Wouldn't it make sense to try the new client here for a small range?

[gd_barnes]

Originally Posted by mdettweiler

I just saw this on the PrimeGrid forums here:

Though it might prove a little hard to reserve a range without masser around...

Why is that? Is there some sort of automated reservation process that only he can access?

[em99010pepe]

I tried the script using the llrnet for base 5 and still doesn't work. The client downloads the candidates, finishes them, uploads them but then the perl script just stops working. It never reaches the point to ask for more work, the perl dos window just shuts down. And if you start do.pl is doesn't start anymore.

EDIT: I just made a test. Do.pl starts if you delete llr.ini, workfile.res and workfile.txt after the client sends the results.

[kar_bon]

it works fine with the WIN-DOS script V0.7, see here.

i only edited
- username
- server
- port

in llr-clientconfig.txt!

[em99010pepe]

Ok, the DOS version is working.

[gd_barnes]

Originally Posted by em99010pepe

I tried the script using the llrnet for base 5 and still doesn't work. The client downloads the candidates, finishes them, uploads them but then the perl script just stops working. It never reaches the point to ask for more work, the perl dos window just shuts down. And if you start do.pl is doesn't start anymore.

EDIT: I just made a test. Do.pl starts if you delete llr.ini, workfile.res and workfile.txt after the client sends the results.

That is strange. You might try just letting it run since it's now created the llr.ini based on base 5 work. I wonder if it got messed up somehow because it had an unrelated llr.ini file in there.

Karsten tested the Windows DOS script and Max and I tested the do.pl scrpt running Linux. We only did sporadic testing of do.pl in Windows because we assumed that most people would use Karsten's Windows DOS script. I wonder if other bases might turn out to be a problem when running do.pl in Windows.

Edit: Glad to see that the DOS script is working. I think I'll try messing around with the do.pl script in Windows on other bases to see if I can "break" it.

[mdettweiler]

Originally Posted by gd_barnes

Why is that? Is there some sort of automated reservation process that only he can access?

Well, the manual reservation files given out here weren't regular ranges with a definite stop and start. Rather, it seemed that each file had candidates spread out over a given range, and files would keep being handed out from within a given range until there were no more left there, at which point a higher block was started. Since the results would then just go directly into the DB, there was no need to keep them in strict sequential order for tracking purposes.

As such, I'm not sure if there's any kind of definite "lowest available n" from which a new range could be started--at least not without risking potential double-work on candidates already done here and there.

Of course, PrimeGrid has enough resources that they could probably just start from the lowest outstanding n on each k and search right on up. They'd probably breeze through any "mixed" ranges in no time and get right into fully new stuff. The worst that could happen is that a portion of the earlier results would go in as doublechecks (and a few would be thrown out as triplechecks).

Originally Posted by gd_barnes

That is strange. You might try just letting it run since it's now created the llr.ini based on base 5 work. I wonder if it got messed up somehow because it had an unrelated llr.ini file in there.

Karsten tested the Windows DOS script and Max and I tested the do.pl scrpt running Linux. We only did sporadic testing of do.pl in Windows because we assumed that most people would use Karsten's Windows DOS script. I wonder if other bases might turn out to be a problem when running do.pl in Windows.

Edit: Glad to see that the DOS script is working. I think I'll try messing around with the do.pl script in Windows on other bases to see if I can "break" it.

Hmm...I'm not entirely sure what happened there, but I also suspect llr.ini has something to do with it. Carlos, if you had previously stopped the client in the middle of base 2 work and just went right into base 5 stuff without cleaning anything out, I imagine that might cause problems; the recommended practice is to first clean out all work in queue with "./do.pl -c", which submits any finished pairs and cancels all unfinished ones.