[quote=mdettweiler;157911]Um...no. I probably could have made this more clear earlier, but ever since PRPnet v1.0.4, the server hands out candidates by increasing order of decimal size, not by order of k. Thus, it is currently searching the main drive plus the two higher of the small k's upwards together in the ~127K vicinity. (k=10107 was already done up to ~144K or something in that vicinity before we upgraded the server to the PRPnet server version that sorts by decimal size instead of by k, so now it's on hold until the rest of the work in the server reaches that point).

Max :smile:[/quote]


Actually, you made it very clear that when the server was upgraded, it would hand them out in decimal-size order. What I may have missed is that the server was actually upgraded. I had assumed you would leave it "non-"upgraded until the 3 k's were done. Alas, it doesn't matter, they will all get tested.

More than anything, I want to get the search-limits reflected correctly on the web pages. I'll subtract n=1K from your estimates here and show those as the current tested limit on all of the k's in case there are straggling pairs below your estimates.

Thanks for the explanation.


Gary

Max,

I have updated the 1st post in this thread to incorporate the fact that everything is now being done on a PRPnet server for this drive. Could you provide a link to instructions for setting up the PRPnet server somewhere in the 1st post?

After my sieving is done at NPLB, I may put a core or 2 on the server. I'll be curious to watch the PRPnet server in action from a client perspective.


Thanks,
Gary

[quote=gd_barnes;158647]Max,

I have updated the 1st post in this thread to incorporate the fact that everything is now being done on a PRPnet server for this drive. Could you provide a link to instructions for setting up the PRPnet server somewhere in the 1st post?

After my sieving is done at NPLB, I may put a core or 2 on the server. I'll be curious to watch the PRPnet server in action from a client perspective.


Thanks,
Gary[/quote]
Okay--actually, sometime within the next couple of days I'll start a new thread with full instructions on how to set up and use the PRPnet client, to replace the existing LLRnet instructions thread. :smile:

Hi all,

PRPnet G3000 has pretty much completed (except for a few possible stragglers that I'll check for later tonight) the main drive work up to n=130K. It's now doing work for k=10107, k=13215, and k=14505 from 130K-150K, currently at about 144K for all three of those k's.

Since that won't last too long for only three k's, I will be loading 130K-150K for the main drive shortly. The server will then immediately begin handing out work for the main drive starting at 130K and continuing until at reaches ~144K, where it will then resume handing out work for the three formerly-separate k's in conjunction with the main drive.

Max :smile:

157473*6^131124+1 is prime! (1175.1532s+0.0047s)

30 Left

Side Note: The flagging of found PRP's works in PRPNet because I got this message after I found the above PRP

[2009-01-16 14:47:13 GMT] a: INFO: Could not find WorkUnit [157473*6^131136+1] on server. Result rejected.

That pair was in the same cache of 10 where I found the PRP. So tests will be saved as long are they are not in the same cache.

[QUOTE=MyDogBuster;158996]157473*6^131124+1 is prime! (1175.1532s+0.0047s)

30 Left

Side Note: The flagging of found PRP's works in PRPNet because I got this message after I found the above PRP

[2009-01-16 14:47:13 GMT] a: INFO: Could not find WorkUnit [157473*6^131136+1] on server. Result rejected.

That pair was in the same cache of 10 where I found the PRP. So tests will be saved as long are they are not in the same cache.[/QUOTE]

If a prime or PRP is found and the server is configured for Sierpinski/Riesel, the server will mark all other candidates for that k/b/c then clear them from memory (after writing the marked values to disk) immediately. That is why the next one for the same k/b/n was rejected. This behavior could be modified, but I'll have to think of a good way to handle it.

Max,

Sorry to keep bugging you for results but could you process results to me for n=100K-130K on this drive? I don't seem to have anything n>100K in my files yet.

Since they are likely spread across 2 servers now, it's probably better to do it now before it get's difficult to find all of them.

Nice prime Ian! BARELY short of top-5000!


Thanks,
Gary

[quote=gd_barnes;159101]Max,

Sorry to keep bugging you for results but could you process results to me for n=100K-130K on this drive? I don't seem to have anything n>100K in my files yet.

Since they are likely spread across 2 servers now, it's probably better to do it now before it get's difficult to find all of them.[/quote]
Actually, no need to worry, all the results are right where I can find them. :smile: In fact, the reason why I didn't get the results done yet is, surprisingly enough :smile:, not due to my negligence, but instead entirely due to the fact that as of a couple of days ago (the last time I checked) there were still a handful of stragglers in the 100K-130K range. :smile:

Anyway, I'll check again later today to see how many stragglers, if any, are left. (It's a little harder to check for stragglers in PRPnet than in LLRnet due to the different file formats, but I'll eventually get together some scripts that should present the data as easily as they do already for LLRnet. :smile:)

The drive is complete to n=150K. Double checking is ongoing for the n=100K-150K range due to problems with the PRPnet server.

New manual files have been posted for n=150K-170K with PFGW headers. It is recommended that people use the newest version of PFGW for testing. It is much faster than anything else.

Base 6 is a very exciting base because there are relatively few k's remaining but enough to make it interesting and there is a fairly high density of primes.


Gary

Taking 150k-152k

Lennart

150k-152k Complete


Taking 152k-154k



Lennart