Rally Nov. 21st-23rd

[IronBits]

Working on more stats. this is just a start...
http://nplb.ironbits.net/progress_400.txt

I should probably create a rejected_knpairs.txt file seeing that sometimes there are LOTS of them that make the page to long...

[gd_barnes]

Hum. Port 400 seems to be sleeping at the moment. Is there a problem or did you just bring it down and back up for a little bit?

More pairs for port 400 coming at you in an Email shortly...

[IronBits]

recv error res=-1, errno=104
recv error res=0, errno=104
recv error res=0, errno=104
broken pipe
recv error res=0, errno=32
shutdown: errno 107

LLR Server version 0.9b1 started
Loading library 'win32' ...
pruning joblist ...
finished ...
write 'joblist.txt' ...
finished ...
bind: errno=98
Error while listening on port 9000
Error code : -1

working on it...

[gd_barnes]

Originally Posted by IronBits

recv error res=-1, errno=104
recv error res=0, errno=104
recv error res=0, errno=104
broken pipe
recv error res=0, errno=32
shutdown: errno 107

Are there too many clients on it? I could shift a few machines to port 443 or 4000 if necessary.

[em99010pepe]

C443 is up and running...no problems here.

[IronBits]

Added in the new pairs, fired it up, going great
Lennart has too much, like Beyond...
he should split up some of his resources and come slaughter your servers to
:cheers:

[IronBits]

I've seen this before, and it's not good. Must be too much for it to handle.
e325955b:3784 (socket 7)
connection request from e325955b:3763 (socket 45)
connection request from e325955b:3757 (socket 46)
connection request from e325955b:3789 (socket 47)
connection request from e325955b:3556 (socket 48)
connection request from e325955b:3785 (socket 49)
connection request from e325955b:3792 (socket 50)
connection request from e325955b:3555 (socket 51)
connection request from e325955b:3759 (socket 52)
connection request from e325955b:3764 (socket 53)
connection request from e325955b:3567 (socket 54)
connection request from e325955b:3750 (socket 55)
connection request from e325955b:3783 (socket 56)
connection request from e325955b:3786 (socket 57)
connection request from e325955b:3765 (socket 58)
connection request from e325955b:3766 (socket 59)

runs itself out of sockets when it does this... SHIFT

[IronBits]

Just as soon as I bring up the server I get this...

connection request from e325955b:1700 (socket 6)
connection request from e325955b:1698 (socket 22)
connection request from e325955b:1701 (socket 23)
connection request from e325955b:1634 (socket 24)
connection request from e325955b:1639 (socket 25)
connection request from e325955b:1676 (socket 26)
connection request from e325955b:1697 (socket 27)
connection request from e325955b:1643 (socket 28)
connection request from e325955b:1642 (socket 29)
connection request from e325955b:1674 (socket 30)
connection request from e325955b:1703 (socket 31)
connection request from e325955b:1678 (socket 32)
connection request from e325955b:1650 (socket 33)
connection request from e325955b:1681 (socket 34)
connection request from e325955b:1645 (socket 35)
connection request from e325955b:1649 (socket 36)
connection request from e325955b:1572 (socket 37)
connection request from e325955b:1573 (socket 38)
connection request from e325955b:1648 (socket 39)
connection request from e325955b:1680 (socket 40)
connection request from e325955b:1651 (socket 41)
connection closed (socket 7)
connection closed (socket 10)
connection request from e325955b:1705 (socket 7)
connection request from e325955b:1704 (socket 10)
connection request from e325955b:1604 (socket 42)
connection request from e325955b:1603 (socket 43)
connection request from e325955b:1663 (socket 44)
connection request from e325955b:1660 (socket 45)
connection request from e325955b:1354 (socket 46)
connection request from e325955b:1644 (socket 47)
connection request from e325955b:1654 (socket 48)
connection request from e325955b:1685 (socket 49)
connection request from e325955b:1355 (socket 50)
connection request from e325955b:1687 (socket 51)
connection request from e325955b:1662 (socket 52)
connection request from e325955b:1683 (socket 53)
connection request from e325955b:1688 (socket 54)
connection request from e325955b:1659 (socket 55)
connection request from e325955b:1689 (socket 56)
connection request from e325955b:1691 (socket 57)
connection request from e325955b:1686 (socket 58)
connection request from e325955b:1665 (socket 59)
connection request from e325955b:1666 (socket 60)
connection request from e325955b:1656 (socket 61)
connection request from e325955b:1692 (socket 62)
connection request from e325955b:1670 (socket 63)
connection request from e325955b:1668 (socket 64)
connection request from e325955b:1609 (socket 65)
connection request from e325955b:1608 (socket 66)

[em99010pepe]

Lennart is using a proxy, that's the problem, when he dumps the server goes down. He should not be using it although it is an easy way to change a lot of cores from server to server.

Carlos

[IronBits]

That's what I thought it was. llrnet server can't handle proxy to server very well at all.
We are toast till he knocks off some of them cores. Beyond used to do that to me as well, and he had to stop doing it ...

[mdettweiler]

Originally Posted by em99010pepe

Lennart is using a proxy, that's the problem, when he dumps the server goes down.

Carlos

Lennart, how many k/n pairs at a time is your proxy set to cache? And David, what is your maxConnections setting? Maybe the problem would be fixed if Lennart sets his proxy to only get/return less k/n pairs at a time than the maxConnections setting is equal to.

In the meantime, it might also be helpful if some of the 'heavy hitters' on port 400 switched to G4000, at least until we resolve this issue with Lennart's proxy.

(P.S.: Gary, if you switch any of your cores to G4000, you can just enter "192.168.2.100" for the server field in llr-clientconfig.txt, instead of "nplb-gb1.no-ip.org". Either will work, but "192.168.2.100" is a shorter route to the server and will probably be quicker/better. )