LLRnet servers for NPLB

[Mini-Geek]

Hate to be the bearer of bad news again, but I'm getting some instability on the 2.4.6 client. I'm currently trying to get some debug info and verify that it's on the released version (and not only one of the early-release versions of it), but at the moment I wouldn't recommend doing too much 2.4.6-specific packaging. (I suppose that you could get it ready and swap out with the newest executables whenever necessary)

[mdettweiler]

Originally Posted by Mini-Geek

Hate to be the bearer of bad news again, but I'm getting some instability on the 2.4.6 client. I'm currently trying to get some debug info and verify that it's on the released version (and not only one of the early-release versions of it), but at the moment I wouldn't recommend doing too much 2.4.6-specific packaging. (I suppose that you could get it ready and swap out with the newest executables whenever necessary)

Ooh, okay. This time around, there's not much to do to prepare the client packages (since the only file that's changed from the 2.4.5 packages is prpclient.exe itself), so I'll just hold off on those until the issues you're seeing are resolved.

[Mini-Geek]

Originally Posted by mdettweiler

Ooh, okay. This time around, there's not much to do to prepare the client packages (since the only file that's changed from the 2.4.5 packages is prpclient.exe itself), so I'll just hold off on those until the issues you're seeing are resolved.

In case you haven't been following it, it turns out there's no error, per se, it's just having trouble writing to a file, which causes it to exit. It may or may not affect other people as commonly as it affects me. In any case, I'd expect the less often you write to the file, the more stable it'd be, so longer work times and larger batches should lessen the problem.

[Mini-Geek]

I've figured out a decent workaround. Instead of running the client directly, (either from a command window or from double-clicking) anybody having a problem like mine can run a batch file like this: (made for Windows, but the idea should work for anything)

@echo off

REM a label to let it know where to loop back to
:begin

REM run the client
prpclient

REM if it gets here, it's because PRPclient exited, or you used Ctrl+C and let the batch job continue

REM pause a few seconds by pinging
ping localhost -n 5

REM then restart the script
goto begin

Or without the comments:

@echo off
:begin
prpclient
ping localhost -n 5
goto begin

This has the added benefit that it doesn't really matter whether you run it from a command window, by double clicking the batch file, or by making a shortcut to the batch file.
Note that if/when PRPclient can't write to work_xxx.save and exits, it will ignore the assignment it just got, (it'll get a new one) and the server will just have to expire the old one when the time comes.

[gd_barnes]

Originally Posted by mdettweiler

Okay, thanks. Within the next day or two I'll get client packages posted for PRPnet 2.4.6 and get the new server set up. Dave and I are still working on a couple final details for importing PRPnet results into the DB, but that shouldn't be too long and we can go ahead with starting up the server anyway.

Max,

Port 4000 has dried. We really need the new PRPnet server right away loaded up with n=740K-750K. I've made David (Ironbits) aware that port 4000 is being phased out but haven't had him officially "delete" it yet until we get the PRPnet server rolling.

Please note that this will be something that is ongoing. About 4-7 days before each server dries out, we need to have a new server set up and loaded for the next range. So we'll need to plan ahead.

For now, I'll note in the 5th drive and in the 1st post here that the drive is awaiting the new server. I'll move my 5th drive cores to the 6th drive.


Thanks,
Gary

[mdettweiler]

Originally Posted by gd_barnes

Max,

Port 4000 has dried. We really need the new PRPnet server right away loaded up with n=740K-750K. I've made David (Ironbits) aware that port 4000 is being phased out but haven't had him officially "delete" it yet until we get the PRPnet server rolling.

Please note that this will be something that is ongoing. About 4-7 days before each server dries out, we need to have a new server set up and loaded for the next range. So we'll need to plan ahead.

For now, I'll note in the 5th drive and in the 1st post here that the drive is awaiting the new server. I'll move my 5th drive cores to the 6th drive.


Thanks,
Gary

Oh, whoops! Thanks for reminding me--it slipped my mind. I'll get to work on it right now.

[gd_barnes]

Max,

Major problems on port 7000. The k/n pairs are processing with the k and n-values reversed. Likely there is a rogue carriage control character on one of the pairs. This will probably be a huge mess to straigten out. Please see what you can do. You may need to go back a couple of days in the results.

Edit: I just checked more results files. This is a much bigger mess than usual. The problem started on the 11/29 results file that was copied off on 11/30 at 12:01 AM. But here's the strange thing: It occurred on k=2403, 2407, 2411, 2415 but not on k=2405, 2409, 2413, and 2417 in that file. The same thing appears to be happening in the 11/30 results file. So it appears to be every other k-value that has the problem.

So it looks like you did something wrong with the k=2400-2600 file that you loaded in. The timing of the problem is unrelated to my inadvertant shutdown of the server. It's probably a good thing that I accidentally shut down the servers causing Bruce some problems and hence pull off of the servers.

Unfortunately my suggestion as this point is to completely remove k>2400 from all files and make sure all k<2400 pairs have been processed. To do this, we'll need to delete all k>2400 from primes.txt, knpairs.txt, joblist.txt, results.txt, and any other straggling file that they might be in and then restart the server. If you have a better suggestion, I'm all ears.

To all (namely Bruce),

I am shutting down port 7000 until we can get the mess straightened out.


Gary

[mdettweiler]

Originally Posted by gd_barnes

Max,

Major problems on port 7000. The k/n pairs are processing with the k and n-values reversed. Likely there is a rogue carriage control character on one of the pairs. This will probably be a huge mess to straigten out. Please see what you can do. You may need to go back a couple of days in the results.


To all (namely Bruce),

I am shutting down port 7000 until we can get the mess straightened out.


Gary

Yowch, I just noticed this too. The whole knpairs.txt file is scrambled. However, Gary, do NOT shut down the server--that is rather difficult due to the loop thingy I have on the server. I'll have to do that according to a very specific procedure.

[mdettweiler]

Wow...this is weird. When I shut down and restarted the VNC server as part of the process of shutting down G7000, it seems that the VNC server doesn't want to give me any taskbars on its session. Gary, since that doesn't seem to be working right, I've started the servers up on the console session for now. That should work fine in the meantime; the only difference is that the VNC connection to the console session is a tad more sluggish than the main VNC session due to the extra visual effects.

[gd_barnes]

Originally Posted by mdettweiler

Yowch, I just noticed this too. The whole knpairs.txt file is scrambled. However, Gary, do NOT shut down the server--that is rather difficult due to the loop thingy I have on the server. I'll have to do that according to a very specific procedure.

OK, I didn't shut it down.

See the edit in my above post. The problem happens only every other k-value and it is continuing right up to this moment. How could a carriage control get messed up on each change in k-value? Did you do an unusual sorting routine? My take is that there is a missing or extra carriage control whenever there is a change in k. That causes it to go from the correct order to the incorrect order and back again.

One more thing: We need to somehow back off all k>2400 results and primes from the NPLB DB counts and scores. The teeny primes will skew those big time. (Well, maybe not the scores but it will the counts.)


Gary

[gd_barnes]

Originally Posted by mdettweiler

Wow...this is weird. When I shut down and restarted the VNC server as part of the process of shutting down G7000, it seems that the VNC server doesn't want to give me any taskbars on its session. Gary, since that doesn't seem to be working right, I've started the servers up on the console session for now. That should work fine in the meantime; the only difference is that the VNC connection to the console session is a tad more sluggish than the main VNC session due to the extra visual effects.

I assume you mean server; as in singular port 7000. I assume there's no reason to shut down more than just this one server.

Edit: Getting off now. I pulled an all-nighter getting the CRUS web pages updated. I still have more to go. Good luck!