PRPnet beta test server

[rogue]

Originally Posted by gamer007

Glad to see that it's back up.

By the way, what should I do with these 2 "z_____" files lying around? I've been having some issues last night, and it seemed to be skipped 2 numbers I had queued to test.

The z*** files are temp files created by LLR. They will only be left around if LLR is interrupted.

[IronBits]

Originally Posted by PCZ

Proxy is a function the server can perform in LLRNET.
Apparently it can crash an LLRNET server, although personally i never observed or believed that.

I certainly have. Confirmed by Beyond for sure. It happens time and time again, consistently and reliably.
That's why I banned using proxy servers against any of the servers I have running.

Something to do with it opening a port for each person/computer that returned work.
Someone else can chime in or provide the linkage to the conversatation we had on it.

[PCZ]

Easier to ban than fix i suppose.

[gamer007]

Looks like the user stats reset to zero and is counting back up. Is this normal or did something happen?

[mdettweiler]

Originally Posted by gamer007

Looks like the user stats reset to zero and is counting back up. Is this normal or did something happen?

Hmm...that's weird. I did restart the server a few times within the last few hours, but theoretically that shouldn't reset the stats since they're stored in a text file.

I just checked the server through VNC and apparently user_stats.ini was blanked out. Yet, this doesn't explain why the stats still contain a couple users (MyDogBuster and cipher), both of whom had only submitted one or two results earlier on, and neither of whom had submitted any results after the server was restarted. Also, I see an entry for "tweiler", which seems to be some weird truncation of my username, in addition to the "mdettweiler" entry.

One thing that might have some bearing on this is the reason why I restarted the server in the first place: I was using a customized build of the server where I edited one line in Candidate.cpp to make it output the user ID as well to completed_tests.log. The modification didn't work, but other than that the server appeared to be working OK at first glance. It's possible that my modification somehow messed up the user stats. (I don't know C++, so I was sort of taking an educated guess on what to change in the source code. Thus, if it would have had non-obvious consequences then I probably wouldn't have realized it. )

Considering as how my modification didn't work anyway, I'll switch the server back to the stock build. If the stats don't get fouled up again, then we're probably OK; if we encounter further issues of this sort with the stock build, I'll report it to Mark as a bug.

[mdettweiler]

Okay, I've switched the server back to the stock build of PRPnet. I also reset the stats completely while I was at it, since they had obviously gotten messed up and I didn't want to compound the issue any further. Thus, the stats *really* are supposed to reset to 0 this time.

Edit: I also checked the CRUS G3000 server, which I had switched over to the same modified binary earlier today. Its stats were in similar disarray. Thus, I am left to conclude that this *is* a problem unique to my failed, transmogrified modification of PRPnet, and not a bug in the real McCoy. (FYI: the G3000 server has also been switched back to the proper binary and its stats reset in a similar manner to G2000.)

[rogue]

Originally Posted by mdettweiler

Okay, I've switched the server back to the stock build of PRPnet. I also reset the stats completely while I was at it, since they had obviously gotten messed up and I didn't want to compound the issue any further. Thus, the stats *really* are supposed to reset to 0 this time.

Edit: I also checked the CRUS G3000 server, which I had switched over to the same modified binary earlier today. Its stats were in similar disarray. Thus, I am left to conclude that this *is* a problem unique to my failed, transmogrified modification of PRPnet, and not a bug in the real McCoy. (FYI: the G3000 server has also been switched back to the proper binary and its stats reset in a similar manner to G2000.)

There is definitely something really weird going on with user stats, but I have not be able to figure out the problem because I haven't reproduced it on my own. I'm going to change the structure a little and see if that helps to resolve the problem.

[mdettweiler]

Originally Posted by rogue

There is definitely something really weird going on with user stats, but I have not be able to figure out the problem because I haven't reproduced it on my own. I'm going to change the structure a little and see if that helps to resolve the problem.

As I said earlier, I think it's only due to my transmogrification of the PRPnet server that I tried using earlier. The problem didn't show up at all except when the modified binary was in use. Thus, it seems that the problem is not present in the real version--which would be supported by the fact that you can't reproduce it on your own.

[rogue]

Originally Posted by mdettweiler

As I said earlier, I think it's only due to my transmogrification of the PRPnet server that I tried using earlier. The problem didn't show up at all except when the modified binary was in use. Thus, it seems that the problem is not present in the real version--which would be supported by the fact that you can't reproduce it on your own.

I know that PrimeGrid has had some issues with user stats, but I don't know if they have been resolved.

[gd_barnes]

I have suggested to Max that we only do "quasi" double-checks of previous n=260K-300K tests with the server -OR- non-top-5000 tests in the future. By quasi, I mean they won't be "counted" as double-checks. We'll still double-check them in a regular fashion in the future -or- with PRPnet once all testing has been fully completed.

In the future before running any new kind of software or server, regardless of type, on 1st pass tests for top-5000 work, all stress testing must be complete and all bugs must be worked out with residues, stats, and copying off of results, etc.

In the mean time, we'll go ahead and complete what has already been reserved from the mini-drive but do no more from there. I'll then suggest that someone double-check it using manual LLR and compare the residues.

For you mainframers, this means that we do our testing in a test environment, not a production environment. :-)



Gary

[gd_barnes]

I have suggested the following test plan for the PRPnet server after we are done with our current mini-drive ranges:

1. Load some k=300-1001 for n=260K-300K work in there and compare residuals to the original tests on our 1st thru 3rd drives. That will be a "medium" test.
2. Get all stats and results copying set up.
3. After #2, load some k=2000-3000 for n=10K-30K work in there and stress test the heck out of it and do "small" tests. I'll throw several quads on it to give it a good jolt.
4. After #3, load some k=300-1001 for n=560K-600K work in there and compare residuals to the original tests on our 1st thru 3rd drives. That will be a "medium big" test.

We'll also want to test unusual situations such as stopping the server right on the hour when the results are supposed to be copied off or right at the end of the day when the current day's results are moved off to the daily files followed by restarting the server.

There will be many more things that I'm sure we'll think of that probably need to be tested.


Gary