[ANN] New Primecoin Pool + GPU Miner

[dga]

FINAL UPDATE: The pool will close. All balances will be PAID once they are mature. I WILL release a solo miner.

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.

[1714670182]

1714670182

[1714670182]

1714670182

[1714670182]

1714670182

[1714670182]

1714670182

[amartinz]

Please don't stop the pool. Ypool is boring...

[gilad215]

Dont give up on the pool! there must be a solution and it seems a lot of guys that can help you are here to help!

[neza777]

Don't give up

[incognitoworker]

Same, dont give up!
Competition is great

[ozzy1926]

yea dont give up! i am bored already

[kev7112001]

u guys dont understand pools these days will always get hit bad with ddos thats a fact i would concentrate on making faster miners not a pool and he seems to be doing this on his own not a team of people the only way a pool would be ok is if there were many many pools and a way to setup backups in case 1 went down which we dont have this isnt like cgminer where u can set that up in case of those situations

[madMAx510510]

NEWS: I've decided to go open source.

See the official thread:
https://bitcointalk.org/index.php?topic=602292.0

EDIT: The pool server will be running and processing payouts until everything has been paid. All balances >= 0.1 XPM will be paid.
Note that you can't mine. It's running only for the payouts.

[B.T.Coin]

NEWS: I've decided to go open source.

See the official thread:
https://bitcointalk.org/index.php?topic=602292.0

So is anybody setting up a new pool with this code?

[madMAx510510]

FINAL UPDATE: The pool will close. All balances will be PAID once they are mature. I WILL release a solo miner.

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.

You were right. This is the issue:
/usr/include/linux/posix_types.h:#define __FD_SETSIZE   1024

Basically when a process opens more than 1024 sockets any select() call will cause a buffer overflow.

And this is exactly what ConnectSocketDirectly does in netbase.cpp on line 359:
int nRet = select(hSocket + 1, NULL, &fdset, NULL, &timeout);

The issue boils down to the bitcoin code using the default value of __FD_SETSIZE as defined in posix_types.h
But you can't blame the bitcoin devs, they never imagined to open more than 1024 sockets.

Tomorrow i might implement a fix for this and start the pool again. I still have all your ips in the firewall settings

[Starscream]

Cheers man!

[hccwin]

excellent idea! solo mining 

[madMAx510510]

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.

[SpeedDemon13]

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.

That would be a nice feature of auto switching for pools, that would be a first for a XPM GPU miner. DDoS protection isn't cheap also.

What will the tentative time table when you will release a new version of the miner?

[drozenski]

If your interested, i would be willing to host and manage the pool.

PM Me

[ap1]

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.

Will it be possible to use p2pool mode?

[csa1234]

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.

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)

[pavimus]

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.

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)

For me catalyst 13.12 works too on rig 3x7970+7950

[jumpsmasher]

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

[XPM-guru]

When are u releasing solo miner?