View Single Post
Old 2009-08-04, 03:27   #10
gd_barnes's Avatar
May 2007
Kansas; USA

101000011110102 Posts

Originally Posted by mdettweiler View Post
I've checked and it looks like all four of those k's were omitted from the file for n<500K. (Since the range we're doing right now in the server is 300K-350K, the k's don't have any incidence at all in the server.)

Per this thread, this is correct for the 3rd Drive. Nonetheless, yes, those k's should be doublechecked. However, we do have one problem: since we didn't originally test them the first time around, we don't have first-pass residuals for those k's. But, we really need to have two sets of residuals for each k/n pair in order to make a proper doublecheck. So here's what I'm proposing: we quickly re-do those k's to get "first-pass" residuals, then we add them to G2000 to be included in the doublecheck. We'll then end up with two residuals for each k/n pair, as needed.

Okay, sounds good. I'll get the sieve file prepped and loaded as soon as possible, hopefully today.

Ah, good. That's nice to hear that there's no interface problem. We're good to go on G5000.

Actually yes, we do have first pass residuals. You might remember that as the k=300-1001 range was nearing n=600K, I followed up the tail end by double checking other's efforts, finding one missing prime in the process, something that I'll also do as the 11th drive nears n=650K. I did it manually but still have the results saved off and available.

So, when you get a chance, can you load k=343, 359, 361, and 375 for n=300K-350K into port G2000? Assuming that this particular server naturally hands them out by size instead of entry order or k-value, then they should be handed out first up until we get to the current n=~330K depth. That would be a good thing.

That's nice to know that those interfacing web pages alert us to such things like that before they become bigger issues. Cool! :-)


Last fiddled with by gd_barnes on 2009-08-04 at 03:28
gd_barnes is online now   Reply With Quote