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

[rogue]

Originally Posted by Mini-Geek

Well, that would certainly explain it, but who knows if greeting.txt is right. If you can see the screen output from prpserver.exe (i.e. what appears in the command line window) it should tell you what version it is as it starts up (so it'll be in the top couple lines of text).

Partially. (seems to just be PRPnet being weird, possibly because it's an older version; but the fact that I get anything is a good sign) The /user_stats.html page looks correct, the /server_stats.html (same as /) page looks garbled, (e.g. first line is "+ADw-style type+AD0AIg-Text/css+ACIAPgA8-/style+AD4APA-/head+AD4-") and /server_status.html is blank.

Definitely not 2.4.1.

[gd_barnes]

The links in the 1st post display perfectly to me. I'm trying to figure out why they'd be any different for you. We're now at n=~219K.

Max, not to be too dictatorial here but the first priority after you get back and after you load up the NPLB server and my private PRPnet server should probably be to upgrade this CRUS server to 2.4.1. It stinks when someone who wants to do work on it can't. Let me know if I can do anything to help. I assume you'll have to update my clients also. If I can just copy some client files over to speed the process along, I will.

Edit: I just checked and the screen output from pairs being sent and received definitely shows version 2.2.3. I also see that Max shows that in the 1st post of this thread.


Thanks,
Gary

[mdettweiler]

Oh, yowch. Just what I was afraid of coming back from my trip to find.

First of all, to answer a question that seems to have popped up a few times, all the servers except my personal server are running 2.3.0, which includes G1300. The greeting.txt entry (which includes what Gary was seeing in his client logs as well) was just my laziness in not updating that file when I upgraded the server. Sometime or other I'll just take the version number out of there so I don't have to bother.

I'll take a look at it as soon as I get the chance. As of now, I didn't get the chance to read the latest action here in detail. I may be able to do something tonight, but it may have to wait until tomorrow.

[mdettweiler]

Ergh, I figured it out now. *bangs head*

Okay, first of all, regarding those two 207K pairs that are behaving strangely: that's due to some fallout from a little bug which I explained earlier regarding the time the server takes to sort candidates by decimal length when they're first loaded. Gary, if I explained the full intricacies of this bug here it would probably just end up confusing you more, so I'll suffice to say just that I'm aware of the problem and will take any action necessary.

Mini-Geek, the reason why you're having problems using your spanking new 2.4.1 client is that while the 2.4 server is backwards-compatible with earlier clients, the reverse is not true. That is, you have to have a 2.4 server to run a 2.4 client.

As of now, the only "live" server I know of running 2.4.1 is my personal PRPnet server, on which I planned to test the new version in action before putting it out on the other servers. My original goal was to have that testing go on while I was away, but since my quad was off the whole time, that didn't happen. I'll give it another day or two and assuming everything checks out, I'll upgrade everything else to 2.4.1. That way, people will be able to connect with either 2.3 or 2.4 clients (or even 2.2 clients like Gary's--yes, that reminds me, when we get everything upgraded to 2.4 I'll send him new client packages for his setup ), and we should be finally free of blank results ("barfs").

[gd_barnes]

Ah, makes sense. No need to explain details. I remember before when we started (or restarted) a server that the first few pairs would sometimes go off into la-la land for days before being handed out. That isn't a "really bad" problem in my mind since they eventually get properly tested. It's just like someone cached them and never tested them.

How will we get the pairs with blank residues retested? Will we need to do that manually?

Sorry to hear about your quad not being on. I noticed it too. That is, I saw that your personal server on my machine was not handing anything out. Too bad I couldn't remotely turn it on for you. lol

[mdettweiler]

Quick update: I just took a look at all the PRPnet servers and have verified a couple of things.

• The little issue with those 207K pairs on G1300 acting strangely seems to have resolved itself, as I would have expected it to.
• PRPnet 2.4.1 seems to be working OK on my personal server, and I'll continue testing it over the next couple of days. I did encounter a strange segfault on the server end that seemed like it might have had something to do with some rejected/expired tests from some of my clients that had sat for a week with work in queue. I'll wait and see if it turns up again.

Everything seems A-OK now.

[gd_barnes]

Tim,

For the next couple of days until Max is comfy with version 2.4.1, you might try running this effort with version 2.3 clients since we know it is 2.3 now.


Gary

[mdettweiler]

Originally Posted by gd_barnes

How will we get the pairs with blank residues retested? Will we need to do that manually?

For personal servers (mine, yours, and results I've processed for anyone else like Sven or Lennart), I usually just fill them in myself, since there usually isn't too many of them. Actually, interestingly enough, there seem to be two types of barfed results that occur: one where only one blank result is recorded, and the other where two results are recorded, one blank and one correct. Quite often they're the latter, so the easiest way to clean up all barfs with one process is find and delete any lines with blank results, then fill in any k/n pairs that shouldn't be there but aren't.

Though I haven't actually yet had to do any results processing for CRUS PRPnet servers (the first will be for the 150K-200K range of Sierp. base 22 which is waiting for me as soon as I get the chance), I'll be using the same process outlined above to clean out barfs. Of course, as always, everything will be verified against the original sieve file to make sure there is one and only one result in the end for each sieve file entry.

For NPLB, the situation will be a bit more complex. The G2000 server we've got running over there is doublechecking work we've already done the first time around, which means that I won't, in fact, have to "process" the results, per se. Instead, we'll just have both the first-pass and doublecheck results loaded into the DB, and let the DB compare the two runs and notify us of any mismatches or holes in either set. To handle barfs in this setting, Dave's going to set it up so that any blank results are automatically ditched. In the case of the Type II barf described above, we'll be left with one good result, or with a Type I barf, we'll be left with a hole, which can then be easily spotted and filled in when we're checking the two datasets against each other.

Sorry to hear about your quad not being on. I noticed it too. That is, I saw that your personal server on my machine was not handing anything out. Too bad I couldn't remotely turn it on for you. lol

Yeah, I was hoping to get on and send you an email so you wouldn't be wondering about what had happened, but didn't get the chance since I was quite busy pretty much the whole time. Speaking of turning things on remotely, though, that's something I'd been pondering for a while that could be quite useful for my quad. Most motherboards today are supposed to support "Wake On LAN", which allows a computer to be turned on via a network signal. Theoretically, this would be exactly what I need. However, in practice, I have never, ever gotten this to work on any computer, regardless of how modern, even when I try to make it easier on the computer by only putting it in standby instead of shutting it down. If anyone else around here has used Wake on LAN successfully, please send me a PM or email about how you did it!

[mdettweiler]

Originally Posted by gd_barnes

I wrote a response at about the same time as yours. Just one more question there.

Yep, saw that and included it in my next note.

Originally Posted by gd_barnes

Tim,

For the next couple of days until Max is comfy with version 2.4.1, you might try running this effort with version 2.3 clients since we know it is 2.3 now.


Gary

Actually, in fact, I was going to write a note to Tim saying that he's welcome to use my personal server if he wants to play around with a 2.4.1 client, if he doesn't mind doing my work. Tim, you can expect a PM about this in a few minutes.

[mdettweiler]

With PRPnet 2.4.3 seeming to be quite stable on both the server and client ends, I've upgraded all the NPLB and CRUS servers to the latest version. Note that while the 2.4.3 server is backwards-compatible with older clients, a 2.4 client will only work with a 2.4 server.

Since PRPnet 2.4's largely revamped communications protocol should make it immune to the blank-residue problem that plagued earlier versions, we are no longer bound by the limitation of minimizing server load drastically. Discussion is welcome on what which bases and drives we should put on PRPnet besides Sierp. base 22 which we already have in G1300.

[gd_barnes]

The server has now dried and the drive is complete.