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

gd_barnes · 2010-07-26, 16:37

Quote:

Originally Posted by mdettweiler

The server is almost at n=300K, so I'm going to go ahead and load in 300K-350K. I was going to wait until Gary got back from his trip, but he's two days overdue and the server's about to dry.

Note that this new sieve file is sieved to the much more optimal depth of p=5T (rather than 700G as the old one was), so this should go at least a little faster.

That is incorrect. The new file is sieved to P=50T and the old one to P=7T. You're off a digit.

So, can I assume that you have the newest sieve file for S22?

Mathew · 2010-07-26, 17:30

Gary,

I have no problem with S26 to 300K (Also on your recommended bases list). Hopefully more will connect else it may be ~6 months to complete. I understand you were trying to even the sides out. I was thinking R24 because S24 was already to 100K and it was the lowest base on the recommended misc section. I did not know about the overhead issues though. Now that makes sense.

Mathew

rogue · 2010-07-26, 17:56

Quote:

Originally Posted by gd_barnes

Max and Matthew, are you OK with S26 for n=250K-300K? Matthew, I do not recommend smaller tests such as R24 for a PRPnet server because the overhead time associated with the sending and returning of pairs is not worth it for shorter tests. Mark had mentioned that previously.

For public PRPNet servers, PRP tests should take at least 60 seconds before being loaded. For private PRPNet servers, the time can be shorter (20 seconds or so) because you won't have the internet overhead. For servers with smaller workunits, I would recommend bumping the max number of work units high enough so that clients can grab two hours or more of work at a time.

Note that these are personal opinions.

mdettweiler · 2010-07-26, 21:19

Quote:

Originally Posted by gd_barnes

Sorry. I'm just now getting back on after a lot of organization and clean up between my 2 planned out-of-town trips. I'm leaving Weds. again and will be gone until the following Thurs. For the upcoming trip, I will be on every day for about an hour or so. I had no access on my last trip.

My preference is to load in S26 for n=250K-300K. The idea behind this drive has been to "catch up" some bases with their neighbor bases that have similar #'s of k's remaining. Looked at in that way, S26 with only 3 k's remaining is a higher priority than S22 for n>300K.

I had actually observered this server not long after I got back early Saturday and figured that it would dry sometime late Tuesday. I'm glad that Max decided to subsequently delete n>300K.

Max and Matthew, are you OK with S26 for n=250K-300K? Matthew, I do not recommend smaller tests such as R24 for a PRPnet server because the overhead time associated with the sending and returning of pairs is not worth it for shorter tests. Mark had mentioned that previously.

Max, since Matthew has been the only one on here for a while, if he would really like to do S22 for n>300K, then go ahead and load it for n=300K-350K instead of S26. BUT...do you actually have an S22 file for n=300K-500K sieved to P=50T? I do not remember sending that to you and we definitely don't want a file only sieved to P=7T loaded in there.

I'll check for a response to this in a few hours. If I need to send the next S22 file to Max, I will at that time. But other than this, this is all that I will have time to respond to until very late today including PMs and Emails. I'll have time for a full-fledged response to everything on Tuesday.

Gary

Ah, glad to see you're still alive.

Since you'd said earlier that you would be home Saturday afternoon, by Monday morning I was beginning to wonder if something unfortunate had happened.

Yes, I have the latest sieve file for S22, sieved to 50T. It does seem I miscounted by a digit.

I'll go ahead and load in S26 for n=250K-300K shortly.

BTW, regarding the size of tests to run in a PRPnet server, note that I've been running 1-k bases starting at 25K through my personal server with no problems. (And that's with full internet overhead since it's being hosted on your machine.) Granted, those bases are sufficiently big that 25K is not terribly tiny, but still, n=50K on R24 shouldn't pose a problem for a v3.x PRPnet server. At that level, I'd be more worried about having to process the results with all those k's eliminated partway through than whether the server can handle it.

mdettweiler · 2010-07-26, 21:39

S22, n=250K-300K has now been loaded into port 1300.

mdettweiler · 2010-08-21, 18:38

Hi all,

In case any of you guys aren't following the NPLB forum, we had a hard drive crash on jeepford, the NPLB/CRUS server machine, yesterday. It created a few bad blocks here and there on the disk, but Gary was able to get it fixed pretty well with the Linux fsck utility.

What we didn't know until just now is that there was some data loss from the crash. While NPLB's servers and stats database escaped unscathed, the CRUS port 1300 server's database and those of Gary and I's personal servers went bye-bye.

