[quote=gd_barnes;182447]Whoa! That's weird and funny. I got a "Welcome to Crunchford" page with a "Sorry nothing here yet" comment below it and a picture of the funny "O RLY" ostrich that is Ian's avitar. I assume you put all of that there. Is that what I am supposed to be getting?[/quote]
Yes, that's what you're supposed to be getting. I put that there back when I first set up the server (before that picture was Ian's avatar, in fact), so I could have something to test the server with. Eventually I decided to put the status pages under the llrnet/ subdirectory instead, and the self-described "Placeholder Page" never got removed. :smile:

Since you obviously were able to make contact with the server when you connected to it directly by IP, that would seem to indicate a DNS cache problem. Rebooting should fix it (though I haven't the faintest idea why refreshing the DNS cache as per my earlier instructions wouldn't work; it worked right away for me), though it's also possible that even without a reboot, the DNS cache entry for that domain expired naturally. At any rate, give it another try with the domain ([URL]http://nplb-gb1.no-ip.org/[/URL] should get you to the "O RLY" page), and if that doesn't work, try rebooting.

Just a quick note to confirm that the timeout changes that were applied have worked as anticipated.

Hourly processing resumed when the server came back up, without intervention.

The daily result process picked up and processed files from GB for both 14th and 24th July, without intervention.
The daily result process took just over 6 minutes due to the extra files.
I anticipate that the time will reduce further back towards the usual 4-5 minutes tomorrow now that the stats server has caught up with the GB files.

All's well. :smile:

/ed-
I may regenerate the overall summary table this weekend just to be sure.
I'll let you know in advance if there is any difference.
Cheers
-ed/

Great work Dave!

I have a small request: Could you make the hourly totals page sort ascending by server instead of descending? I think it would be easier to find the hourly stats for the server that you want that way.


Thanks a bunch,
Gary

[quote=gd_barnes;182575]Great work Dave!

I have a small request: Could you make the hourly totals page sort ascending by server instead of descending? I think it would be easier to find the hourly stats for the server that you want that way.


Thanks a bunch,
Gary[/quote]
Yes, especially with our current priority being on IB-[B]2000[/B], a rather low number. I think back when the system was set up it was on IB8000, which is rather near the top.

I think we did it because the servers that start with a "G", i.e. mine, would sort to the top and those are usually lower priority. But that's OK if G4000 and G8000 are at the top with IB2000 3rd followed by the rest. It's just easier to read a list that is sorted lowest to highest if it is not ranking something like primes score or # of primes.

could we please set the jobMaxTime for the higher ranges to 2 or 3 days again?

thanks.

sort changed to port ascending, then server ascending and then date descending. Participants are still sorted alphabetically.

[quote=kar_bon;182609]could we please set the jobMaxTime for the higher ranges to 2 or 3 days again?

thanks.[/quote]

Not this time. Frankly I'm tired of messing with the JobMaxTimes and I have told David (IronBits) that we would no longer be messing with them. We've had this discussion before and I reluctantly let it go to 3 days on all ports. Many other projects use 1 day. We set them lower so if some nefarious individuals cache a bunch of pairs and don't process them, which happened twice with port 2000 shortly after we started the 11th drive, the pairs would be returned and reprocessed fairly quickly. At 3 days, I've seen pairs go longer than 6 days without being processed, when they are handed out, not processed, returned, handed out, not processed again, returned again, handed out a 3rd time, and finally processed.

My ports G4000 and G8000 are 5 days. We left those alone. IMHO, that is way too long but I've let them stand since Max controls those servers and a few people like yourself and Max want them longer. Also, port IB9000 is 2 days. G8000 and IB9000 contain the higher ranges now. That should be plenty of time and plenty of choice for processing higher n-range pairs on longer JobMaxTime ports.


Gary

[QUOTE=gd_barnes;182677]My ports G4000 and G8000 are 5 days. We left those alone. IMHO, that is way too long but I've let them stand since Max controls those servers and a few people like yourself and Max want them longer. Also, port IB9000 is 2 days. G8000 and IB9000 contain the higher ranges now. That should be plenty of time and plenty of choice for processing higher n-range pairs on longer JobMaxTime ports.
[/QUOTE]

misunderstood?

all ports got just jobMaxTime=1 since the setup of Drive #11.

port IB9000 was set up to 2 days because of the higher range on my request.

port GB9000 seems still on 1 day,too. look at the rejected log yesterday!!!
i've lost many pairs because of those 1day-Timer!

request: could the jobMaxTime displayed at [url]http://nplb-gb1.no-ip.org/llrnet/[/url] too, like for IB-ports?

[quote=kar_bon;182698]misunderstood?

all ports got just jobMaxTime=1 since the setup of Drive #11.

port IB9000 was set up to 2 days because of the higher range on my request.

port GB9000 seems still on 1 day,too. look at the rejected log yesterday!!!
i've lost many pairs because of those 1day-Timer!

request: could the jobMaxTime displayed at [URL]http://nplb-gb1.no-ip.org/llrnet/[/URL] too, like for IB-ports?[/quote]
I just checked, and it looks like GB4000 and GB8000 are both set to 3 days. Regarding the rejected pairs, unfortunately I can't see those any more, so I don't know what would have caused those. Were they by chance from k/n pairs you reserved prior to the server outage? If so, then it's possible that those were due to the outage, despite the precautions we took to avoid having anyone else connect to the server until you'd returned your pairs.

Next time we have a server outage, I'll be sure to set all the ports to a higher jobMaxTime for a day or two to give people a chance to return their old results. (Note that this won't affect the PRPnet servers, since PRPnet codes the expiration date directly on each k/n pair in its prpserver.candidates file, so if you change the equivalent of jobMaxTime, I'm pretty sure that the expiration dates will not be recalculated.)

Regarding displaying jobMaxTime on the web page: okay, that sounds like a good idea. It will need a tad of work to make sure that the scripts can pull it out of the llr-clientconfig.txt file live, but I'm sure is is possible and will try to get it set up.

those rejected pairs were new ones reserved directly after submitting the results of 400 i got since the outrage.

have a look at [url]http://www.noprimeleftbehind.net/index.php?content=progress[/url] for the GB8000 server:
- on 2009-07-23 16:00 there're the 400 pairs submitted corcectly after the server was ok again
- the same time i've reserved another 400 (as still in the llr-clientconfig.txt for my instances)
- on 2009-07-24 18:00 the server only take 58 from these 400 back, the remaining were rejected!