PRPnet 1st drive-R/S base 2 even-k/even-n/odd-n

[MyDogBuster]

I've added a core to the cause. I would suggest a sort option of A so that bases will complete by oldest loaded first.
I may add more cores when other tests end. Hope you don't mind the company Mathew.

Any suggestions on what to add after R31? I have resources for a sieve.

[mdettweiler]

R31 is now loaded, and the server is on sortoption=A. (It was on N before. I'm not sure why it wasn't on A to begin with; since A sorts by decimal length within a file, it's effectively the same as N most of the time, so I usually always use A except where otherwise necessary.)

[Mathew]

Max,

I am confused now. It looks like the server is only doling out the largest k. There is an n difference of over 1600 between the largest k and the next one. The other 2 k's should be smaller in decimal length.

MyDogBuster,

I could always use more company.

[mdettweiler]

Originally Posted by Mathew Steine

Max,

I am confused now. It looks like the server is only doling out the largest k. There is an n difference of over 1600 between the largest k and the next one. The other 2 k's should be smaller in decimal length.

Hmm, very strange...looking at the database and sorting by LastUpdateTime, then DecimalLength (that is, the same criteria the server uses on sortoption=A) I see that the pairs are listed in alphabetical order--that is, sorted by k but with k=155 coming before k=32. And LastUpdateTime (a Unix time value) seems to increment by 1 for each k in that order.

I'm not entirely sure what happened here, but can only suppose it has to do with how I re-loaded the pairs after that big server crash a few weeks back where most of our PRPnet servers got wiped. To do that I processed the incomplete pairs from the server's results files, sorted them by n, ran a diff comparing the result with the original sieve file, and loaded the missing pairs back into the server. What I'm seeing now would almost seem to indicate that I'd sorted them by k, which doesn't seem right.

Anyway, whatever happend, I must have had a good reason for it at the time. That must have been why the server was set to sortoption=N, so that the pairs would be handed out in the right order despite how I loaded them. So I'm sure it wasn't a PRPnet bug but rather something I did when I was re-loading the pairs.

Now that R31 is loaded into the server, there's not much I can do about it (since changing it back to sortoption=N would make it hand out R31 pairs); no big deal, we're close enough to the end of the range anyway that the effect will hardly be noticeable. (It will all get done at the same time it originally would have, just in slightly different order.)

[gd_barnes]

Max,

Can you 100% for sure say that the pairs will be handed out in n-value order within each k-value? If so, I suppose that is OK for the few remaining pairs of S22. BUT...It is not OK for the much larger n-range and twice as many k's on R31.

Can you 100% guarantee us that R31 will be handed out entierly in n-value order after finishing S22? We don't want to test one k at a time on R31.

Is there a way you can post a file of the order in which everything should be handed out? If it's too much trouble, don't worry about it.


Gary

[mdettweiler]

Originally Posted by gd_barnes

Max,

Can you 100% for sure say that the pairs will be handed out in n-value order within each k-value? If so, I suppose that is OK for the few remaining pairs of S22. BUT...It is not OK for the much larger n-range and twice as many k's on R31.

Can you 100% guarantee us that R31 will be handed out entierly in n-value order after finishing S22? We don't want to test one k at a time on R31.


Gary

Yes, the few pairs remaining on S26 will be handed out in alphabetical k order primary, then n secondary. R31 will then be handed out in standard n-value order (or more precisely, decimal length; but that essentially works out to n-value order anyway).

[gd_barnes]

OK, sounds good.

[gd_barnes]

Originally Posted by mdettweiler

R31 is now loaded, and the server is on sortoption=A. (It was on N before. I'm not sure why it wasn't on A to begin with; since A sorts by decimal length within a file, it's effectively the same as N most of the time, so I usually always use A except where otherwise necessary.)

N is slightly better than A. Otherwise:

2*3^n+1

would be handed out before:

8*3^(n-1)+1

because the latter is larger even though the former n-value is larger.

IMHO, it is "slightly" better to have everything in n-value order -or- everything in k-value order...not size order, which is difficult to visualize when looking, especially on large conjectured bases.

It would get even more ridiculous where one k-value is teeny (like k=2) and the other is huge (like k=50G) on Riesel base 3. The teeny k could have an n-value that is > 10 more than the huge k n-value yet the form would still be smaller and so the former k with the much larger n-value would get handed out first.

Sort option A should probably only be used when more than one base is being tested and you happen to want to test them all upwards at about the same length. (Personally I'd still prefer N as long as the range of bases was not too large.) Even when testing both the Riesel and Sierp side of the same base, sort option N is still slightly better IMHO.


Gary

[gd_barnes]

Thinking way ahead here: After we're done with R31, we might consider loading our team drives for R16 and S16 in here; both at the same time and hand them out in n-value order so that one catches up with the other and then they run in concert with each other.

I think they could probably be sieved further. When I sieved them, I wasn't using my speedier sieving I7.

It would be nice to get those moving up towards n=1M base 2 (n=250K base 16).

...Just food for thought right now. No decision needed at this point. The 2 bases are good candidates for a server due to the fair # of k's remaining and the fairly high current search depth. Heck, we could even have a CRUS PRPnet rally on them sometime in the future.

[MyDogBuster]

If we're looking for stuff to do, I'd like to get all the bases < 250 up to at least n=100K, excluding the high ck ones with loads of k's left. Put the cutoff point at something like 20k's remaining. Sieve them, load them and let 'er rip.

JMHO

I'd probably run the base 16 stuff, but it's not my first choice, more like a "If that's all there is "

Any preference Mathew?

[mdettweiler]

Originally Posted by gd_barnes

N is slightly better than A. Otherwise:

2*3^n+1

would be handed out before:

8*3^(n-1)+1

because the latter is larger even though the former n-value is larger.

IMHO, it is "slightly" better to have everything in n-value order -or- everything in k-value order...not size order, which is difficult to visualize when looking, especially on large conjectured bases.

It would get even more ridiculous where one k-value is teeny (like k=2) and the other is huge (like k=50G) on Riesel base 3. The teeny k could have an n-value that is > 10 more than the huge k n-value yet the form would still be smaller and so the former k with the much larger n-value would get handed out first.

Sort option A should probably only be used when more than one base is being tested and you happen to want to test them all upwards at about the same length. (Personally I'd still prefer N as long as the range of bases was not too large.) Even when testing both the Riesel and Sierp side of the same base, sort option N is still slightly better IMHO.


Gary

Indeed--hence why I mentioned that decimal length is "effectively the same" as n-value, not exactly the same. Still, for most purposes it's close enough that it's no big deal. I usually prefer to use sortoption=A instead of N because it allows me more direct control over what order things are handed out in; it's roughly similar to LLRnet's method of handing out pairs as they're encountered in the knpairs file.

For servers that will usually stay on the same kind of work proceeding upward by n (such as NPLB's port 9000), there's not much point in using A. If, as suggesed in your next post, we move port 1300 to the bases 16 after it finishes R31, then sortoption=N would be a good fit for it.

Regarding doing the bases 16 next in port 1300: sounds good to me. We could use some help on those drives. Though Ian's idea of getting the "non-hard" bases <250 up to 100K first is also a possibility.