Sven has reported completion of k=319 to n=875K and has sent me the results. No primes since n=700K. He is continuing on to n=1M.

On my k=325, 335, & 347, I am at n=720K. No primes since n=700K.

A little while ago, I got a PM from Vaughan, who currently has a slow core on port 9000 at a remote location. He said that since he doesn't have access to the machine running it that if the server dried, that processing would be lost.

While it is only one slow core; it got me thinking about something: What would people think if we did another 6 k drive here and loaded port 9000 up with it for starting after the 9th drive is done? It would be for the 6 currently unreserved k's in this drive that are currently at n=700K; the lowest of any search level for k < 400. The k's are: 351, 355, 357, 361, 363, & 365.

Initially, we could just reserve n=700K-800K for the server for hose 6 k's and leave n>800K open to inidividual-k reservations. Depending on what people want at that time, we could then either dry the server or load it up with the next higher n-range.

Right now, Bruce is making mincemeat out of the 9th drive...blowing through it at 1000 pairs per hour after finishing his sieving effort a little early. At the current rate, it will probably dry out in < 2 days; which of course means that we'll officially have all k=1400-2000 fully searched up to n=650K once everything is verified!


Gary

If you can save an asset of Vaughan's, then save it even if it is a slow system. :smile:

Its an intel C2D6300 in another country! I hope we don't upset them by calling them slowpokes :)

According to bok's stats prediction DeeDee's due to overtake Brucifer in about 1952 days so you've got 5 years start, so long as you don't work that account name between now and 2014.

Do I hear any objections to loading the aforementioned k's into port 9000 for a "temporary" mini-drive starting at n=700K at the end of the 9th drive pairs?

I say temporary because we may just run it from n=700K-800K in the server depending on what people want to do here.

i would prefer to upload those new k's in 9000 because the other 6k-mini-drive is almost done!

and if the found primes will reported here [url]http://www.noprimeleftbehind.net/index.php[/url] too, i think others will change to those k's to push them up to 1M!

[QUOTE=gd_barnes;175176]A little while ago, I got a PM from Vaughan, who currently has a slow core on port 9000 at a remote location. He said that since he doesn't have access to the machine running it that if the server dried, that processing would be lost.[/QUOTE]

Hm, this makes me wonder something:
How hard would it be to make it so that any port that is not configured will seamlessly default to a chosen port? Similar to a catch-all email address, but for ports. My firewall calls it a Virtual DMZ host, but doesn't allow port redirecting (which would be that any random port on the external gets mapped to, say, port 8000 on the internal). I think I recall port redirection happening before over there, so maybe it can be done.
Just a thought so we can shut down ports without having to worry about unattended computers going idle. :smile:

[quote=Mini-Geek;175223]Hm, this makes me wonder something:
How hard would it be to make it so that any port that is not configured will seamlessly default to a chosen port? Similar to a catch-all email address, but for ports. My firewall calls it a Virtual DMZ host, but doesn't allow port redirecting (which would be that any random port on the external gets mapped to, say, port 8000 on the internal). I think I recall port redirection happening before over there, so maybe it can be done.
Just a thought so we can shut down ports without having to worry about unattended computers going idle. :smile:[/quote]
Well, that would probably work (in fact it was done before to redirect port 500 to port 6000), but for one problem: the NewPGen header line. If a client is not *completely* cleaned out before the server switches headers, then it will never think to get rid of the old header line in its workfile.txt file, and all results from that client will be rejected until the workfile.txt is manually deleted/fixed.

If we were going to do this, we'd need to make sure that not only was the original server completely dry, but that no clients are still sending anything to the server. That way we could be sure everybody's clients are completely dried out before switching over.

But, nonetheless, it is a rather interesting idea to load a new 6k mini-drive into port 9000. Especially since, as Karsten said, we're moderately close to finishing the first one.

OK, here we go: Reserving k=351, 355, 357, 361, 363, and 365 for n=700K-800K for port 9000 for another 6k mini drive.

I just now sent the file to David.

At the current rate, port 9000 will start handing out pairs for this new range in 40-45 hours.


Gary

k=349 and 353 are complete to 819K, pausing to sieve.

status report on k=311 and 337
 

both tested till n=1.57M - I am still working on those.