I should be able to reconstruct the candidate load of each server pretty easily from their results files, so we won't lose more than a day of processing on any of them. However, the user stats and user primes stored in each server will be lost. That's not a big deal for the private servers, but unfortunately it means our only stats for port 1300 will be reset to 0. (We haven't yet found any primes on port 1300 since it's been upgraded to PRPnet 3.x, so there's nothing to lose there.)

Port 1300 will be the first one I reconstruct. I hope to have it up within a few hours.

Max

mdettweiler · 2010-08-21, 19:09

Port 1300 is back up and I see one of Mathew's clients has already grabbed two pairs from it.

That wasn't too hard; now I get to tackle the personal servers. Gary's won't be too hard (one of them is empty, the other is is a pretty straightforward job like 1300), but mine will be a bit of a pain since I had a handful of different CRUS bases loaded in there. Ergh.

mdettweiler · 2010-08-21, 21:41

Oops, it seems that I accidentally loaded the pairs back in as base 2 instead of base 26.

It's fixed now...sorry Mathew for the wasted CPU-time of the last couple hours.

gd_barnes · 2010-09-23, 08:26

Max,

I expect port 1300 to dry out in ~1 week at Mathew's current rate of processing. He and I discussed putting R31 for n=120.2K-150K next into the server unless you have a better idea.

Mathew,

Did you say that you determined that R31 is sieved far enough? For such a small n-range at P=3.5T, it is probably far enough. Sieving small n-ranges (that is max-n/min-n < 1.5) very deep is usually inefficient. What is left is the tail-end of a larger sieve file.

Gary

mdettweiler · 2010-09-23, 15:40

Quote:

Originally Posted by gd_barnes

Max,

I expect port 1300 to dry out in ~1 week at Mathew's current rate of processing. He and I discussed putting R31 for n=120.2K-150K next into the server unless you have a better idea.

Mathew,

Did you say that you determined that R31 is sieved far enough? For such a small n-range at P=3.5T, it is probably far enough. Sieving small n-ranges (that is max-n/min-n < 1.5) very deep is usually inefficient. What is left is the tail-end of a larger sieve file.

Gary

Sounds good. I'll await further confirmation of optimal depth before going ahead and loading it.

Mathew · 2010-09-23, 19:30

Gary,

I did not do any tests. I just came to the same conclusion as you, it is probably sieved far enough.

Max,

Feel free to load R31.

2010-07-26, 17:30	#57
Mathew Nov 2009 536₈ Posts	Gary, I have no problem with S26 to 300K (Also on your recommended bases list). Hopefully more will connect else it may be ~6 months to complete. I understand you were trying to even the sides out. I was thinking R24 because S24 was already to 100K and it was the lowest base on the recommended misc section. I did not know about the overhead issues though. Now that makes sense. Mathew Last fiddled with by MyDogBuster on 2010-07-27 at 03:08

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Sierp base 6 - team drive #3	gd_barnes	Conjectures 'R Us	373	2014-06-11 21:31
Sierp base 16 - team drive #1	gd_barnes	Conjectures 'R Us	254	2014-06-10 16:00
PRPnet 2nd drive-51 bases with <= 5 k's to n=250K	gd_barnes	Conjectures 'R Us	158	2013-08-12 03:18
New PRPnet drive discussion	mdettweiler	Conjectures 'R Us	89	2011-08-10 09:01
Sierp base 3 - mini-drive II	gd_barnes	Conjectures 'R Us	46	2009-10-26 18:19

2010-07-26, 21:39	#60
mdettweiler A Sunny Moo Aug 2007 USA (GMT-5) 3×2,083 Posts	S22, n=250K-300K has now been loaded into port 1300.

2010-08-21, 18:38	#61
mdettweiler A Sunny Moo Aug 2007 USA (GMT-5) 1100001101001₂ Posts	Hi all, In case any of you guys aren't following the NPLB forum, we had a hard drive crash on jeepford, the NPLB/CRUS server machine, yesterday. It created a few bad blocks here and there on the disk, but Gary was able to get it fixed pretty well with the Linux fsck utility. What we didn't know until just now is that there was some data loss from the crash. While NPLB's servers and stats database escaped unscathed, the CRUS port 1300 server's database and those of Gary and I's personal servers went bye-bye. I should be able to reconstruct the candidate load of each server pretty easily from their results files, so we won't lose more than a day of processing on any of them. However, the user stats and user primes stored in each server will be lost. That's not a big deal for the private servers, but unfortunately it means our only stats for port 1300 will be reset to 0. (We haven't yet found any primes on port 1300 since it's been upgraded to PRPnet 3.x, so there's nothing to lose there.) Port 1300 will be the first one I reconstruct. I hope to have it up within a few hours. Max

2010-08-21, 19:09	#62
mdettweiler A Sunny Moo Aug 2007 USA (GMT-5) 3×2,083 Posts	Port 1300 is back up and I see one of Mathew's clients has already grabbed two pairs from it. That wasn't too hard; now I get to tackle the personal servers. Gary's won't be too hard (one of them is empty, the other is is a pretty straightforward job like 1300), but mine will be a bit of a pain since I had a handful of different CRUS bases loaded in there. Ergh.

2010-08-21, 21:41	#63
mdettweiler A Sunny Moo Aug 2007 USA (GMT-5) 3·2,083 Posts	Oops, it seems that I accidentally loaded the pairs back in as base 2 instead of base 26. It's fixed now...sorry Mathew for the wasted CPU-time of the last couple hours.

2010-09-23, 08:26	#64
gd_barnes May 2007 Kansas; USA 101×103 Posts	Max, I expect port 1300 to dry out in ~1 week at Mathew's current rate of processing. He and I discussed putting R31 for n=120.2K-150K next into the server unless you have a better idea. Mathew, Did you say that you determined that R31 is sieved far enough? For such a small n-range at P=3.5T, it is probably far enough. Sieving small n-ranges (that is max-n/min-n < 1.5) very deep is usually inefficient. What is left is the tail-end of a larger sieve file. Gary

2010-09-23, 19:30	#66
Mathew Nov 2009 2×5²×7 Posts	Gary, I did not do any tests. I just came to the same conclusion as you, it is probably sieved far enough. Max, Feel free to load R31.