Rally Nov. 21st-23rd

[mdettweiler]

Originally Posted by IronBits

I would think creating multiple proxy servers, with 20-25 fast clients each, should be more than enough to simplify the moving of cores around to different projects.
We can always toss some knpairs on another port (5000?) so Lennart can play with his proxy settings to see if he can find the optimal solution for his needs.

Okay, how about we do that after the rally. Gary, how about we load 598K-600K or something like that into port 5000 for this?

[em99010pepe]

ecmnet client has an interesting feature, when changing servers on the config file the client always sends back the work to its origins. llrnet should behave like that in a future version. (Gary's comment about clearing the cache)

I'm leaving to have dinner and see a movie with my girlfriend. Hope the server C443 stays up and running, if something goes wrong I advise the clients to change server address to IB400 one. Bye.

[IronBits]

With Beyond's extensive testing, it was determined there is a flaw in the way the proxy communicates with the server.
It opens a bunch of sockets at once to get work, but never closes those sockets and almost never gets many knpairs for it's efforts.
I was watching the sockets climb to the max connections in the config file within seconds of bringing it online, every time, just like what happend with Beyond.

Maybe I can get Beyond to weigh in on this subject so we can gain the knowledge of his experience and testing with the proxy with all his fast cores.

[mdettweiler]

Originally Posted by IronBits

With Beyond's extensive testing, it was determined there is a flaw in the way the proxy communicates with the server.
It opens a bunch of sockets at once to get work, but never closes those sockets and almost never gets many knpairs for it's efforts.
I was watching the sockets climb to the max connections in the config file within seconds of bringing it online, every time, just like what happend with Beyond.

Maybe I can get Beyond to weigh in on this subject so we can gain the knowledge of his experience and testing with the proxy with all his fast cores.

Here's the interesting thing, though: when I look at G4000's server console, the socket #'s seem to be somewhat steady in the range of 40-50. So, it would seem that the sockets *are* being closed--though possibly not until the proxy's done with its current batch of results. That would be consistent with what we've been seeing: that a proxy with more results to return than a server has available sockets simply fills up all the available sockets, but doesn't close them because it doesn't think it's done with those sockets. Hence the server crashes when the proxy tries to open yet another socket to continue submitting its results.

Anyway, just a hypothesis.

[Flatlander]

server = "nplb-gb1.no-ip.org"
port = 4000

Is asleep.

Or maybe awake again???

[mdettweiler]

Originally Posted by Flatlander

server = "nplb-gb1.no-ip.org"
port = 4000

Is asleep.

Or maybe awake again???

Looks good to me. Though upon looking back through the console output it seems as though there may have been a short interruption of some kind a few minutes ago...at any rate, though, all should be find now.

[gd_barnes]

Originally Posted by mdettweiler

Okay, how about we do that after the rally. Gary, how about we load 598K-600K or something like that into port 5000 for this?

OK, but let's keep it on the leading edge of the current servers so we don't have these huge holes; perhaps 576K-578K. It it drops dead as a result of testing, even for up to a week, it wouldn't be a problem because we have a huge amount of work in port 400 at the moment.


Gary

[mdettweiler]

Originally Posted by gd_barnes

OK, but let's keep it on the leading edge of the current servers so we don't have these huge holes; perhaps 576K-578K. It it drops dead as a result of testing, even for up to a week, it wouldn't be a problem because we have a huge amount of work in port 400 at the moment.


Gary

Okay, sounds good.

[Wabbit98]

I switched over to 4000 because my client was asleep this morning and it was on 400.

Ni

[IronBits]

That's what happens to the client when the server doesn't respond after an unknown amount of time passes.
The server is running, all you would have had to do was restart it to get work.

[Beyond]

Originally Posted by IronBits

With Beyond's extensive testing, it was determined there is a flaw in the way the proxy communicates with the server.
It opens a bunch of sockets at once to get work, but never closes those sockets and almost never gets many knpairs for it's efforts.
I was watching the sockets climb to the max connections in the config file within seconds of bringing it online, every time, just like what happend with Beyond.

Maybe I can get Beyond to weigh in on this subject so we can gain the knowledge of his experience and testing with the proxy with all his fast cores.

The proxy opens a new socket for each client that is connectd to that proxy. On each failure to connect (send or recieve) it leaves the sockt connection open (there is no 'time_out" to drop the connection) then immediately opens another socket to re-try the connection, multiply this by the number of clients on the proxy and you can see what happens.

Multiply proxies will eliminate the problem if thy are all pointed at different servers/ports.