Team drive #6 k=600-800 n=600K-1M

[gd_barnes]

Reserving n=606K-610K for port 5000.

[mdettweiler]

Reserving 610K-620K for LLRnet IB5000. At its current processing rate, the server will dry in ~2 days or less, and it's moving somewhat more quickly than IB400, so hence I'm reserving a larger chunk for it. (If IB5000's current rate is kept up, it will complete the 610K-620K range in about 5 days, that is, 5 days after the ~2 days to complete 606K-610K.)

Edit: Gary, it seems that we will be having at least 1 already known prime in this 610K-620K range. Can you update the first post of this thread to reflect all such primes? Thanks.

[gd_barnes]

Originally Posted by mdettweiler

Reserving 610K-620K for LLRnet IB5000. At its current processing rate, the server will dry in ~2 days or less, and it's moving somewhat more quickly than IB400, so hence I'm reserving a larger chunk for it. (If IB5000's current rate is kept up, it will complete the 610K-620K range in about 5 days, that is, 5 days after the ~2 days to complete 606K-610K.)

Edit: Gary, it seems that we will be having at least 1 already known prime in this 610K-620K range. Can you update the first post of this thread to reflect all such primes? Thanks.

??

Max, I appreciate your enthusiasm but can you check with me first next time? This is way more than we need. First, there appears to be a very large error in your calculations. Second, to keep the drives relatively even, when this drives gets close to the 5th drive, I will likely split my cores between ports 400 and 5000 since Ian likes to be on port 4000. Third, I may pull off another quad to finish the k=1005-2000 sieving by Jan. 15th.

Calculations as of 1 AM EST on Dec. 29th assuming current processing rate:

Current remaining in port 5000: ~14,400 pairs
610K-620K: ~37,000 pairs
Total thru 620K: ~51,400 pairs

Current processing rate: ~3,700 pairs / day

Dry current pairs: 14,400/3,700 = ~4 days
Dry thru 620K: 51,400/3,700 = ~14 days


It's not a big deal. We'll dry it eventually. It's just nice to give out manual reservations a little closer to where the servers are testing.


Thanks,
Gary

[mdettweiler]

Originally Posted by gd_barnes

??

Max, I appreciate your enthusiasm but can you check with me first next time? This is way more than we need. First, there appears to be a very large error in your calculations. Second, to keep the drives relatively even, when this drives gets close to the 5th drive, I will likely split my cores between ports 400 and 5000 since Ian likes to be on port 4000. Third, I may pull off another quad to finish the k=1005-2000 sieving by Jan. 15th.

Calculations as of 1 AM EST on Dec. 29th assuming current processing rate:

Current remaining in port 5000: ~14,400 pairs
610K-620K: ~37,000 pairs
Total thru 620K: ~51,400 pairs

Current processing rate: ~3,700 pairs / day

Dry current pairs: 14,400/3,700 = ~4 days
Dry thru 620K: 51,400/3,700 = ~14 days


It's not a big deal. We'll dry it eventually. It's just nice to give out manual reservations a little closer to where the servers are testing.


Thanks,
Gary

Whoops. I was *so* sure of my calculations--I had gotten the 2 days and 5 days figures by looking at the results file for today, and seeing that the server had processed about n=2K from the time the results were copied off yesterday, to the time when I looked at the file (not long before the results were to be copied off for today). Thus, I assumed IB5000 was progressing at a rate of ~2K per day, and thus, with the leading edge being at ~606K, it would be about 2 days before it would reach 610K.

And, of course, assuming that the rate of n=2K per day remained roughly constant, then n=10K would take about 5 days to complete. Of course, you're right, I shouldn't have been quite so impulsive with sending such a big file for the server, and should have first considered the distinct possibility that the processing rate would drop somewhat since, as you said, you'll probably be shifting some of your IB5000 cores to other work once the server reaches 610K.

Oh well--as you said, it will dry eventually.

Max

[gd_barnes]

Originally Posted by mdettweiler

Whoops. I was *so* sure of my calculations--I had gotten the 2 days and 5 days figures by looking at the results file for today, and seeing that the server had processed about n=2K from the time the results were copied off yesterday, to the time when I looked at the file (not long before the results were to be copied off for today). Thus, I assumed IB5000 was progressing at a rate of ~2K per day, and thus, with the leading edge being at ~606K, it would be about 2 days before it would reach 610K.

And, of course, assuming that the rate of n=2K per day remained roughly constant, then n=10K would take about 5 days to complete. Of course, you're right, I shouldn't have been quite so impulsive with sending such a big file for the server, and should have first considered the distinct possibility that the processing rate would drop somewhat since, as you said, you'll probably be shifting some of your IB5000 cores to other work once the server reaches 610K.

Oh well--as you said, it will dry eventually.

Max

No biggie. Shall I post more files?

[IronBits]

range added to knpairs
You can always keep an eye on how much is being processed by hour and by day right here
http://nplb.ironbits.net/progress_5000.html
and here
http://nplb.ironbits.net/progress_400.html

[mdettweiler]

Originally Posted by IronBits

range added to knpairs
You can always keep an eye on how much is being processed by hour and by day right here
http://nplb.ironbits.net/progress_5000.html
and here
http://nplb.ironbits.net/progress_400.html

Hmm...interestingly enough, based on the processing rate shown on the IB5000 progress page, my estimate of the server drying the two ranges in a total of 7 days is pretty accurate. Of course, as Gary said, I failed to account for the distinct possibility of him shifting his priority elsewhere at some point in that range.

BTW: Thanks Gary for posting more files here.

[gd_barnes]

Originally Posted by mdettweiler

Hmm...interestingly enough, based on the processing rate shown on the IB5000 progress page, my estimate of the server drying the two ranges in a total of 7 days is pretty accurate. Of course, as Gary said, I failed to account for the distinct possibility of him shifting his priority elsewhere at some point in that range.

BTW: Thanks Gary for posting more files here.

I think you are doing some sort of that new "fuzzy" math again.

Now, Max, you should no better than to debate me on something math-related. It'd be about like me trying to debate you on something computer-related. lmao

Of course this is about 10-12 hours later but let me show you how it is done (lol)...

As of 6 PM EST:

Port 5000 has 48358 remaining knpairs! << -----
knpairs.txt - Size: 531962
Last Updated: 12/29/2008 3:15:39 PM
first k/n pair 663 602715
last k/n pair 725 620000


From progress report of yesterday - 3711 pairs processed
From progress report of 2 days ago - 3698 pairs processed
Analysis of current users processing: Same as yesterday per progress report today.

Therefore estimate - 3700 pairs / day << -----
(same as my estimate early this morning)


Actual estimate:

48358 / 3700 = ~13.1 days

It's about 1/2-day less then the 13.6-13.7 day estimate (rounded to 14 days) that I gave before...exactly what one would expect for an estimate 10-12 hours later. So ETA would be Jan. 11th around 7-8 PM EST if no one, including me, touched their machines before then, assuming no increase in testing times / fftlen changes, etc. for the ever-increasing n-range. If you account for slightly increasing testing times, I'm speculating that might add another 2-8 hours so this estimate is acutally a bit low.

I think the problem in your estimate is that you can't use n-ranges processed per day to get an accurate estimate because what is returned to the server can vary widely from one minute to the next or one hour to the next.

Good luck debunking this one!

And finally...I know you probably won't but I just like to rib you so don't take anything personally. More than anything, I just want to make sure you know a way to come up with a more accurate estimate like this.


Gary

[mdettweiler]

Originally Posted by gd_barnes

I think you are doing some sort of that new "fuzzy" math again.

Now, Max, you should no better than to debate me on something math-related. It'd be about like me trying to debate you on something computer-related. lmao

Of course this is about 10-12 hours later but let me show you how it is done (lol)...

As of 6 PM EST:

Port 5000 has 48358 remaining knpairs! << -----
knpairs.txt - Size: 531962
Last Updated: 12/29/2008 3:15:39 PM
first k/n pair 663 602715
last k/n pair 725 620000


From progress report of yesterday - 3711 pairs processed
From progress report of 2 days ago - 3698 pairs processed
Analysis of current users processing: Same as yesterday per progress report today.

Therefore estimate - 3700 pairs / day << -----
(same as my estimate early this morning)


Actual estimate:

48358 / 3700 = ~13.1 days

It's about 1/2-day less then the 13.6-13.7 day estimate (rounded to 14 days) that I gave before...exactly what one would expect for an estimate 10-12 hours later. So ETA would be Jan. 11th around 7-8 PM EST if no one, including me, touched their machines before then, assuming no increase in testing times / fftlen changes, etc. for the ever-increasing n-range. If you account for slightly increasing testing times, I'm speculating that might add another 2-8 hours so this estimate is acutally a bit low.

I think the problem in your estimate is that you can't use n-ranges processed per day to get an accurate estimate because what is returned to the server can vary widely from one minute to the next or one hour to the next.

Good luck debunking this one!

And finally...I know you probably won't but I just like to rib you so don't take anything personally. More than anything, I just want to make sure you know a way to come up with a more accurate estimate like this.


Gary

Hmm...my most recent estimate of 7 days was, in fact, determined using a method similar to yours. How we came up with different answers is beyond me...maybe I plugged something into a calculator the wrong way.

Oh, wait...I just figured out where I went wrong! I took the # of k/n pairs processed yesterday on IB5000, but divided them into the # of k/n pairs remaining in IB400!

Max

[IronBits]

Max's problem with his estimation is due to not having control over where your quads are going to be, to make his predictions come true

[mdettweiler]

LLRnet IB5000 has completed 600K-605K, lresults emailed to Gary.