PRPnet server bugs and barfing problem

[henryzz]

Note by mdettweiler: this thread was split off from the main PRPnet thread.

on http://nplb-gb1.no-ip.org:3000/server_stats.html there are two columns named min N when one should be max N

[rogue]

Originally Posted by henryzz

on http://nplb-gb1.no-ip.org:3000/server_stats.html there are two columns named min N when one should be max N

I'm aware of the problem. It's pretty minor, so until something more significant shows up, I won't put out another release.

[mdettweiler]

Lennart just sent me a PM informing me that he couldn't reach the G3000 server. I checked the server, and it seems that somehow it got all messed up. There are a large number of results in completed_tests.log from the last few hours that have blank residuals! I'm not sure how this occurred; I'll need to do a bit more investigating. In the meantime, G3000 is offline.

[mdettweiler]

Okay, I've got all that sorted out. Still no clue as to why it malfunctioned, but at least everything should be back to normal now.

[mdettweiler]

Originally Posted by mdettweiler

Okay, I've got all that sorted out. Still no clue as to why it malfunctioned, but at least everything should be back to normal now.

Upon further investigation of the log files, I've got a basic idea of what probably happened. My guess is that there was a brief interruption in a connection between the server and one of the clients around 8:55 AM GMT today. The interruption must have occurred while the server was in the middle of either sending or receiving (probably receiving, from what I could tell), which apparently confused the heck out of the server.

One unfortunate side effect of all this is that the prpserver.candidates file ended up getting wiped. I'm not sure how it was wiped, but presumably it happened as part of the whole mess-up. I was, however, able to rebuild the prpserver.candidates file from the original sieve file, and remove all completed tests, so we shouldn't miss anything. The only remaining side effect is that a few people might encounter rejected tests (in this case, that would only be Lennart and I, since we're the only ones on the server right now).

Max

[gd_barnes]

Why are these two links the same thing?:

http://nplb-gb1.no-ip.org:3000/
http://nplb-gb1.no-ip.org:3000/server_stats.html

Please remove one of them or change one of the pages to what it should be.

Other issues:
At 3 PM CDT this afternoon, I was receiving pairs at n=~108000. How come most k's in the above pages are showing a "min n" of 100200-100500? I don't think that anyone is cacheing THAT many pairs? How often is this page updating?

Max, in the 1st post here, I have updated the "n-value" loaded in the server to the range shown in your PM to me as well as the "currently processing at" n-value from the n-range that is currently being handed out to my clients. You had it incorrectly marked as "n-value" 130K-150K and "currently processing at" ~140K. That mislead me greatly into thinking we only had a nominal amount of work left. When I started getting pairs at n=~107K Sat. afternoon, I was very confused. Hence our PM exchange. If we're going to have that info. there, please make sure that it is correct. The "currently processing at" n-value needs to be updated every 2-3 days maximum like is done at NPLB.

Can we fix the issue with the two "min n" columns?

Can we get a web page that shows in a similar format as the one at NPLB at nplb.ironbits.net/? We need more general info. like that.

I've done a lot of back office batch and online testing for legacy financial systems that had to be perfect in production. This is just a warning that I will pick you guys to death on some of this stuff so be prepared!


Thanks,
Gary

[Lennart]

Originally Posted by gd_barnes

Why are these two links the same thing?:

http://nplb-gb1.no-ip.org:3000/
http://nplb-gb1.no-ip.org:3000/server_stats.html

Please remove one of them or change one of the pages to what it should be.

Other issues:
At 3 PM CDT this afternoon, I was receiving pairs at n=~108000. How come most k's in the above pages are showing a "min n" of 100200-100500? I don't think that anyone is cacheing THAT many pairs? How often is this page updating?

Max, in the 1st post here, I have updated the "n-value" loaded in the server to the range shown in your PM to me as well as the "currently processing at" n-value from the n-range that is currently being handed out to my clients. You had it incorrectly marked as "n-value" 130K-150K and "currently processing at" ~140K. That mislead me greatly into thinking we only had a nominal amount of work left. When I started getting pairs at n=~107K Sat. afternoon, I was very confused. Hence our PM exchange. If we're going to have that info. there, please make sure that it is correct. The "currently processing at" n-value needs to be updated every 2-3 days maximum like is done at NPLB.

Can we fix the issue with the two "min n" columns?

Can we get a web page that shows in a similar format as the one at NPLB at nplb.ironbits.net/? We need more general info. like that.

I've done a lot of back office batch and online testing for legacy financial systems that had to be perfect in production. This is just a warning that I will pick you guys to death on some of this stuff so be prepared!


Thanks,
Gary

Must be a typo Change server_stats.html to http://nplb-gb1.no-ip.org:3000/server_status.html


Lennart

[gd_barnes]

OK, corrected. Thanks Lennart for the correct link.

But the info. on the status link is incorrect. It shows exactly:

Sierpinski Base 6 6 k remaining31 n remainingmin n is 1760 (100287 digits long)

Can we please correct this? Almost everything is wrong including grammar, n-value, and size. It should be something like:

Sierp base 6, 28 k's remaining, pairs remaining 1760, min n is xxxxxx (xxxxxx digits).

Obviously the "min n" cannot be 1760. Also the size can't be right either. A size of 100287 would be for an n-value of ~129000. We don't even have that range loaded in the server!


Thanks,
Gary

[gd_barnes]

Holy crap. I just checked. Lennart, you must have multiple quads on Sierp base 6. We're close to drying it out! Unless I'm misunderstanding something, nice work! Have you received notification of any primes?

[Lennart]

Originally Posted by gd_barnes

Holy crap. I just checked. Lennart, you must have multiple quads on Sierp base 6. We're close to drying it out! Unless I'm misunderstanding something, nice work! Have you received notification of any primes?

I have some cores on it.

No no mail.

Lennart

[gd_barnes]

Cool. I just wanted to make sure I wasn't hallucinating there.

Guys, two more problem:

First:

http://nplb-gb1.no-ip.org:3000/ show k's remaining for 36772, 118147, and 157473. These were found prime back in January and should not be on the list. If you remove those, you get the correct 28 k's remaining. The primes were:
36772*6^126672+1
118147*6^122688+1
157473*6^113124+1

That will correct part of the problem with http://nplb-gb1.no-ip.org:3000/server_status.html as for the # of k's remaining, which shows 31 k's remaining vs. 28.

Second:

Lennart received no Email but should have received them on 4 primes. The primes found for the current run that are shown in the PRP.log file on the server are:

72785*6^118347+1
98860*6^119849+1
123285*6^147200+1
145076*6^149946+1


A lot of problems...a lot of work to do yet. I'm not willing to load n>150K in the server until we do a rerun of about an n=10K range of this where there are primes and all of these issues are corrected. That is testing with test data, which means a double-check in this case.


Gary