PRPnet servers for NPLB

[gd_barnes]

Max,

It looks like Lennart brought a fair-sized number of cores to port 9000 in the last day. Can you load n=796K-800K in PRPnet port 9000 sometime today? It will probably need to be today. Thanks.


Gary

[mdettweiler]

Originally Posted by gd_barnes

Max,

It looks like Lennart brought a fair-sized number of cores to port 9000 in the last day. Can you load n=796K-800K in PRPnet port 9000 sometime today? It will probably need to be today. Thanks.


Gary

I think what you're seeing is a somewhat normal fluctuation of how many cores he has on G9000 at any given moment: from what it looks like, I'm guessing he's got his clients set to split their time between NPLB and some other server (possibly a PrimeGrid or personal server), which means that clients are moving on and off throughout the day.

As I've watched the hourly output numbers, I've noticed a pattern of ebbs and flows; sometimes Lennart's output can go all the way up to 80/hour, other times it's down to 5/hour. He seems to be moving the server forward at a rate of about .3-.4K per day.

Lennart, are you by chance planning to sustain your current rate of processing on the server? If so, I'll load in 796K-800K as Gary suggested; otherwise, I'll just keep refilling it 1K at a time as per standard operating plan.

[Lennart]

Originally Posted by mdettweiler

Lennart, are you by chance planning to sustain your current rate of processing on the server? If so, I'll load in 796K-800K as Gary suggested; otherwise, I'll just keep refilling it 1K at a time as per standard operating plan.

No I do some work on small n. I have NPLB as a fallback when i clean up and reload my servers. :)

Lennart

[gd_barnes]

Oh, OK. Makes sense. I had also seen the fluctuations but I was looking at more of an average daily processing the last 3 days of > 1000 pairs a day. Even with the large hourly fluctuations, the daily fluctuations were far less on a percentage basis, i.e. ~1100, 800, and 1150 the last 3 days including today GMT. (Tues. is now done GMT.) The average # of pairs in an n=1K range is only ~3800.

Max, I might suggest an n=2K range since it can fluctuate quite a bit. We don't want to be caught off guard and the server to dry. If it's in his server list, we would just lose his processing altogether if it dried.

Thinking of it mathwise and to avoid too large of gaps for extended periods: If Lennart would be close to completing n=796K-800K at approximately the same time that the LLRnet server completes n=786K-796K, then loading n=796K-800K would be the way to go. But since we don't know what those fluctuations will be right now, a 4K range is probably a little large.

Thanks for keeping us in your fallback server list Lennart.

[mdettweiler]

Originally Posted by gd_barnes

Oh, OK. Makes sense. I had also seen the fluctuations but I was looking at more of an average daily processing the last 3 days of > 1000 pairs a day. Even with the large hourly fluctuations, the daily fluctuations were far less on a percentage basis, i.e. ~1100, 800, and 1150 the last 3 days including today GMT. (Tues. is now done GMT.) The average # of pairs in an n=1K range is only ~3800.

Max, I might suggest an n=2K range since it can fluctuate quite a bit. We don't want to be caught off guard and the server to dry. If it's in his server list, we would just lose his processing altogether if it dried.

Thinking of it mathwise and to avoid too large of gaps for extended periods: If Lennart would be close to completing n=796K-800K at approximately the same time that the LLRnet server completes n=786K-796K, then loading n=796K-800K would be the way to go. But since we don't know what those fluctuations will be right now, a 4K range is probably a little large.

Thanks for keeping us in your fallback server list Lennart.

All right, 2K it is then. I'll probably load in 796K-798K later today; then I'll continue to keep an eye on it and load in 798K-800K as we get close to 798K.

[mdettweiler]

Karsten,

As you know, there's currently no easy way to determine the lowest untested n remaining in PRPnet port 9000 without direct access to the DB. I'm planning to add some code to the http://www.noprimeleftbehind.net/prpnet/ page to make it query this information and display it, but in the meantime, I remembered that you'll probably need this information to determine which ranges are ready for you to process. So, I just wanted to let you know: the current lowest outstanding pair in G9000 is 453*2^810127-1. You should therefore be able to process all ranges from that server below that.

Hope this helps,
Max

[kar_bon]

Originally Posted by mdettweiler

As you know, there's currently no easy way to determine the lowest untested n remaining in PRPnet port 9000 without direct access to the DB. I'm planning to add some code to the http://www.noprimeleftbehind.net/prpnet/ page to make it query this information and display it, but in the meantime, I remembered that you'll probably need this information to determine which ranges are ready for you to process. So, I just wanted to let you know: the current lowest outstanding pair in G9000 is 453*2^810127-1. You should therefore be able to process all ranges from that server below that.

I don't really need that information: I download the result-files and process them by counting the done pairs in a special n-range by scripts.
If there're no pairs remaining, I compare them with the original sieve-file: If any pair is missing or doubled, I'm aware of it.

The information I need more for the PRPnet-stats page is the sum of all remaining pairs.
For now only a copy of the table of k-values in a spreadsheet and adding them there will do this!

[mdettweiler]

Originally Posted by kar_bon

I don't really need that information: I download the result-files and process them by counting the done pairs in a special n-range by scripts.
If there're no pairs remaining, I compare them with the original sieve-file: If any pair is missing or doubled, I'm aware of it.

The information I need more for the PRPnet-stats page is the sum of all remaining pairs.
For now only a copy of the table of k-values in a spreadsheet and adding them there will do this!

Ah, okay. Yes, the total number of remaining pairs will definitely be on the status page once I'm done rewriting it; in the meantime, I suppose pulling the information out of a spreadsheet as you're doing is the easiest way.

[rogue]

Originally Posted by mdettweiler

Ah, okay. Yes, the total number of remaining pairs will definitely be on the status page once I'm done rewriting it; in the meantime, I suppose pulling the information out of a spreadsheet as you're doing is the easiest way.

If you have an enhancement to the code base, please send it on to me for potential inclusion in the next release.

[mdettweiler]

Originally Posted by rogue

If you have an enhancement to the code base, please send it on to me for potential inclusion in the next release.

Well, I wasn't planning to integrate this into the PRPnet code base (I don't know C++, so that would be a little hard); rather, I was planning to integrate it into my Perl script that I use to generate the status page at http://www.noprimeleftbehind.net/prpnet/. Currently that page doesn't display too much info, but the idea is to get it somewhere closer to what http://www.noprimeleftbehind.net/llrnet/ displays (that's the original script, designed for LLRnet, which pulls all its information from the various text files).

[rogue]

Originally Posted by mdettweiler

Well, I wasn't planning to integrate this into the PRPnet code base (I don't know C++, so that would be a little hard); rather, I was planning to integrate it into my Perl script that I use to generate the status page at http://www.noprimeleftbehind.net/prpnet/. Currently that page doesn't display too much info, but the idea is to get it somewhere closer to what http://www.noprimeleftbehind.net/llrnet/ displays (that's the original script, designed for LLRnet, which pulls all its information from the various text files).

Let me know what stats you want to see and I can look into the effort to display them.