Pages:
Author

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

newbie
Activity: 12
Merit: 0
May 10, 2014, 09:30:32 AM
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



did you tried using 13,12 modded drivers?

yes 13.12 = 13.12 modded

i uses 13.12 modded as the standard driver on all my 6 GPU rigs but with this particular miner for my R9 290s, it only works with 14.x drivers so for now i run it with 5 GPU.  13.12 modded works fine with my 6 GPU 79XX / 280X rigs though
full member
Activity: 289
Merit: 100
O2-Protocol.com Carbon Offset DeFi
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



did you tried using 13,12 modded drivers?
newbie
Activity: 44
Merit: 0
When are u releasing solo miner?
newbie
Activity: 12
Merit: 0
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

member
Activity: 103
Merit: 10
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
full member
Activity: 289
Merit: 100
O2-Protocol.com Carbon Offset DeFi
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)
ap1
newbie
Activity: 41
Merit: 0
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?
newbie
Activity: 56
Merit: 0
If your interested, i would be willing to host and manage the pool.

PM Me
hero member
Activity: 518
Merit: 500
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?
member
Activity: 70
Merit: 10
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.
newbie
Activity: 56
Merit: 0
excellent idea! solo mining  Huh
sr. member
Activity: 364
Merit: 250
Cheers man! Smiley
member
Activity: 70
Merit: 10
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 Wink
sr. member
Activity: 332
Merit: 250
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

So is anybody setting up a new pool with this code?
member
Activity: 70
Merit: 10
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

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.
sr. member
Activity: 479
Merit: 250
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
sr. member
Activity: 378
Merit: 250
yea dont give up! i am bored already
hero member
Activity: 736
Merit: 500
Same, dont give up!
Competition is great
newbie
Activity: 28
Merit: 0
Don't give up
full member
Activity: 430
Merit: 100
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!
Pages:
Jump to: