mersenneforum.org

mersenneforum.org (https://www.mersenneforum.org/index.php)
-   No Prime Left Behind (https://www.mersenneforum.org/forumdisplay.php?f=82)
-   -   PRPnet servers for NPLB (https://www.mersenneforum.org/showthread.php?t=12224)

mdettweiler 2009-07-28 16:08

PRPnet servers for NPLB
 
The following is a list of all of NPLB's active PRPnet servers. The admins will keep this thread updated as often as possible. :smile:

A daily general report for all PRPnet servers is at [URL="http://www.noprimeleftbehind.net/prpnet"]www.noprimeleftbehind.net/prpnet[/URL].
An hourly/daily progress report for all NPLB servers is at [URL="http://www.noprimeleftbehind.net/stats/index.php?content=port"]www.noprimeleftbehind.net/stats/index.php?content=port[/URL].
[B]Currently processing ranges last updated 2020-01-01 08:00 GMT.[/B]

[B]NPLB PRPnet server #1:[/B]
Short identification: G1468
server = [URL="http://www.noprimeleftbehind.net"]www.noprimeleftbehind.net[/URL]
port = 1468
k's: 317/329/335/341/363/391/393/399 [B](8k mini-drive)[/B]
n-range: 1.575M-2M
currently processing at n= [COLOR=blue]Complete[/COLOR]
k's: 347/351/355/357/359/361/365/367/369/371/375/377/379/381/383/385/387 [B](17k maxi-drive)[/B]
n-range: 1.61M-2M
currently processing at [COLOR=deepskyblue][COLOR=black]n=[/COLOR] [COLOR=blue]Complete[/COLOR][/COLOR]
k-range: 300-350 [B](15th Drive)[/B]
n-range: 2M-3M
currently processing at n= [COLOR=blue]~2.71M[/COLOR]
server summary*: [URL="http://www.noprimeleftbehind.net:1468/all.html"]www.noprimeleftbehind.net:1468/all.html[/URL]

[B]NPLB PRPnet server #2[/B][B]:[/B]
Short identification: G9000
server: [URL="http://www.noprimeleftbehind.net"]www.noprimeleftbehind.net[/URL]
port: 9000
k-range: 400-600 [B](13th Drive)[/B]
n-range: 1M-1.02M, 1.025M-1.035M, 1.05M-1.7M
currently processing at n= [COLOR=#0000ff]~1.59M[/COLOR]
k-range: 800-1001 [B](7th Drive)[/B]
n-range: 790K-793K, 800K-810K, 820K-830K, 840K-870K, 880K-920K, 940K-950K, 960K-970K, 980K-995K, 998K-1M
currently processing at n= [COLOR=#0000ff](complete)[/COLOR]
server summary*: [URL="http://www.noprimeleftbehind.net:9000/all.html"]www.noprimeleftbehind.net:9000/all.html[/URL]

[B]NPLB PRPnet server #3:[/B]
Short identification: G2000
server: [URL="http://www.noprimeleftbehind.net"]www.noprimeleftbehind.net[/URL]
port: 2000
k-range: 600-1001 [B](14th Drive)[/B]
n-range: 1M-1.6M
currently processing at n= [COLOR=#0000ff]~1.55M[/COLOR]
server summary*: [URL="http://www.noprimeleftbehind.net:2000/all.html"]www.noprimeleftbehind.net:2000/all.html[/URL]


*The user and team scores given by the server's pages are calculated directly by the server, and may not match up with our official stats at [URL="http://www.noprimeleftbehind.net/"]www.noprimeleftbehind.net/[/URL]. This score is primarily useful for comparing different users on a specific server, and use a completely different formula for calculating score than what is used in the NPLB database. Therefore the scores are not equivalent to the database scores for primes and results.

gd_barnes 2009-08-03 09:07

Max,

You have used the following link suffix in 3 places:

[URL="http://nplb-gb1.no-ip.org:5000/server_stats.html"]server_stats.html[/URL]

Instead of this one:

[URL="http://nplb-gb1.no-ip.org:5000/server_status.html"]server_status.html[/URL]


Both of them were incorrect in the 1st post here and it was also incorrect over at CRUS. This is just a heads up. I've now corrected all 3 places.

I've also corrected the k-range in port 5000 from 3200-3400 to 3000-3400 per our email discussion.

I've now checked all of the related web pages. Everything was correct except for one thing: [URL]http://nplb-gb1.no-ip.org:2000/[/URL] is missing k=343, 359, 361, and 375. Can you please check into why those 4 k's are missing? If they have been omitted from the file that is loaded into the server, please add those k's to the server so that they aren't missed. If not, then a correction is needed with the interface from the server to that web page.


Thanks,
Gary

vaughan 2009-08-03 09:23

I get "Problem loading page" messages for all the port:5000 links in your post Max.
When is this machine coming on-line?

gd_barnes 2009-08-03 09:29

[quote=vaughan;183807]I get "Problem loading page" messages for all the port:5000 links in your post Max.
When is this machine coming on-line?[/quote]

See this statement above:

[B]NPLB PRPnet server #1 (updated 2009-08-03 09:00 GMT):
[COLOR=red]Note: Server is not online yet. Links below will not work until server is brought online.[/COLOR][/B]
maintained by mdettweiler on gd_barnes machine


We are having difficulting with testing over at CRUS. Although the PRPnet servers themselves seem to be working mostly correctly, interfaces to the web pages seem to be having some problems both there and here.

Max, if you can see what is causing the problem on port G2000 here with the 4 k's not being shown on the one web page, fix it, and then start up G2000 again to where the web page shows correctly, then I'm good with us starting on G5000. Please remember to load the file by k-value. n=50K-75K to start with should be a good stress test. I'll throw at least 3 quads on it to give it a good stress. It will be interesting to see if my servers can handle such a load for extremely fast tests.


Gary

vaughan 2009-08-03 09:48

[QUOTE=gd_barnes;183808]See this statement above:

[/QUOTE]
Is it days or weeks away?

Should I move my machines from IB:9000 and co at noprimeleftbehind.net to PRPnet?

BOINC Simap is out of work now so once my cached tasks are crunched and reported I'll be back to full strength. I noticed that my I7-920 (Win 7 64bit) is pretty quick at BOINC ABCatHome.

gd_barnes 2009-08-03 13:39

[quote=vaughan;183809]Is it days or weeks away?

Should I move my machines from IB:9000 and co at noprimeleftbehind.net to PRPnet?

BOINC Simap is out of work now so once my cached tasks are crunched and reported I'll be back to full strength. I noticed that my I7-920 (Win 7 64bit) is pretty quick at BOINC ABCatHome.[/quote]

It depends on what you want to do. IB9000 has some of the biggest top-5000 tests that we have. Only G8000 is higher for servers. I think you said you like those the best.

Unfortunately at this time, these are the only two PRPnet servers and have/will be running the smallest tests that we have and are not top-5000. We're still in a testing and transition phase yet. G2000 that currently has work is double check. G5000 will be extremely small (n=50K-75K vs. 800K-900K in port IB9000) new tests and will take only a few seconds each to test. So you'll get to complete a lot of pairs and find a lot of small primes but their stats score here will be very small. :smile:

As for when G5000 will start up, I see it as 1-3 days away yet. Max is the one coordinating the running of the PRPnet servers so he could be more specific. I'm the checker and verifier of every little issue that I can find. I wanted to do the non-top-5000 and double-check work on the PRPnet servers until we defenitively have all of the smallest issues worked out. Then we'll begin transitioning perhaps 1-2 of our LLRnet servers at a time that are doing top-5000 tests to PRPnet servers as we get to nice round n-ranges.

Once G5000 starts up, we'll announce it here. In order to do a good stress test on it, we'll want lots of cores running it. I'll probably put several quads on it and if others can do the same, that would be a great stress test. The idea is to see how much load my servers and PRPnet can handle at the moment. With very fast tests, this will be a very big load as huge #'s of pairs are handed out and completed in short order.


Gary

mdettweiler 2009-08-03 13:45

[quote=gd_barnes;183806]Max,

You have used the following link suffix in 3 places:

[URL="http://nplb-gb1.no-ip.org:5000/server_stats.html"]server_stats.html[/URL]

Instead of this one:

[URL="http://nplb-gb1.no-ip.org:5000/server_status.html"]server_status.html[/URL]


Both of them were incorrect in the 1st post here and it was also incorrect over at CRUS. This is just a heads up. I've now corrected all 3 places.[/quote]
Whoops, thanks. :smile:

[quote]I've also corrected the k-range in port 5000 from 3200-3400 to 3000-3400 per our email discussion.[/quote]
Duh, should have remembered that one. :rolleyes: Thanks.

[quote]I've now checked all of the related web pages. Everything was correct except for one thing: [URL]http://nplb-gb1.no-ip.org:2000/[/URL] is missing k=343, 359, 361, and 375. Can you please check into why those 4 k's are missing? If they have been omitted from the file that is loaded into the server, please add those k's to the server so that they aren't missed. If not, then a correction is needed with the interface from the server to that web page.[/quote]
Hmm...did we originally leave those k's out of the first-pass 3rd Drive? Because I just used the original 3rd Drive sieve file for this.

gd_barnes 2009-08-03 13:57

[quote=mdettweiler;183843]Hmm...did we originally leave those k's out of the first-pass 3rd Drive? Because I just used the original 3rd Drive sieve file for this.[/quote]

Hum. That's very possible but we do need to double-check all of them. I'll have to investigate and get back with you late this afternoon.

In the mean time, can you check the file that is in G2000 to make sure none of those k's are there? If none are there, the web page interfaces appear to be completely correct for this particular testing and we can start G5000 at any time.

Once G5000 starts handing out pairs, can you do a quick spot check to make sure there are a full 195 k's listed on the appropriate web page interface? The file that I sent you should have all k's in there for k=3010-3400.

BTW, I goofed in two ways on the range for G5000. We're only testing k=3010-3400, not 3000-3400 since Lennart has done 3000-3010. Also, we're only doing n=50K-400K not 50K-425K. We're stopping at 400K because that is where the mini-drive started. When people reserve individual k's on the k=3200-3400 range, they'll just need to do a little non-top-5000 work, which would also be the case if we loaded n=50K-425K so we may as well be consistent with k=3010-3200. I've corrected that (once again) in the 1st post. Sheesh. lol

Just a friendly reminder to be sure and only initially load n=50K-75K and in k-value sequence. Thanks.


Gary

mdettweiler 2009-08-03 14:28

[quote=gd_barnes;183845]Hum. That's very possible but we do need to double-check all of them. I'll have to investigate and get back with you late this afternoon.

In the mean time, can you check the file that is in G2000 to make sure none of those k's are there? If none are there, the web page interfaces appear to be completely correct for this particular testing and we can start G5000 at any time.[/quote]
I've checked and it looks like all four of those k's were omitted from the file for n<500K. (Since the range we're doing right now in the server is 300K-350K, the k's don't have any incidence at all in the server.)

Per [url=http://www.mersenneforum.org/showthread.php?t=9995]this thread[/url], this is correct for the 3rd Drive. Nonetheless, yes, those k's should be doublechecked. However, we do have one problem: since we didn't originally test them the first time around, we don't have first-pass residuals for those k's. But, we really need to have two sets of residuals for each k/n pair in order to make a proper doublecheck. So here's what I'm proposing: we quickly re-do those k's to get "first-pass" residuals, then we add them to G2000 to be included in the doublecheck. We'll then end up with two residuals for each k/n pair, as needed.

[quote]Once G5000 starts handing out pairs, can you do a quick spot check to make sure there are a full 195 k's listed on the appropriate web page interface? The file that I sent you should have all k's in there for k=3010-3400.

BTW, I goofed in two ways on the range for G5000. We're only testing k=3010-3400, not 3000-3400 since Lennart has done 3000-3010. Also, we're only doing n=50K-400K not 50K-425K. We're stopping at 400K because that is where the mini-drive started. When people reserve individual k's on the k=3200-3400 range, they'll just need to do a little non-top-5000 work, which would also be the case if we loaded n=50K-425K so we may as well be consistent with k=3010-3200. I've corrected that (once again) in the 1st post. Sheesh. lol

Just a friendly reminder to be sure and only initially load n=50K-75K and in k-value sequence. Thanks.[/quote]
Okay, sounds good. I'll get the sieve file prepped and loaded as soon as possible, hopefully today.

gd_barnes 2009-08-04 03:27

[quote=mdettweiler;183847]I've checked and it looks like all four of those k's were omitted from the file for n<500K. (Since the range we're doing right now in the server is 300K-350K, the k's don't have any incidence at all in the server.)

Per [URL="http://www.mersenneforum.org/showthread.php?t=9995"]this thread[/URL], this is correct for the 3rd Drive. Nonetheless, yes, those k's should be doublechecked. However, we do have one problem: since we didn't originally test them the first time around, we don't have first-pass residuals for those k's. But, we really need to have two sets of residuals for each k/n pair in order to make a proper doublecheck. So here's what I'm proposing: we quickly re-do those k's to get "first-pass" residuals, then we add them to G2000 to be included in the doublecheck. We'll then end up with two residuals for each k/n pair, as needed.


Okay, sounds good. I'll get the sieve file prepped and loaded as soon as possible, hopefully today.[/quote]


Ah, good. That's nice to hear that there's no interface problem. We're good to go on G5000.

Actually yes, we do have first pass residuals. You might remember that as the k=300-1001 range was nearing n=600K, I followed up the tail end by double checking other's efforts, finding one missing prime in the process, something that I'll also do as the 11th drive nears n=650K. I did it manually but still have the results saved off and available.

So, when you get a chance, can you load k=343, 359, 361, and 375 for n=300K-350K into port G2000? Assuming that this particular server naturally hands them out by size instead of entry order or k-value, then they should be handed out first up until we get to the current n=~330K depth. That would be a good thing.

That's nice to know that those interfacing web pages alert us to such things like that before they become bigger issues. Cool! :-)


Gary

mdettweiler 2009-08-04 03:52

[quote=gd_barnes;183936]Ah, good. That's nice to hear that there's no interface problem. We're good to go on G5000.

Actually yes, we do have first pass residuals. You might remember that as the k=300-1001 range was nearing n=600K, I followed up the tail end by double checking other's efforts, finding one missing prime in the process, something that I'll also do as the 11th drive nears n=650K. I did it manually but still have the results saved off and available.

So, when you get a chance, can you load k=343, 359, 361, and 375 for n=300K-350K into port G2000? Assuming that this particular server naturally hands them out by size instead of entry order or k-value, then they should be handed out first up until we get to the current n=~330K depth. That would be a good thing.

That's nice to know that those interfacing web pages alert us to such things like that before they become bigger issues. Cool! :-)


Gary[/quote]
Okay, sounds good. However, it seems that I don't have the 260K-600K sieve file for those four k's; I only have the sieve file for the 3rd Drive. Could you send me the part that I'm missing?

Thanks,
Max :smile:

vaughan 2009-08-05 10:16

Both sets of "user stats" in Post #1 in this thread end up with a blank screen and the URL changes to about:blank

methinks the server is not worky

gd_barnes 2009-08-05 11:16

Only the port G5000 links are not working because it is offline as shown in the 1st posting here. i.e.:

[B][quote][/B]
[B]NPLB PRPnet server #1 (updated 2009-08-03 09:00 GMT):
[COLOR=red]Note: Server is not online yet. Links below will not work until server is brought online.[/COLOR][/B]
[/quote]

We're still fighting some issues with a PRPnet server over at CRUS (Conjectures 'R Us) before bringing it online.

The port G2000 links are working so the server should be working. Let us know if you experience problems connecting to it.


Gary

mdettweiler 2009-08-05 12:42

[quote=gd_barnes;184192]Only the port G5000 links are not working because it is offline as shown in the 1st posting here. i.e.:

[b]

We're still fighting some issues with a PRPnet server over at CRUS (Conjectures 'R Us) before bringing it online.

The port G2000 links are working so the server should be working. Let us know if you experience problems connecting to it.


Gary[/quote]
As Gary said--G5000 isn't online yet, so its links won't work. However, G2000's are working fine for me; note that these pages are generated on the fly and often take a few seconds to load. Wait for them, and that big blank page will turn into the requested info. :smile:

vaughan 2009-08-06 13:50

Very strange, the :2000 stats wouldn't work for me about this time last night from Melbourne but just now worked fine for me in Sydney.

Edited by MyDog: Solution - Stay in Sydney LOL

Zachariassen 2009-08-07 09:08

..and suddenly I got work from the G3000 !!!! - server...
Is the G2000 down ?

Whatever the reason was - the G2000-server is working now...

vaughan 2009-08-07 11:59

@Zach: thanks for the hint, I'll check out port 3k.

@MyDog: nice travel tip but Melbourne is head office so I cannot avoid it.

Zachariassen 2009-08-07 13:52

[quote=vaughan;184431]@Zach: thanks for the hint, I'll check out port 3k.[/quote]

[URL]http://nplb-gb1.no-ip.org:3000/user_stats.html[/URL]

Well - the user stats shows that we are doing some work at the G3000-server from time to time...

But... we have a long way to go before we can compete against the 'top guys' :razz: - I don't even know what those big numbers are ... billions... trillions... fantasillions ????

Edited MyDog: Or maybe crunch-illions

rogue 2009-08-07 14:28

[QUOTE=Zachariassen;184447][URL]http://nplb-gb1.no-ip.org:3000/user_stats.html[/URL]

Well - the user stats shows that we are doing some work at the G3000-server from time to time...

But... we have a long way to go before we can compete against the 'top guys' :razz: - I don't even know what those big numbers are ... billions... trillions... fantasillions ????

Edited MyDog: Or maybe crunch-illions[/QUOTE]

I cannot view the stats from work (the port is blocked), but if any of them were generated from the 2.1.2 (or older) server, then the large ones are most likely garbage. I fixed an issue in 2.1.3 where scores were calculated incorrectly. The user stats are persistent, in other words, they are not calculated on the fly like the server stats.

mdettweiler 2009-08-07 14:40

[quote=rogue;184452]I cannot view the stats from work (the port is blocked), but if any of them were generated from the 2.1.2 (or older) server, then the large ones are most likely garbage. I fixed an issue in 2.1.3 where scores were calculated incorrectly. The user stats are persistent, in other words, they are not calculated on the fly like the server stats.[/quote]
Hmm, I see. Well, I'm pretty sure that most of that data was picked up on 2.2.x versions, so we should be good on that count. :smile: I have noticed, however, that PRPnet scores in general tend to balloon to very big numbers if you put a lot of crunching onto one server; see my personal server at [URL]http://nplb-gb1.no-ip.org:1864/user_stats.html[/URL] for an example of this. Note that this server, AFAIR, never ran a version lower than 2.2.1. Edit: Note also that this server's done a bunch of big base 12 numbers, so that huge score isn't quite as abnormal as it would otherwise look. :smile:

rogue 2009-08-07 21:45

The scores are definitely wacko, but I don't know why at this time. If you want, you can recalculate them by taking averages of the other users and multiplying out by the number of tests. I wonder if it somehow miscalculated the decimal length of some numbers, because I think that is about the only way they can get whacked.

vaughan 2009-08-09 21:37

prperror message
 
AppName: prpclient AppVer: 0.0.0.0 ModName: prpclient.exe
ModVer: 0.0.0.0 Offset: 0001755f

<?xml version="1.0" encoding="UTF-16"?>
<DATABASE>
<EXE NAME="prpclient.exe" FILTER="GRABMI_FILTER_PRIVACY">
<MATCHING_FILE NAME="cllr.exe" SIZE="3956736" CHECKSUM="0xDFFF2752" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="02/01/2008 07:10:16" UPTO_LINK_DATE="02/01/2008 07:10:16" />
<MATCHING_FILE NAME="pfgw.exe" SIZE="5575680" CHECKSUM="0x70A557FB" MODULE_TYPE="WIN32" PE_CHECKSUM="0x55476C" LINKER_VERSION="0x0" LINK_DATE="07/25/2009 21:37:06" UPTO_LINK_DATE="07/25/2009 21:37:06" />
<MATCHING_FILE NAME="phrot.p3-mingw32.exe" SIZE="199168" CHECKSUM="0x5BD4CABD" MODULE_TYPE="WIN32" PE_CHECKSUM="0x3A182" LINKER_VERSION="0x10000" LINK_DATE="04/27/2009 10:31:32" UPTO_LINK_DATE="04/27/2009 10:31:32" />
<MATCHING_FILE NAME="prpclient.exe" SIZE="606208" CHECKSUM="0x68C7A1E4" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="07/17/2009 12:59:11" UPTO_LINK_DATE="07/17/2009 12:59:11" />
</EXE>
<EXE NAME="kernel32.dll" FILTER="GRABMI_FILTER_THISFILEONLY">
<MATCHING_FILE NAME="kernel32.dll" SIZE="989696" CHECKSUM="0x2D998938" BIN_FILE_VERSION="5.1.2600.5781" BIN_PRODUCT_VERSION="5.1.2600.5781" PRODUCT_VERSION="5.1.2600.5781" FILE_DESCRIPTION="Windows NT BASE API Client DLL" COMPANY_NAME="Microsoft Corporation" PRODUCT_NAME="Microsoft® Windows® Operating System" FILE_VERSION="5.1.2600.5781 (xpsp_sp3_gdr.090321-1317)" ORIGINAL_FILENAME="kernel32" INTERNAL_NAME="kernel32" LEGAL_COPYRIGHT="© Microsoft Corporation. All rights reserved." VERFILEDATEHI="0x0" VERFILEDATELO="0x0" VERFILEOS="0x40004" VERFILETYPE="0x2" MODULE_TYPE="WIN32" PE_CHECKSUM="0xFE572" LINKER_VERSION="0x50001" UPTO_BIN_FILE_VERSION="5.1.2600.5781" UPTO_BIN_PRODUCT_VERSION="5.1.2600.5781" LINK_DATE="03/21/2009 14:06:58" UPTO_LINK_DATE="03/21/2009 14:06:58" VER_LANGUAGE="English (United States) [0x409]" />
</EXE>
</DATABASE>

mdettweiler 2009-08-09 21:50

[quote=vaughan;184756]AppName: prpclient AppVer: 0.0.0.0 ModName: prpclient.exe
ModVer: 0.0.0.0 Offset: 0001755f

<snip>[/quote]
Where did you see this message? In the console window? In a dialog box?

rogue 2009-08-09 22:29

[QUOTE=vaughan;184756]AppName: prpclient AppVer: 0.0.0.0 ModName: prpclient.exe
ModVer: 0.0.0.0 Offset: 0001755f

<?xml version="1.0" encoding="UTF-16"?>
<DATABASE>
<EXE NAME="prpclient.exe" FILTER="GRABMI_FILTER_PRIVACY">
<MATCHING_FILE NAME="cllr.exe" SIZE="3956736" CHECKSUM="0xDFFF2752" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="02/01/2008 07:10:16" UPTO_LINK_DATE="02/01/2008 07:10:16" />
<MATCHING_FILE NAME="pfgw.exe" SIZE="5575680" CHECKSUM="0x70A557FB" MODULE_TYPE="WIN32" PE_CHECKSUM="0x55476C" LINKER_VERSION="0x0" LINK_DATE="07/25/2009 21:37:06" UPTO_LINK_DATE="07/25/2009 21:37:06" />
<MATCHING_FILE NAME="phrot.p3-mingw32.exe" SIZE="199168" CHECKSUM="0x5BD4CABD" MODULE_TYPE="WIN32" PE_CHECKSUM="0x3A182" LINKER_VERSION="0x10000" LINK_DATE="04/27/2009 10:31:32" UPTO_LINK_DATE="04/27/2009 10:31:32" />
<MATCHING_FILE NAME="prpclient.exe" SIZE="606208" CHECKSUM="0x68C7A1E4" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="07/17/2009 12:59:11" UPTO_LINK_DATE="07/17/2009 12:59:11" />
</EXE>
<EXE NAME="kernel32.dll" FILTER="GRABMI_FILTER_THISFILEONLY">
<MATCHING_FILE NAME="kernel32.dll" SIZE="989696" CHECKSUM="0x2D998938" BIN_FILE_VERSION="5.1.2600.5781" BIN_PRODUCT_VERSION="5.1.2600.5781" PRODUCT_VERSION="5.1.2600.5781" FILE_DESCRIPTION="Windows NT BASE API Client DLL" COMPANY_NAME="Microsoft Corporation" PRODUCT_NAME="Microsoft® Windows® Operating System" FILE_VERSION="5.1.2600.5781 (xpsp_sp3_gdr.090321-1317)" ORIGINAL_FILENAME="kernel32" INTERNAL_NAME="kernel32" LEGAL_COPYRIGHT="© Microsoft Corporation. All rights reserved." VERFILEDATEHI="0x0" VERFILEDATELO="0x0" VERFILEOS="0x40004" VERFILETYPE="0x2" MODULE_TYPE="WIN32" PE_CHECKSUM="0xFE572" LINKER_VERSION="0x50001" UPTO_BIN_FILE_VERSION="5.1.2600.5781" UPTO_BIN_PRODUCT_VERSION="5.1.2600.5781" LINK_DATE="03/21/2009 14:06:58" UPTO_LINK_DATE="03/21/2009 14:06:58" VER_LANGUAGE="English (United States) [0x409]" />
</EXE>
</DATABASE>[/QUOTE]

???

vaughan 2009-08-09 22:55

[QUOTE=mdettweiler;184757]Where did you see this message? In the console window? In a dialog box?[/QUOTE]

A "standard" Windows XP Pro 32bit error reporting message popped up. I copied and posted the contents of the error file [appcompat.txt] for someone with the knowledge to diagnose the issue. I reported the error to M$.

EDIT:
This is the last line of the prplient.log file:

[2009-08-09 16:43:47 GMT] G2000: ERROR: Test for 391*2^331845-1 rejected. No residue reported

rogue 2009-08-10 00:08

[QUOTE=vaughan;184765]A "standard" Windows XP Pro 32bit error reporting message popped up. I copied and posted the contents of the error file [appcompat.txt] for someone with the knowledge to diagnose the issue. I reported the error to M$.

EDIT:
This is the last line of the prplient.log file:

[2009-08-09 16:43:47 GMT] G2000: ERROR: Test for 391*2^331845-1 rejected. No residue reported[/QUOTE]

It sounds like a potential memory leak, but I don't think that there is enough information for me to investigate. I'll look, but I make no promises. Can you supply the previous hundred or so lines from the log?

vaughan 2009-08-10 03:38

[2009-08-09 14:30:08 GMT] Total Time: 21:44:50 Total Tests: 519 Total PRPs Found: 0
[2009-08-09 14:30:08 GMT] G2000: Returning work to server nplb-gb1.no-ip.org at port 2000
[2009-08-09 14:30:11 GMT] G2000: INFO: Test for candidate 383*2^330956-1 accepted
[2009-08-09 14:30:12 GMT] G2000: INFO: Test for candidate 349*2^331823-1 accepted
[2009-08-09 14:30:14 GMT] G2000: INFO: Test for candidate 369*2^331823-1 accepted
[2009-08-09 14:30:15 GMT] G2000: INFO: Test for candidate 367*2^331825-1 accepted
[2009-08-09 14:30:16 GMT] G2000: INFO: Test for candidate 301*2^331829-1 accepted
[2009-08-09 14:30:17 GMT] G2000: INFO: Test for candidate 315*2^331828-1 accepted
[2009-08-09 14:30:19 GMT] G2000: INFO: Test for candidate 319*2^331829-1 accepted
[2009-08-09 14:30:20 GMT] G2000: INFO: Test for candidate 313*2^331827-1 accepted
[2009-08-09 14:30:21 GMT] G2000: INFO: Test for candidate 387*2^331828-1 accepted
[2009-08-09 14:30:22 GMT] G2000: INFO: Test for candidate 357*2^331828-1 accepted
[2009-08-09 14:30:23 GMT] G2000: INFO: All 10 test results were accepted
[2009-08-09 14:30:44 GMT] nplb-gb1.no-ip.org:5000 connect to socket failed
[2009-08-09 14:30:44 GMT] G3000: Getting work from server nplb-gb1.no-ip.org at port 3000
[2009-08-09 14:30:49 GMT] G3000: No active candidates found on server
[2009-08-09 14:31:10 GMT] nplb-gb1.no-ip.org:5000 connect to socket failed
[2009-08-09 14:31:11 GMT] G2000: Getting work from server nplb-gb1.no-ip.org at port 2000
[2009-08-09 14:33:17 GMT] G2000: 391*2^331827-1 is not prime. Residue F95BCAC394FE5444
[2009-08-09 14:35:20 GMT] G2000: 393*2^331826-1 is not prime. Residue 2BAF32BB0A4F4272
[2009-08-09 14:37:23 GMT] G2000: 393*2^331828-1 is not prime. Residue 67EC3F1D1554AB85
[2009-08-09 14:39:27 GMT] G2000: 317*2^331830-1 is not prime. Residue 20364812DC97B746
[2009-08-09 14:41:29 GMT] G2000: 381*2^331829-1 is not prime. Residue 05A8760D85239313
[2009-08-09 14:43:32 GMT] G2000: 369*2^331832-1 is not prime. Residue FAFD3C634E1D07B4
[2009-08-09 14:45:35 GMT] G2000: 391*2^331829-1 is not prime. Residue 0723ABE5C5109F90
[2009-08-09 14:47:38 GMT] G2000: 311*2^331834-1 is not prime. Residue 5C83C6DE26193723
[2009-08-09 14:49:42 GMT] G2000: 339*2^331835-1 is not prime. Residue 4F36E1689E31B5BD
[2009-08-09 14:51:46 GMT] G2000: 355*2^331833-1 is not prime. Residue 1BEEA7FA6A0EB47A
[2009-08-09 14:51:46 GMT] Total Time: 22:06:28 Total Tests: 529 Total PRPs Found: 0
[2009-08-09 14:51:46 GMT] G2000: Returning work to server nplb-gb1.no-ip.org at port 2000
[2009-08-09 14:51:47 GMT] G2000: INFO: Test for candidate 391*2^331827-1 accepted
[2009-08-09 14:51:49 GMT] G2000: INFO: Test for candidate 393*2^331826-1 accepted
[2009-08-09 14:51:50 GMT] G2000: INFO: Test for candidate 393*2^331828-1 accepted
[2009-08-09 14:51:51 GMT] G2000: INFO: Test for candidate 317*2^331830-1 accepted
[2009-08-09 14:51:52 GMT] G2000: INFO: Test for candidate 381*2^331829-1 accepted
[2009-08-09 14:51:53 GMT] G2000: INFO: Test for candidate 369*2^331832-1 accepted
[2009-08-09 14:51:55 GMT] G2000: INFO: Test for candidate 391*2^331829-1 accepted
[2009-08-09 14:51:56 GMT] G2000: INFO: Test for candidate 311*2^331834-1 accepted
[2009-08-09 14:51:57 GMT] G2000: INFO: Test for candidate 339*2^331835-1 accepted
[2009-08-09 14:51:58 GMT] G2000: INFO: Test for candidate 355*2^331833-1 accepted
[2009-08-09 14:51:59 GMT] G2000: INFO: All 10 test results were accepted
[2009-08-09 14:52:20 GMT] nplb-gb1.no-ip.org:5000 connect to socket failed
[2009-08-09 14:52:20 GMT] G3000: Getting work from server nplb-gb1.no-ip.org at port 3000
[2009-08-09 14:52:24 GMT] G3000: No active candidates found on server
[2009-08-09 14:52:45 GMT] nplb-gb1.no-ip.org:5000 connect to socket failed
[2009-08-09 14:52:45 GMT] G2000: Getting work from server nplb-gb1.no-ip.org at port 2000
[2009-08-09 14:54:55 GMT] G2000: 369*2^331835-1 is not prime. Residue FF3E7C3822B497AA
[2009-08-09 14:56:59 GMT] G2000: 393*2^331834-1 is not prime. Residue D1E109E6EDD9AD7F
[2009-08-09 14:59:02 GMT] G2000: 397*2^331833-1 is not prime. Residue 380F4B61A220F62D
[2009-08-09 15:01:07 GMT] G2000: 321*2^331837-1 is not prime. Residue E5040570E1C2708B
[2009-08-09 15:03:11 GMT] G2000: 369*2^331836-1 is not prime. Residue 13DA51DF7E506CCE
[2009-08-09 15:05:16 GMT] G2000: 395*2^331836-1 is not prime. Residue 4F3A1E3FFBBB317E
[2009-08-09 15:07:20 GMT] G2000: 303*2^331842-1 is not prime. Residue 2557EF6023D840E1
[2009-08-09 15:09:25 GMT] G2000: 319*2^331841-1 is not prime. Residue 81BEB2B6818E4CAC
[2009-08-09 15:11:30 GMT] G2000: 357*2^331840-1 is not prime. Residue A770DC121365D833
[2009-08-09 15:13:34 GMT] G2000: 399*2^331841-1 is not prime. Residue 4C7E1995F9BE22D0
[2009-08-09 15:13:34 GMT] Total Time: 22:28:16 Total Tests: 539 Total PRPs Found: 0
[2009-08-09 15:13:35 GMT] G2000: Returning work to server nplb-gb1.no-ip.org at port 2000
[2009-08-09 15:13:38 GMT] G2000: INFO: Test for candidate 369*2^331835-1 accepted
[2009-08-09 15:13:39 GMT] G2000: INFO: Test for candidate 393*2^331834-1 accepted
[2009-08-09 15:13:41 GMT] G2000: INFO: Test for candidate 397*2^331833-1 accepted
[2009-08-09 15:13:42 GMT] G2000: INFO: Test for candidate 321*2^331837-1 accepted
[2009-08-09 15:13:43 GMT] G2000: INFO: Test for candidate 369*2^331836-1 accepted
[2009-08-09 15:13:44 GMT] G2000: INFO: Test for candidate 395*2^331836-1 accepted
[2009-08-09 15:13:45 GMT] G2000: INFO: Test for candidate 303*2^331842-1 accepted
[2009-08-09 15:13:47 GMT] G2000: INFO: Test for candidate 319*2^331841-1 accepted
[2009-08-09 15:13:48 GMT] G2000: INFO: Test for candidate 357*2^331840-1 accepted
[2009-08-09 15:13:49 GMT] G2000: INFO: Test for candidate 399*2^331841-1 accepted
[2009-08-09 15:13:50 GMT] G2000: INFO: All 10 test results were accepted
[2009-08-09 15:14:11 GMT] nplb-gb1.no-ip.org:5000 connect to socket failed
[2009-08-09 15:14:11 GMT] G3000: Getting work from server nplb-gb1.no-ip.org at port 3000
[2009-08-09 15:14:15 GMT] G3000: No active candidates found on server
[2009-08-09 15:14:36 GMT] nplb-gb1.no-ip.org:5000 connect to socket failed
[2009-08-09 15:14:36 GMT] G2000: Getting work from server nplb-gb1.no-ip.org at port 2000
[2009-08-09 15:16:45 GMT] G2000: 395*2^331840-1 is not prime. Residue 226B2DF526FBF188
[2009-08-09 15:18:49 GMT] G2000: 327*2^331845-1 is not prime. Residue B8D045C31A297474
[2009-08-09 15:20:52 GMT] G2000: 309*2^331844-1 is not prime. Residue 717BB482862049F3
[2009-08-09 15:22:56 GMT] G2000: 349*2^331845-1 is not prime. Residue 925B8371F61CD2BB
[2009-08-09 15:25:01 GMT] G2000: 369*2^331843-1 is not prime. Residue EEF79002BEAE3D82
[2009-08-09 16:41:47 GMT] G2000: 367*2^331845-1 is not prime. Residue A55BF5921B33C9A7
[2009-08-09 16:41:53 GMT] Total Time: 23:56:30 Total Tests: 545 Total PRPs Found: 0
[2009-08-09 16:42:03 GMT] G2000: Returning work to server nplb-gb1.no-ip.org at port 2000
[2009-08-09 16:42:20 GMT] G2000: INFO: Test for candidate 395*2^331840-1 accepted
[2009-08-09 16:42:39 GMT] G2000: INFO: Test for candidate 327*2^331845-1 accepted
[2009-08-09 16:42:55 GMT] G2000: INFO: Test for candidate 309*2^331844-1 accepted
[2009-08-09 16:43:05 GMT] G2000: INFO: Test for candidate 349*2^331845-1 accepted
[2009-08-09 16:43:21 GMT] G2000: INFO: Test for candidate 369*2^331843-1 accepted
[2009-08-09 16:43:31 GMT] G2000: INFO: Test for candidate 367*2^331845-1 accepted
[B][2009-08-09 16:43:47 GMT] G2000: ERROR: Test for 391*2^331845-1 rejected. No residue reported[/B]
[2009-08-09 23:01:36 GMT] PRPNet Client application v2.2.3 started
[2009-08-09 23:01:36 GMT] User name vaughan at email address is vaughan@my-email-address
[2009-08-09 23:03:55 GMT] G2000: 391*2^331845-1 is not prime. Residue 5A2D91A0D6CFB625
[2009-08-09 23:06:15 GMT] G2000: 311*2^331846-1 is not prime. Residue 53D15E503782C0D9
[2009-08-09 23:08:34 GMT] G2000: 315*2^331847-1 is not prime. Residue 6D5CC5DD21E50EE3
[2009-08-09 23:10:53 GMT] G2000: 317*2^331846-1 is not prime. Residue 1457E9DD13960EBA
[2009-08-09 23:10:53 GMT] Total Time: 0:09:17 Total Tests: 4 Total PRPs Found: 0
[2009-08-09 23:10:54 GMT] G2000: Returning work to server nplb-gb1.no-ip.org at port 2000
[2009-08-09 23:10:58 GMT] G2000: ERROR: Workunit 395*2^331840-1 not found on server
[2009-08-09 23:10:58 GMT] G2000: The client will delete this workunit
[2009-08-09 23:10:58 GMT] G2000: ERROR: Workunit 327*2^331845-1 not found on server
[2009-08-09 23:10:58 GMT] G2000: The client will delete this workunit
[2009-08-09 23:10:58 GMT] G2000: ERROR: Workunit 309*2^331844-1 not found on server
[2009-08-09 23:10:58 GMT] G2000: The client will delete this workunit
[2009-08-09 23:10:58 GMT] G2000: ERROR: Workunit 349*2^331845-1 not found on server
[2009-08-09 23:10:58 GMT] G2000: The client will delete this workunit
[2009-08-09 23:10:59 GMT] G2000: ERROR: Workunit 369*2^331843-1 not found on server
[2009-08-09 23:10:59 GMT] G2000: The client will delete this workunit
[2009-08-09 23:10:59 GMT] G2000: ERROR: Workunit 367*2^331845-1 not found on server
[2009-08-09 23:10:59 GMT] G2000: The client will delete this workunit
[2009-08-09 23:11:00 GMT] G2000: INFO: Test for candidate 391*2^331845-1 accepted
[2009-08-09 23:11:01 GMT] G2000: INFO: Test for candidate 311*2^331846-1 accepted
[2009-08-09 23:11:02 GMT] G2000: INFO: Test for candidate 315*2^331847-1 accepted

kar_bon 2009-08-10 09:12

if not aware:

[2009-08-09 16:43:47 GMT] G2000: ERROR: Test for [b]391*2^331845-1[/b] rejected. No residue reported
[2009-08-09 23:01:36 GMT] PRPNet Client application v2.2.3 started
[2009-08-09 23:01:36 GMT] User name vaughan at email address is vaughan@my-email-address
[2009-08-09 23:03:55 GMT] G2000: [b]391*2^331845-1[/b] is not prime. Residue 5A2D91A0D6CFB625

the pair with no reported residue is 3 lines down when the client was started about 6 hours later!

and about 7 minutes! later:

[2009-08-09 23:11:00 GMT] G2000: INFO: Test for candidate [b]391*2^331845-1[/b] accepted

vaughan 2009-08-10 11:41

Yes that's correct Kar_bon but it doesn't explain why the app triggered a Windows error event.

rogue 2009-08-10 12:42

Who is running the server? What does the server log have in it?

mdettweiler 2009-08-10 12:46

[quote=rogue;184817]Who is running the server? What does the server log have in it?[/quote]
I don't have time right now, but I'll post a log within the next couple of hours.

gd_barnes 2009-08-10 19:19

[quote=rogue;184817]Who is running the server? What does the server log have in it?[/quote]

Rogue, the servers are on my machine. Can you tell me what file to post to give you this info.? Or what part of what file? If so, I may be able to help.

I'll be offline for a bit to eat and then should be back on in 30 mins. or so.


Gary

rogue 2009-08-10 20:52

[QUOTE=gd_barnes;184858]Rogue, the servers are on my machine. Can you tell me what file to post to give you this info.? Or what part of what file? If so, I may be able to help.

I'll be offline for a bit to eat and then should be back on in 30 mins. or so.

Gary[/QUOTE]

I need the prpserver.log file that shows the communication back to the client at that time. The terminal output from the server would be even more helpful.

I actually think that I found a problem, maybe not the problem, but a problem related to this bug. I'll patch it tomorrow.

mdettweiler 2009-08-10 21:40

1 Attachment(s)
[quote=rogue;184867]I need the prpserver.log file that shows the communication back to the client at that time. The terminal output from the server would be even more helpful.

I actually think that I found a problem, maybe not the problem, but a problem related to this bug. I'll patch it tomorrow.[/quote]
Okay, here's the prpserver.log file from 2009-08-09 00:00 GMT until now. I don't have this server on debug logging so I can't give you the terminal output, but hopefully this will do the trick. :smile:

gd_barnes 2009-08-13 04:18

After discussion with Max and Ian, we have decided to delay the implementation of PRPnet at NPLB by 3-6 months or more due to stability issues as more clients are added to the server.

Testing at CRUS revealed that multi-threading is needed and that storing the file in memory and updating from there works OK for a limited # of clients but not as more clients are added. If you have technical questions related to that, Max and/or Ian can give more details.

PRPnet is still excellent for small efforts and the "BOINC-like" quality that it has that allows you to dictate what percentage of your machine(s) run what efforts on different servers is excellent!

If you understand the general setup, I recommend a personal PRPnet server for most people but I would not suggest running more than about 10 cores on each server that you use at any one time at the current approximate median level of n-ranges for our project (n=~450K-850K). The max # of cores that it can handle should vary with the length of time that each test takes. Therefore, the base 5 project may be able to run most of their project on PRPnet because their tests are so long. It PRPnet is still not fully ready by the time we're ready to start k=300-400 for n=1M-2M (I'd like to shoot for Nov. on that after we are hopefully complete to n=1M on that range), we may consider a somewhat limited-use public server for these long tests.

For the time being, we will not use port G5000 for the small tests as originally planned so I will/have removed it from the 1st post here. Such short tests could possibly cause problems with as few as 5 clients.

Over the next few days, I will have Max set up a server on one of my machines to start processing the non-top-5000 ranges of k=2000-3400. Shortly after that, I'll create a thread officially starting the effort. For those of you who don't like to mess with reporting primes either at top-5000 or here (admins take care of tracking all non-top-5000 primes) but would like to help us get some ranges filled in, I would suggest that effort for you.


Gary

gd_barnes 2009-08-13 04:22

Max and Mark,

The link [URL]http://nplb-gb1.no-ip.org:2000/server_status.html[/URL] doesn't seem to be working. It comes up but nothing shows on the page.


Gary

mdettweiler 2009-08-13 04:45

[quote=gd_barnes;185229]Max and Mark,

The link [URL]http://nplb-gb1.no-ip.org:2000/server_status.html[/URL] doesn't seem to be working. It comes up but nothing shows on the page.


Gary[/quote]
Hmm, that's weird. All the other pages work, but this one doesn't work even when I tried restarting the server. Mark, do you know what might be causing this?

IronBits 2009-08-13 05:18

chmod 666 *.html :)

rogue 2009-08-13 12:45

[QUOTE=mdettweiler;185233]Hmm, that's weird. All the other pages work, but this one doesn't work even when I tried restarting the server. Mark, do you know what might be causing this?[/QUOTE]

Nope. Anything in the debug log?

mdettweiler 2009-08-13 14:17

[quote=rogue;185293]Nope. Anything in the debug log?[/quote]
I hadn't checked that. I'll go do that now...

BTW, I got a PM from Ian saying that in his experience, having that particular page blank out was a direct precursor to data being lost from the middle of the prpserver.candidates file. Sure enough, when I checked the server, it seems that there's a small hole in the file: it's supposed to be all of k=300-400 for n=300K-350K, but k=359 and k=361 are missing. If something did happen, though, it happened rather cleanly; no other k's, even the ones around them, seem to be affected (at least at a glance).

Okay, I just checked the server and it turns out I didn't have that one on debug logging. I've switched it on to debug logging now, though, so any future problems should be logged.

BTW, a brief look at the end of the non-debug log indicates that there's some barfing going on on G2000, too. I see entries saying "Rejected test on x due to no residue" and then immediately after that it accepts the result with the blank residue--just as I was seeing on G3000. If this problem could be fixed, then PRPnet would be at least stable enough to use for lower-volume sitatuations, even without being able to handle high-volume capacity without multithreading.

(It would probably be rather superfluous to provide the log for this barfing incident since it looks like the exact same thing that's happened a million times on G3000. :smile:)

rogue 2009-08-13 15:58

[QUOTE=mdettweiler;185308]BTW, a brief look at the end of the non-debug log indicates that there's some barfing going on on G2000, too. I see entries saying "Rejected test on x due to no residue" and then immediately after that it accepts the result with the blank residue--just as I was seeing on G3000. If this problem could be fixed, then PRPnet would be at least stable enough to use for lower-volume sitatuations, even without being able to handle high-volume capacity without multithreading.

(It would probably be rather superfluous to provide the log for this barfing incident since it looks like the exact same thing that's happened a million times on G3000. :smile:)[/QUOTE]

If you can e-mail me the relevant pieces of the client and server logs, I would appreciate it. It has been difficult following the various posts.

mdettweiler 2009-08-13 16:17

[quote=rogue;185319]If you can e-mail me the relevant pieces of the client and server logs, I would appreciate it. It has been difficult following the various posts.[/quote]
Which logs do you want me to send you? The ones sprinkled throughout the "PRPnet bugs" thread in the CRUS forum?

rogue 2009-08-13 22:29

[QUOTE=mdettweiler;185322]Which logs do you want me to send you? The ones sprinkled throughout the "PRPnet bugs" thread in the CRUS forum?[/QUOTE]

The ones relevant to the latest issue that you mentioned

mdettweiler 2009-08-13 22:44

[quote=rogue;185375]The ones relevant to the latest issue that you mentioned[/quote]
Oh, I see. I'm afraid I don't have much data on the problem with the server dropping candidates from its queue; the server in question didn't have debug logging enabled at the time.

I'll try to reproduce the bug locally, this time with debug logging. Hopefully that will give us a clue as to what's going on here.

gd_barnes 2009-08-13 22:55

Just click on the [URL]http://nplb-gb1.no-ip.org:2000/server_status.html[/URL] link. That will cause the problem! :smile:

Isn't that what you suspected might be causing it over at CRUS?

rogue 2009-08-13 23:41

[QUOTE=gd_barnes;185382]Just click on the [URL]http://nplb-gb1.no-ip.org:2000/server_status.html[/URL] link. That will cause the problem! :smile:

Isn't that what you suspected might be causing it over at CRUS?[/QUOTE]

I actually want to get rid of that page in the next release. It isn't overly useful.

mdettweiler 2009-08-14 01:12

[quote=gd_barnes;185382]Just click on the [URL]http://nplb-gb1.no-ip.org:2000/server_status.html[/URL] link. That will cause the problem! :smile:

Isn't that what you suspected might be causing it over at CRUS?[/quote]
Yes, I know, but I figured it would be better to do it locally rather than mess up the public server. :smile:

gd_barnes 2009-08-14 05:02

[quote=mdettweiler;185308]I hadn't checked that. I'll go do that now...

BTW, I got a PM from Ian saying that in his experience, having that particular page blank out was a direct precursor to data being lost from the middle of the prpserver.candidates file. Sure enough, when I checked the server, it seems that there's a small hole in the file: it's supposed to be all of k=300-400 for n=300K-350K, but k=359 and k=361 are missing. If something did happen, though, it happened rather cleanly; no other k's, even the ones around them, seem to be affected (at least at a glance).[/quote]


k=359 and 361 are k's that were not in the original sieve file in addition to k=343 and 375. I'll send you the original sieve files for those k's shortly to load in there.

So in this case, nothing is missing.

mdettweiler 2009-11-25 16:33

Hi all,

I am pleased to announce that our new PRPnet server for the 5th Drive, G3000, is up and running! :grin: It is replacing our IB4000 LLRnet server for this drive. To run it, go to our [url=http://www.mersenneforum.org/showthread.php?t=12223]PRPnet thread[/url] to download and set up the latest version of the client. The client packages there should be preconfigured with G3000 at 100% work proportion (though if you're upgrading from an older client you'll need to add G3000 to your prpclient.ini manually).

Note that as of now, we don't have this PRPnet server hooked up to the DB yet; Dave will need to add a little patch to throw out results with blank residues (which resulted from bugs in earlier PRPnet versions; even though they should be gone now, we still want to play it safe) before we can start importing results from G3000. However, the results will still be copied off daily to [URL]http://nplb-gb1.no-ip.org/llrnet/results/[/URL] in LLRnet format, so Ian, you can continue to process results for this the same way you did for LLRnet IB4000.

Have fun! :smile:

Max :smile:

mdettweiler 2009-11-25 20:27

Oh, one last thing I forgot to mention about the new G3000 server. Even though it's not yet hooked up to the DB, you'll still receive email notifications of primes found. That's because until we can get it set up with the DB, I have PRPnet's built-in prime notification system turned on. The notifications will look a tad different, but all the key information is still there. Of note, these notifications come from my email address, [EMAIL="max@noprimeleftbehind.net"]max@noprimeleftbehind.net[/EMAIL], instead of [EMAIL="no-reply@noprimeleftbehind.net"]no-reply@noprimeleftbehind.net[/EMAIL] like the DB ones do, so if you need to put the sending email address in your address book in order to ensure that a spam filter doesn't stop the notifications, make sure mine's in there as well.

gd_barnes 2009-12-01 03:11

Max has added a daily general status report web page for port 3000 at [URL]http://nplb-gb1.no-ip.org/prpnet/[/URL]. I've now added that link to the 1st post in this thread. The page will eventually have all NPLB PRPnet servers on it.

Max, I see that the page has not updated itself since 11:05 AM CST this morning. Is some more tweaking needed for that?

mdettweiler 2009-12-01 03:20

[quote=gd_barnes;197417]Max, I see that the page has not updated itself since 11:05 AM CST this morning. Is some more tweaking needed for that?[/quote]
Ah, whoops, I forgot to put it in the crontab, so it only ran when I started it manually. Thanks for the pointer--everything should be all set now.

gd_barnes 2009-12-02 19:55

Max,

The web page itself does not display the prime that Bruce found today. It's correct in the primes file but still shows "(none yet)" under primes found today on the page.


Gary

mdettweiler 2009-12-03 00:43

[quote=gd_barnes;197611]Max,

The web page itself does not display the prime that Bruce found today. It's correct in the primes file but still shows "(none yet)" under primes found today on the page.


Gary[/quote]
Actually, he didn't find that prime today. The reason why it shows it with a timestamp of 05:44:55 is because PRPnet gives all its times in GMT. I didn't go to the trouble of putting code in my converter script to change it to local time in the LLRnet-formatted output, because in the end, it doesn't end up making that much of a difference (we already have mixed timezones in the DB, with David's GMT-7 servers and your GMT-6 winter/GMT-5 summer servers). Essentially, this means that the timestamps on the PRPnet results files will always be off by 6 hours in the winter and 5 hours in the summer.

So, when you account for that, the prime was actually found at 23:44:55 last night--which was about 15 minutes before the daily copy-off. Hence, it is no longer listed on the main status page.

mdettweiler 2009-12-03 00:57

Hi all,

As of now, we have a new PRPnet server operational on nplb-gb1.no-ip.org port 7000, replacing the old LLRnet G7000 for the 12th Drive range.

Note that this server currently has its daily results copy-off disabled, so that the DB doesn't start importing data from it until we've cleaned up a wee bit of mess caused by some malfunctions on the old LLRnet G7000. This will be turned on as soon as Dave returns from his apparent hiatus and can get the DB stuff sorted out. :smile:

BTW, PRPnet G7000 isn't on the [URL]http://nplb-gb1.no-ip.org/prpnet/[/URL] page yet, but don't worry, I'll get it there later today.

Max :smile:

Brucifer 2009-12-03 08:38

Okay, currently have some systems running on G2000 and G7000 and stuff seems to be rolling along okay. :smile:

gd_barnes 2009-12-03 20:33

[quote=mdettweiler;197636]Hi all,

As of now, we have a new PRPnet server operational on nplb-gb1.no-ip.org port 7000, replacing the old LLRnet G7000 for the 12th Drive range.

Note that this server currently has its daily results copy-off disabled, so that the DB doesn't start importing data from it until we've cleaned up a wee bit of mess caused by some malfunctions on the old LLRnet G7000. This will be turned on as soon as Dave returns from his apparent hiatus and can get the DB stuff sorted out. :smile:

BTW, PRPnet G7000 isn't on the [URL]http://nplb-gb1.no-ip.org/prpnet/[/URL] page yet, but don't worry, I'll get it there later today.

Max :smile:[/quote]

Bump bump. It's tomorrow now. lol

Quick question: I notice that some of the pairs being returned show that the program used on PRPnet is LLR and others show that it is CLLR. What is the difference? Isn't CLLR the older version used by LLRnet that isn't as fast?

Also, in the new client care package for PRPnet version 2.4.6 that you sent me, as you know, you didn't send me LLR. So I just left the version that I already had in each of my folders. Is that the correct and most up-to-date version of LLR? I don't want to be using this CLLR program if it is slower and is the one used by LLRnet.

Since Bruce is now off of the 5th drive, I'll look to move some clients over there by tomorrow if I have an answer here.


Gary

henryzz 2009-12-03 20:44

[quote=gd_barnes;197710]Bump bump. It's tomorrow now. lol

Quick question: I notice that some of the pairs being returned show that the program used on PRPnet is LLR and others show that it is CLLR. What is the difference? Isn't CLLR the older version used by LLRnet that isn't as fast?

Also, in the new client care package for PRPnet version 2.4.6 that you sent me, as you know, you didn't send me LLR. So I just left the version that I already had in each of my folders. Is that the correct and most up-to-date version of LLR? I don't want to be using this CLLR program if it is slower and is the one used by LLRnet.

Since Bruce is now off of the 5th drive, I'll look to move some clients over there by tomorrow if I have an answer here.


Gary[/quote]
AFAIK CLLR is just a console version for windows so things like PRPnet can call it from the commandline(it is identical to the latest linux llr)

Mini-Geek 2009-12-03 20:49

[quote=henryzz;197715]AFAIK CLLR is just a console version for windows so things like PRPnet can call it from the commandline(it is identical to the latest linux llr)[/quote]
Yep, this is correct. On Windows, LLR's GUI version is llr.exe and the command line version is cllr.exe. Either one can outdated or not. LLRnet built in a now-outdated version of LLR/CLLR. Most likely the CLLR you've got is the newer version. Run cllr -v from the command line to check. (3.7.1c is the newest)

mdettweiler 2009-12-03 20:54

[quote=gd_barnes;197710]Bump bump. It's tomorrow now. lol[/quote]
Whoops--sorry about that. :smile: I'll do that shortly.

[quote]Quick question: I notice that some of the pairs being returned show that the program used on PRPnet is LLR and others show that it is CLLR. What is the difference? Isn't CLLR the older version used by LLRnet that isn't as fast?

Also, in the new client care package for PRPnet version 2.4.6 that you sent me, as you know, you didn't send me LLR. So I just left the version that I already had in each of my folders. Is that the correct and most up-to-date version of LLR? I don't want to be using this CLLR program if it is slower and is the one used by LLRnet.[/quote]
As Henry said, cllr is the Linux version of LLR compiled for Windows. That gives the option of using a command line interface on Windows instead of the the default GUI. This allows the program to be run by other programs, such as PRPnet, which wouldn't be able to manage the GUI version as easily. cllr is updated along with the regular LLR, and the version included with the Windows PRPnet client packages is 3.7.1c, the latest. The Linux version of LLR, which is just called "llr" (hence the different name in the PRPnet server logs), is the exact same thing as cllr, just that it's for Linux. The version you have of that is also the latest, 3.7.1c.

In fact, cllr was actually not even around back when version 3.5, the version LLRnet uses, was current. cllr was first produced for version 3.7.1b. As such, if you have any copy of cllr, it can't be any older than 3.7.1b, which is just as fast as 3.7.1c anyway.

Edit: Ah, I see Mini-Geek explained this too while I was writing my post. One correction, though: as I said above, cllr didn't even exist for any versions slower than the current one.

Brucifer 2009-12-04 18:31

G7000 hasn't been accepting stuff for a while................... can't get new work either.......

mdettweiler 2009-12-04 18:53

[quote=Brucifer;197788]G7000 hasn't been accepting stuff for a while................... can't get new work either.......[/quote]
Hmm...strange. The server was stuck in what appeared to be a repeating loop of "Nothing was received, therefore the socket was cloed [sic]" every few seconds. I don't have debug logging turned on for this server (the file would get really big, really fast, due to the high volume of traffic from pairs this small), and the standard log wasn't much help. All it showed was that somebody's client (or clients, it's hard to tell) connected at 16:53:07 GMT and thereafter kept inundating the server with incomplete connections that it (correctly) ditched.

Anyway, I've restarted the server now. Everything seems to be OK for now.

rogue 2009-12-04 19:09

[QUOTE=mdettweiler;197791]Hmm...strange. The server was stuck in what appeared to be a repeating loop of "Nothing was received, therefore the socket was cloed [sic]" every few seconds. I don't have debug logging turned on for this server (the file would get really big, really fast, due to the high volume of traffic from pairs this small), and the standard log wasn't much help. All it showed was that somebody's client (or clients, it's hard to tell) connected at 16:53:07 GMT and thereafter kept inundating the server with incomplete connections that it (correctly) ditched.

Anyway, I've restarted the server now. Everything seems to be OK for now.[/QUOTE]

I think I know how to solve the problem. Modify Socket::ListenForMessage() to this before returning:

b_IsSendBuffering = false;
m_Log->Debug(DEBUG_SOCKET, "Message coming on socket %d", i_Socket);
b_IsOpen = true;
b_IsReadBuffering = false;
return inet_ntoa(sin.sin_addr);

I suspect that the send buffering flag is set and is preventing the server from properly telling the client that it has established a connection. I gave this patch to Lennart and we haven't seen any new issues with it, or at least none have been reported.

mdettweiler 2009-12-04 21:20

[quote=rogue;197793]I think I know how to solve the problem. Modify Socket::ListenForMessage() to this before returning:

b_IsSendBuffering = false;
m_Log->Debug(DEBUG_SOCKET, "Message coming on socket %d", i_Socket);
b_IsOpen = true;
b_IsReadBuffering = false;
return inet_ntoa(sin.sin_addr);

I suspect that the send buffering flag is set and is preventing the server from properly telling the client that it has established a connection. I gave this patch to Lennart and we haven't seen any new issues with it, or at least none have been reported.[/quote]
Okay, I've applied the patch. Hopefully we won't see any more of this problem. :smile:

Brucifer 2009-12-05 20:04

Okay, G7000 is hanging up again so I'm pulling stuff off. Will work on my manual reservation stuff.

mdettweiler 2009-12-05 20:54

[quote=Brucifer;197932]Okay, G7000 is hanging up again so I'm pulling stuff off. Will work on my manual reservation stuff.[/quote]
I just checked the server and it looks fine. I also confirmed that Gary didn't restart it, so it seems whatever the problem was, it fixed itself. I'll take a look at the debug logs later and see if it was a different sort of problem.

Brucifer 2009-12-05 22:09

Was probably past the max point at where it could quickly handle connects so clients were having to wait............... ????? I say that as if it's working good again then it's because I pulled several cores off it so the load lightened a bit on it.

rogue 2009-12-05 22:51

[QUOTE=Brucifer;197939]Was probably past the max point at where it could quickly handle connects so clients were having to wait............... ????? I say that as if it's working good again then it's because I pulled several cores off it so the load lightened a bit on it.[/QUOTE]

I suggest that you up maxworkunits on your clients. That will also reduce the load on the server. Max should also up the maxworkunits on the server so that clients can do a lot more work between communications to the server.

Brucifer 2009-12-06 00:08

I've had mine at 20, but the server was at 10. The machines I'd left on G7000 were hanging up to, aparrently sockets aren't being released is what it acts like cause the clients don't get released so they hang on waiting for the server to do something. I have taken all my clients off G7000 and am running an llrnet server here at home on a manual reservation.

mdettweiler 2009-12-06 01:50

[quote=Brucifer;197948]I've had mine at 20, but the server was at 10. The machines I'd left on G7000 were hanging up to, aparrently sockets aren't being released is what it acts like cause the clients don't get released so they hang on waiting for the server to do something. I have taken all my clients off G7000 and am running an llrnet server here at home on a manual reservation.[/quote]
Do you have the latest version of the client (2.4.6)?

Meanwhile, I've upped maxworkunits on the server to 50. If you're feeling bold, give it a try at 20.

BTW Bruce, could you possibly send me a debug log snippet from a client that demonstrates the problematic behavior if you see it again? If I can get an exact timestamp for when the problem's occurring, I can compare what happened on the server's debug log at that same time and possibly get a better idea of what's going on.

Brucifer 2009-12-06 04:34

yup latest client.

edit: I'm just going to run my llrnet stuff and not mess anymore with the prpnet.

gd_barnes 2009-12-08 00:48

I'm sure it's due to the load on the server. I just looked at it now. It's like it's in an endless loop from for getting and receiving nothing from Lennart. I'll stop and restart the server.

We're all tired of the PRPnet problems and I'm sure PrimeGrid is too. It is my conclusion that PRPnet cannot handle a large load and will not be able to do so in the foreseeable future until memory is no longer utilized for most of it.

Bruce, your machines on PRPnet port 4000 for the 5th drive had no problem that I observed. I'm a pretty big sceptic in this situation but am comfortable enough to put my own machines on PRPnet port 4000. That's because tests take much longer than the 12th drive. Also the long tests on CRUS PRPnet port 1300 have made that quite a stable server over there. So I'm comfortable in saying that you can run port 4000 here and not have problems.

Max, based on the problems, here is how I would like to proceed:

1. (Must be done by late Tuesday): Set up a PRPnet server for the 6th drive and load n=743K-750K. The LLRNet server for that drive is going to be drying over the next few days.

2. Set up an LLRNet server for the 12th drive on port 4000 and load it up with k=2600-2800/n=50K-250K (please make sure extra headers are removed). We'll go ahead and finish k=2400-2600 on the current PRPnet server and then remove that server. PRPnet does not work for small tests with any kind of large load and it's the large load we need to knock off this large range of work.

3. For the 11th drive, set up an LLRNet server on my machine at your convience and load n=520K-530K in it. It will be several weeks before David's server dries so no rush there. I want this on LLRnet because I want the possibility for rallies on it in the future. PRPnet is not ready for rallies. Also, the kind of smaller tests make it more vulnerable than the 5th/6th drives.

Here is the effect of all of this for the future:

5th drive: PRPnet server
6th drive: PRPnet server (currently LLRnet)
7th drive: LLRnet server
11th drive: LLRnet server
12th drive: LLRnet server (currently PRPnet)
doublecheck drive: PRPnet server*

*We may have to go back to an LLRnet server at some point if some heavy hitters come in on it.

In other words, only the n>700K tests will be on PRPnet servers and we're leaving one of those on PRPnet for people's comfort level. People can take their choice.

My apologies to Bruce and Lennart and thank you for helping us out with these small n-ranges. Lennart, if you stay on the 12th drive PRPnet server with your current load, I'll check it several times a day. If it has problems, I'll stop and restart it like I'm about to do right now.

I'm sorry everyone, PRPnet is just not fully ready for the big time yet; at least not at the lower n-ranges, which I'm classifying as anything n<700K right now. I as well as PrimeGrid have been more than patient with it. It's time to finally deal with the reality of the situation.

Edit: The 10th drive was left out of this post. See discussion below.


Gary

mdettweiler 2009-12-08 03:25

Actually, I think you might be underestimating what PRPnet can handle a bit. :smile: From what I've observed, I think PRPnet should be able to handle anything over 200K fine, even with lots of cores. I think once we finish off the lowest tier of the 12th Drive, that one will actually be OK to continue on with PRPnet.

This is not due to problems with PRPnet per se but rather the inherent limitations of a single-threaded server application. That said, those inherent limitations are rather high. Keep in mind that we didn't start encountering problems until we had Lennart and Bruce's combined might on tiny n=50K candidates. Also, Bruce has recently been testing the G2000 (n=~300K) server with loads of clients, and it's been holding up quite nicely.

Here's how I suggest we proceed:

-Finish off the currently loaded range in G7000, but don't do any more n=50K-250K work through PRPnet. Bruce has offered to finish off this portion of the drive with his internal LLRnet server, and I estimate he can have it done within a month.

-Continue in PRPnet G7000 with the n>250K portion of the 12th Drive.

-Continue transferring all the other servers over to PRPnet except G4000/7th Drive, which will permanently remain on LLRnet.

Essentially, the only work we have that is more than PRPnet can handle, even under stressful rally conditions, is the tiny 50K-250K stuff. Everything else should be A-OK. And I'm not just saying that out of wishful thinking; this time we have real data from Bruce's tests on G2000 to back it up. :smile:

Max :smile:

gd_barnes 2009-12-08 04:32

Sorry Max. Not this time around. We've had enough. It's not ready yet. I'd like to stick with what I suggested. Our heavy hitters are frustrated and rightfully so. Thanks.

You can say you know what the problem is but there is no way to know without large-scale beta testing. Yes, it worked for Bruce on smaller tests for a while but there have been large changes since then. And as we've seen, changes to one thing usually affect other things on PRPnet.

IMHO, running a PRPNet rally is tantamount to a disaster, especially if Lauren from Free-DC showed up with his 200 cores.

If the 3 PRPnet servers go well for 6 months, then we'll move some more over. I want to make it a more gradual process.


Gary

mdettweiler 2009-12-08 04:35

[quote=gd_barnes;198140]Sorry Max. Not this time around. We've had enough. It's not ready yet. I'd like to stick with what I suggested. Thanks.

If that goes well for 6 months, then we'll move some more over. I want to make it a more gradual process.


Gary[/quote]
Okay, if we have to... :unsure:

BTW, what about the 10th Drive? That one's at about 664K right now, and it should be plenty big enough for PRPnet to handle easily. We'd still be keeping all the smaller stuff (11th, 12th Drives) on LLRnet, but at least all the stuff that we know can work with PRPnet will be on there.

gd_barnes 2009-12-08 04:51

[quote=mdettweiler;198141]Okay, if we have to... :unsure:

BTW, what about the 10th Drive? That one's at about 664K right now, and it should be plenty big enough for PRPnet to handle easily. We'd still be keeping all the smaller stuff (11th, 12th Drives) on LLRnet, but at least all the stuff that we know can work with PRPnet will be on there.[/quote]

Oh, I completely forgot about that one. lol OK, I'll relent there. With little interest on it of late, we can put it on PRPnet. It will become more popular as the 11th drive passes n=600K but that will be quite a while.

Edit: I just now updated applicable posts to include the 10th drive for PRPnet in the future.

gd_barnes 2009-12-08 13:03

Max,

I just now had to shut down and restart my server machine. The screen had gone partially blank with no icons, many of the apps on the top tool bar had little red x's through them, and the servers were doing nothing. I'm not sure as to what could have caused this.

I restarted the servers like they've been done previously except that I did it directly on the machine instead of remotely.

I can confirm that ports 3000 and 4000 have started handing out work again. I can't tell yet on the others. The down time appeared to be a little over an hour.


Gary

mdettweiler 2009-12-08 15:55

[quote=gd_barnes;198179]Max,

I just now had to shut down and restart my server machine. The screen had gone partially blank with no icons, many of the apps on the top tool bar had little red x's through them, and the servers were doing nothing. I'm not sure as to what could have caused this.

I restarted the servers like they've been done previously except that I did it directly on the machine instead of remotely.

I can confirm that ports 3000 and 4000 have started handing out work again. I can't tell yet on the others. The down time appeared to be a little over an hour.


Gary[/quote]
Okay, everything looks good. :smile:

gd_barnes 2009-12-08 23:22

Something similar is happening again. I don't know what is causing it but I suspect it might be the memory filling up. (Maybe the load on G7000 is causing it? That would be a problem on my machine and not with PRPnet, per se.) The icons are there this time but I can't access any of the menu selections at the top including not being able to shut the computer down normally. Other functions seem to be not working either. It sounds like a full memory to me. I've never had any issues like this with any of my Linux machines in the past.

I'm going to shut the computer down and restart everything but I won't restart port G7000.

Lennart, I'm assuming that you're probably off of G7000 now but if you're not, you may want to move them else. Due to its issues, I'm not going to restart it for a while. We need to figure out what is virtually locking up my machine.

Max, all my machines have 2 GB of memory. The new server machine will have 4 GB. What I could do (if compatible) is put one of the memory sticks that will go in it into the current server machine.

Frankly, I'm not sure what to do about k=2400-2600 on the 12th drive right now. I'll have to think about it. If anyone has any thoughts, I'm all ears. I could just put one quad on it myself on PRPnet and let it hack away for days or weeks until it finishes.


Gary

Brucifer 2009-12-09 01:25

Why don't you just shut it down. Send me the remains of the file and I will finish it up and then shoot the results to Max, and then Max can try and piece it all together. The other option is just send me the whole range and I'll go the whole thing. I just mentioned the first option first though cause Lennart has run a lot of that and no sense wasting his work. :-)

At any rate, that would take care of the 7000 stuff, and then the project doesn't have to worry about it and I'll jcrunch the stuff in between the other stuff.

edit: In fact, just send me all the stuff that you were going to put on 7000, and I'll just run it all here at home. As Max mentioned earlier in a thread somewhere, should only take me 4 to 6 weeks and then it's all out of our hair. :-)

gd_barnes 2009-12-09 01:44

OK, thanks for the offer and that is under consideration Bruce. The problem is determining what is left for k=2400-2600 on PRPnet. I'll let Max make the determination on whether he thinks what is left in our candidates file is an accurate representation of what remains. Max, do you feel that is accurate? If not, any suggestions?

I know you're offering to do the whole range again but then there's the credit issue. We want to give you and Lennart appropriate credit for the work already done on G7000 and later on, we'll import what you finish up manually into the stats DB.

I've asked Max to send you k=2600-2800 for n=50K-250K. If he hasn't done that by about midnight CST, I'll send it to you. In the mean time, he has to set up a new PRPnet server for the 6th drive. Ironbit's current LLRnet server will dry out by tomorrow.


Gary

mdettweiler 2009-12-09 03:06

[quote=gd_barnes;198286]OK, thanks for the offer and that is under consideration Bruce. The problem is determining what is left for k=2400-2600 on PRPnet. I'll let Max make the determination on whether he thinks what is left in our candidates file is an accurate representation of what remains. Max, do you feel that is accurate? If not, any suggestions?

I know you're offering to do the whole range again but then there's the credit issue. We want to give you and Lennart appropriate credit for the work already done on G7000 and later on, we'll import what you finish up manually into the stats DB.

I've asked Max to send you k=2600-2800 for n=50K-250K. If he hasn't done that by about midnight CST, I'll send it to you. In the mean time, he has to set up a new PRPnet server for the 6th drive. Ironbit's current LLRnet server will dry out by tomorrow.


Gary[/quote]
How about this:

-I send Bruce the files to do all of k=2400-3000 for n=50K-250K.
-Since Bruce's results will be considered "manual work" as far as stats are concerned, the G7000 results done by Lennart will make it into the DB well ahead of them anyway.
-As such, when we import Bruce's results later on, after we've gotten manual-results import up and running, the DB will give us a clear list of what's new and what's already in there. The stuff that's already in there will be imported into the doublecheck DB (which should be all set by then), and credited to Bruce as such. That will save us a bit of work when we eventually doublecheck this range.

Brucifer 2009-12-09 06:22

That works very well Max, and good idea on the double check stuff for any overlap!!! :-) That takes care of both Lennart and my efforts which is cool.

kar_bon 2009-12-09 07:56

i would like to get those results, too, for checking and updating my summary pages for drive 12 for that range. all results like normal in LLR-format.

so for now i can update up to k=2399 and then it would be great if i can get results for small ranges done, like 50 or 100 k's.
thanks.

gd_barnes 2009-12-09 09:30

PRPnet port 7000 is officially offline now. Bruce has manually reserved k=2400-3000 for n=50K-250K and will run a personal LLRnet server to complete the range.

The current plan is to create an LLRnet server to run n=250K-350K for the 12th drive. We'll then revisit the possibility of a PRPnet server when we're ready to start with n=350K-425K.

gd_barnes 2009-12-09 22:19

PRPnet port 5000 for 6th drive range n=743K-750K has now been set up and is ready for clients.

mdettweiler 2009-12-11 04:31

Daily results copying-off and [url=http://nplb-gb1.no-ip.org/prpnet/]status page[/url] updates are now online for G5000.

I also took the opportunity, while I was at it, to remove G7000 from the status page as it is no longer active. Note that the results from there will eventually get into the database (after Dave has cleaned up the mess in the DB from the tail end of LLRnet G7000's previous tenure). When that happens, the results will be online at [URL]http://nplb-gb1.no-ip.org/llrnet/results/[/URL] as usual, to answer Karsten's request in post #84.

gd_barnes 2009-12-13 11:01

I will be out of town Dec. 14th thru 21st; Monday to Monday. I will be on most days but my time will be more limited.

I'll be leaving for the airport around 2:00 Monday afternoon. The cable folks are coming out on the 14th morning sometime between 9 AM and noon to upgrade my service to the fixed IP address. Hopefully there are no issues there. All GB servers will probably need to be down 1-2 hours.

Max, let me know if you see any potential issues now. My time will be pressed on Monday. I hadn't planned it that way. It was just the quickest they could get me in and I didn't want to wait another week.

Obviously my IP address will change. Let me know if and how that affects the no-IP and remote access stuff on my machines.


Gary

mdettweiler 2009-12-13 14:49

[quote=gd_barnes;198705]Max, let me know if you see any potential issues now. My time will be pressed on Monday. I hadn't planned it that way. It was just the quickest they could get me in and I didn't want to wait another week.

Obviously my IP address will change. Let me know if and how that affects the no-IP and remote access stuff on my machines.[/quote]
I don't foresee any problems cropping up. Since the server won't actually be shut down, the servers should be all ready to go when your internet comes back online. Even if you do need to shut it down, though, for whatever reason (I don't think this will be the case), you know how to restart the servers.

As for the IP, I doubt we'll have any issues there either. The worst that could happen is that a client or two might not be able to reach the server for a couple hours until it decides to update its DNS cache, but there's not really anything we can do about that.

I'll send you a couple final instructions via PM regarding upgrading to the static IP. Stay tuned. :smile:

gd_barnes 2009-12-14 06:33

Max,

Should we show the port 2000 doublecheck effort on the green web page?


Gary

mdettweiler 2009-12-14 06:34

[quote=gd_barnes;198785]Max,

Should we show the port 2000 doublecheck effort on the green web page?


Gary[/quote]
Good idea. I'll do that now.

mdettweiler 2009-12-14 06:41

[quote=mdettweiler;198786]Good idea. I'll do that now.[/quote]
Okay, all set. BTW, since I needed to enter something in the description field for the server, I decided to designate this effort "Doublecheck Drive #2", which it's essentially been all this while in everything but name. It seemed a bit more substantive than just calling it "k=300-400 doublecheck". :smile:

gd_barnes 2009-12-14 17:35

The cable/internet guy is here now to set up the commercial (fixed IP) acct. There will likely be some small downtime on the GB servers.

When done, there will be no more IP address changes. :smile:

gd_barnes 2009-12-14 18:19

The fixed IP is now all set up. I had to shut down the servers for only ~20-30 mins. while the guy was here but they are now running again.

Max, everything seems to be working like clockwork. All machines have internet access and I'm able to remotely connect to all of the machines that I could before.

It's nice to have something technical go off without a hitch. :smile:

Everyone, you might check your clients connected to the GB servers. They should have fairly quickly reconnected after I restarted the servers.

...fast internet! Weeeeeee! :smile:


Gary

mdettweiler 2009-12-15 00:07

[quote=gd_barnes;198838]The fixed IP is now all set up. I had to shut down the servers for only ~20-30 mins. while the guy was here but they are now running again.

Max, everything seems to be working like clockwork. All machines have internet access and I'm able to remotely connect to all of the machines that I could before.

It's nice to have something technical go off without a hitch. :smile:

Everyone, you might check your clients connected to the GB servers. They should have fairly quickly reconnected after I restarted the servers.

...fast internet! Weeeeeee! :smile:


Gary[/quote]
Cool! I'm greatly relieved to hear all went without a hitch. :smile:

There's only one problem: you've still got a dynamic IP. :razz: I just checked your router and it's still on dynamic mode. Note that this isn't a problem on your ISP's end, just that you forgot to perform the instructions I sent you on properly configuring your router. :smile:

No problem, though--it looks now like I'll be able to do that part. It seems that even though you've been given a static IP, you're still allowed to use a dynamic one if you really want to, which is what your router is doing right now since it's still configured as before. This is actually a good thing, and I was hoping this would be the case, since it means that your existing configuration would work fine on the new connection at least until I could get in and do the geek stuff myself. :smile: I didn't know until now that this would be the case, though, hence my PM with instructions for that part of the setup.


Gary, I'm assuming that the cable guys gave you a piece of paper or something with the following information on it:[LIST][*]IP address[*]Subnet mask[*]Gateway[*]Primary and secondary DNS servers[/LIST]Could you send me all the above info? That way I can configure your router to use the [I]real[/I] static IP, so we'll truly not have any more IP changes ever again. :smile:

BTW, is the new connection faster than the old one? I'm guessing so given your remark at the end of your last post. That will definitely be a boon for the Aliquot Sequences project once we get the FTP server set back up for them on the new server. (For the uninitiated, they transfer lots of large files as part of their group factorization efforts and we used to host an FTP server for them before we shut it down in preparation for our upcoming move to the new server.) And, of course, you'll have a faster internet connection on your end too. :smile:

gd_barnes 2009-12-15 03:55

I'm stuck in Denver right now on the way to Las Vegas waiting on a long delayed flight.

Sorry. I thought the instructions were meant for if my router (modem?)wasn't properly connecting. Since it was connecting great, I didn't think they were necessary.

They gave me a couple of pieces of paper but I don't think they had much detailed info. on them. I was looking for an IP address and didn't see one.

One thing that might help: When I remotely connected from my laptop, it said that so-and-so IP address was added to its list of valid IP addresses. Is there a way for you to view the list of valid ones by remote access? Of course the fixed IP would be the last one that it just recently added.

Perhaps the fixed IP will have to wait a week.

One interesting note: I also went by residential Time Warner and had them remove my residential internet. I had checked that everything worked both before and after I went there. But now I wonder if they hadn't removed the residential side when I checked and hence everything appeared to be working even though I didn't do the setup stuff you sent. And even further: I'm now wondering if things will stop working when they remove my residential internet account. Ugh.


Gary

mdettweiler 2009-12-15 16:10

[quote=gd_barnes;198876]I'm stuck in Denver right now on the way to Las Vegas waiting on a long delayed flight.

Sorry. I thought the instructions were meant for if my router (modem?)wasn't properly connecting. Since it was connecting great, I didn't think they were necessary.

They gave me a couple of pieces of paper but I don't think they had much detailed info. on them. I was looking for an IP address and didn't see one.

One thing that might help: When I remotely connected from my laptop, it said that so-and-so IP address was added to its list of valid IP addresses. Is there a way for you to view the list of valid ones by remote access? Of course the fixed IP would be the last one that it just recently added.

Perhaps the fixed IP will have to wait a week.

One interesting note: I also went by residential Time Warner and had them remove my residential internet. I had checked that everything worked both before and after I went there. But now I wonder if they hadn't removed the residential side when I checked and hence everything appeared to be working even though I didn't do the setup stuff you sent. And even further: I'm now wondering if things will stop working when they remove my residential internet account. Ugh.


Gary[/quote]
Okay, I verified that the IP address you have now is on RoadRunner's business network, so yes, that's working properly. It's still dynamic, but it's on the commercial account nonetheless.

No need to worry about it for now; a dynamic IP should be able to last out the week without changing. Once you get home you can look at the various documentation they gave you and see if your IP's on there. If you can't find an IP on any of the literature they provided, call them. This type of service is supposed to have a fixed IP, so they should be able to at least tell you what yours is (otherwise it's no use).


All times are UTC. The time now is 17:32.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.