Topic: [ANN] New Primecoin Pool + GPU Miner (Read 19670 times)

did you tried using 13,12 modded drivers?

Similar experience here.
13.12 works fine for 79XX / 280X but not with my r9 290s.  Gives an error and closes unless I use 14.x with them

Please be sure your solo miner will work with Catalyst 13.12 as its the only driver that work on my 6 x GPU rig (only driver that recognize the 6 x GPUs on same board)

PS: 13.12 worked 100% fine with your pool miner at 4.30 CPD per GPU (R9 280x core 1150 / mem 1500)

But again, it will be only temporary so there is at least one pool running at all.

In the long run i don't want to be bothered with DOS attacks or manage firewall settings all day long.
I think there should be multiple pools running and then the miner could be auto-switching in case one goes down.
And yeah solo mining of course.

But again, it will be only temporary so there is at least one pool running at all.

In the long run i don't want to be bothered with DOS attacks or manage firewall settings all day long.
I think there should be multiple pools running and then the miner could be auto-switching in case one goes down.
And yeah solo mining of course.

But again, it will be only temporary so there is at least one pool running at all.

In the long run i don't want to be bothered with DOS attacks or manage firewall settings all day long.
I think there should be multiple pools running and then the miner could be auto-switching in case one goes down.
And yeah solo mining of course.

If you change your mind, I'm happy to help a bit.  I think you've taken some really nice steps forward with your architecture thus far and it'd be cool to see a new pool design succeed.  (Particularly if you were, in the long run, interested in open sourcing parts of the protocol so that others could build upon it).  Getting rid of the hacked up mix of binary gloop and stuff-over-http would be great.

A good place to start is here:

http://www.lognormal.com/blog/2012/09/27/linux-tcpip-tuning/
http://pic.dhe.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=%2Fcom.ibm.websphere.edge.doc%2Fedge%2Fcp%2Fadmingd45.htm

A few are important - tuning time_wait will reduce your susceptibility to grade-school-level TCP attacks such as those that were happening the last few days.  But don't set it to 1 second like those guys did - 10 seconds should be adequate.

echo "1024 61000" > /proc/sys/net/ipv4/ip_local_port_range
echo "10" > /proc/sys/net/ipv4/tcp_fin_timeout
echo 32768 > /proc/sys/fs/file-max

syncookies should already be enabled, but if they're not:

echo 1 > /proc/sys/net/ipv4/tcp_syncookies

and check this page's suggestion for using iptables to rate-limit inbound synfloods:
http://www.liquidcomm.net/news/tech_tips/linux_os/how-to-manage-a-ddos-or-dos-attempt-directed-at-your-linux-server.html

It's very possible that the crash you're seeing from ConnectSocketDirectly is related still to running out of file descriptors or something very similar.  General server scalability tuning might make it disappear.  

http://www.nateware.com/linux-network-tuning-for-2013.html

has a few more - particularly the per-user open file limits, etc.  Don't bother with the congestion window and rmem/etc. stuff in there - your server isn't aiming for high tcp throughput on a single connection.

Doing it all via sysctl config in /etc/sysctl.conf is the most straightforward way to have your changes persist after a reboot.

NEWS: I've decided to go open source.

See the official thread:
https://bitcointalksearch.org/topic/open-source-xpm-pool-gpu-miner-aka-madprimeminer-602292