Team drive #5: k=400-600 n=600K-1M

[MyDogBuster]

Reserving 617-618

[gd_barnes]

Reserving n=618K-625K for port 400.

[em99010pepe]

Originally Posted by gd_barnes

Reserving n=618K-625K for port 400.

Pay attention to the server...IB forgot to add the latest range.

[IronBits]

*cough*
ahem

Port 400 has 27418 remaining knpairs!
knpairs.txt - Size: 327640
Last Updated: 1/10/2009 2:41:55 PM
first k/n pair 465 614571
last k/n pair 567 625000
jobMaxTime = 3 * 24 * 3600 -- 3 days
prunePeriod = 1 * 1 * 3600 -- hourly

[gd_barnes]

Max,

And further; can you process the results for n=606.2K-615K on this drive?

I was kind and didn't request this one this morning.

We'll be glad we got all this stuff out of the way before the 8th drive restarts; which I'm planning on late Sat.


Thanks a bunch,
Gary

[Mini-Geek]

605.2-.4 and .7-.9 complete.
ETA for finishing off the full range is 1/22.

[mdettweiler]

I was trying to process the results for 606.2K-615K just now and found the following 26 missing results:

549 612947
567 612953
441 612987
493 612987
501 612987
511 612987
553 612987
555 612987
405 612988
419 612988
429 612988
435 612988
453 612988
575 612988
481 612989
417 612990
447 612990
453 612990
587 612990
429 612991
531 612991
595 612991
437 612992
495 612992
409 612993
565 612993

This is despite the fact that the server reports this range as long complete (none of these remain in the knpairs.txt file), and even when I tried re-downloading a bunch of the results files just to make sure that I didn't miss anything, I still was missing these results in the end.

However, I find it hard to believe that 26 k/n pairs would just disappear into thin air unless something absolutely crazy happened to them. David, did results for any of these k/n pairs ever make it into the database? If so, could you please post their respective residuals here so I can incorporate them into my final results file for this range?

If they are not in the database, then they'll need to be re-crunched. In that case, I'll just do them myself manually since 26 k/n pairs is only a wee bit of work.

Max

[AMDave]

Max

I punched that list of k/n into the db and got the following:

MySQL returned an empty result set (i.e. zero rows). (Query took 0.5044 sec)

none of those pairs are in the live results table.

I recommend doing them again.
As you say, not much work in those.
What is the bet that every one of them is prime! lol
and they are high n's too.

[gd_barnes]

I did some analysis on this problem. The last pair shown in the Jan. 8th results file for pairs run on Jan. 7th was:

user=gd_barnes
[2009-01-07 23:44:08]
531*2^612986-1 is not prime. Res64: 7CE1FF3EA994AED5 Time : 2685.0 sec.


The first pair shown in the Jan. 9th results file for pairs run on Jan. 8th was:

user=gd_barnes
[2009-01-08 00:00:26]
445*2^612993-1 is not prime. Res64: F20B96F85A9C7355 Time : 2682.0 sec.


David,

I had several quads on port 400 at the time and I was running 95%+ of the pairs in the server. glennpat had what appeared to be one core on it. If you look in the results files for both days, I was returning a completed pair to the server at about 2 per minute.

Therefore the question is, why are there no results shown in the last 15 mins. 52 secs. of Jan. 7th?

That accounts for all except the first two pairs in Max's Email. I will do an analysis of those in the next post.

One more thing: Based on that, I'll bet my bottom dollar that I have the results on my machines (if I processed them) and somehow they've come up missing. And further, my machines never stopped at that time and if I had stopped them, I always immediately return unprocessed pairs to the server using the "llrnet -c" command and they should have shown up in the next day's results -or- if they weren't returned, they would have shown up 3 days later. I checked all of the results up to 4 days after that and they weren't there.

My take: The server is processing the pairs correctly but is somehow getting messed up when it creates the daily results files. For the ones that I don't have, I bet glennpat has them on his machine(s).

In a prior life, I did both accounting work (in my 20's) and system's analysis (late 30's & 40's until last year). It's fun finding the cause of thorny problems like this.

Edit: Max, you said there were 22 results missing but listed 26 of them. I corrected your count.


Gary

[gd_barnes]

OK, I've determined what I think happened on the 1st two pairs also and it's the same as the 1st problem with a catch: Those were assigned to glennpat approximately 2 hours before the nefarious time at the end of Jan. 7th. I know that because I was returning results to the server for that same n-value approximately 1.5 hours before the end of the day. The difference is due to the small amount of pairs that I cache at all times plus the length of time it takes me to process a pair.

After he was assigned them, he likely returned them to the server fully processed sometime between 23:45 and 0:00; which jives with his typical 7000 sec. processing time.

So that's it...I believe it is 2 symptoms of the same problem.

I'm going down to look at my machines now to see if I have results for them. If I have them, I'll post them in the next post.


Gary

[IronBits]

Something must have fubar'd during the switch over to Linux processing is the only thing I can think of.
It didn't happen before, and it hasn't happened afterwards. Good catch.
I suggest process them again manually and be done with it.