The servers are down again...

[quote=em99010pepe;126607]The servers are down again...[/quote]

... and up again.

[quote=em99010pepe;126572]... Meanwhile, you guys better move all cores to port 300.[/quote]

Main bus B undervolt. Everyone in the LEM!

I ask people to split the cores between server ports 100 and 300. That's the best thing to do and the rally will take place on both server, thoughts?

EDIT: Also on ports 443 and 444....

By reading RieselSieve forum I detected that sometimes a client can jam the llrnet server...that happened twice in 3 years on them. Now we need to find who was the bad guy!

Another thing that helps: if the client gets stuck at 99 % please restart it.

Carlos

EDIT: server port 100 is getting 3x more work than server port 300.

... and hanging again!

[quote=em99010pepe;126610]I ask people to split the cores between server ports 100 and 300. That's the best thing to do and the rally will take place on both server, thoughts?

EDIT: Also on ports 443 and 444....[/quote]
What work is on 443 and 444?

I think we have to cancel the rally until I find who's the faulty client that is hanging the server.

On port 443 and 443 you have [url=http://www.mersenneforum.org/showthread.php?t=9911]this[/url].

In a way I don't mind if we postpone this rally. It means I can finish my GIMPS number 24 hours earlier, so I can join NPLB sooner. In fact, I think I'll go reserve a range now. :smile:
(Est. time is Monday at 11:29 CST, but I use the computer, so I'd say that afternoon-night.)
Edit: BTW, there were nearly 50 new posts in this thread when I woke up...hehe, you people post a lot. :razz:

I'm going to clear the cache from 5 cores then move to manual reservation. I think the best strategy is to manual reserve ranges when possible and only add cores to LLRnet in limit cases like work machines where you don't have daily control, etc. I prefer to use the manual client so from now on I won't run LLRnet client.

I need to know who can only run LLRnet?
My example: only on 2 cores, the rest can run manual LLR.

We need to soft the interaction between clients/server until we reach a higher n when the candidates began to be longer to test and therefore less communications with the server will take place.

[quote=em99010pepe;126613]By reading RieselSieve forum I detected that sometimes a client can jam the llrnet server...that happened twice in 3 years on them. Now we need to find who was the bad guy!

Another thing that helps: if the client gets stuck at 99 % please restart it.

Carlos

EDIT: server port 100 is getting 3x more work than server port 300.[/quote]
Hmm. Maybe it's not one user in particular who caused the problem, just a general overload of sorts? In which case, the cause of the problem would be running too many LLRnet servers on one machine.

Maybe once I've "taught" Gary how to run an LLRnet server as he requested, we can run the port 100 server over on one of his machines.

You know, now that I think about it, the symptoms on my end really seem to support the "client jamming the server" theory. You see, what I've found happening is, one of my clients will finish a k/n pair, and report it successfully; but the other one, meanwhile, finishes a k/n pair the next minute and can't report it until a minute later when it tries again! So, it would seem as if the server [i]is[/i] getting "jammed" by an overload of clients connecting.

(This is for the port 300 server, by the way.)