 Show Posts
|
|
Pages: [1] 2 3 4 »
|
If you change TARGET in .cl files, make new kernel.bin then your CPD in stats also will change. edit: 270X settings for DTC: #define SIZE 4096 // Size of local sieve array (must be multiple of 1024)
#define LSIZE 256 // Local worksize for sieve (don't change this)
#define STRIPES 400 // Number of sieve segments (you may tune this)
#define WIDTH 20 // Sieve width (includes extensions, you may tune this)
#define PCOUNT 38400 // Number of sieve primes (must be multiple of 256, you should tune this, 40960 is for 280X)
#define SCOUNT PCOUNT // Don't change it
#define TARGET 9 // Target for s_sieve
If you change target to 9 you need to use the latest *.cl files from git, 6 days ago. Otherwise you have bugs... Also you may have to reduce STRIPES to maybe 150, otherwise the miner crashes because the sieve now returns 3 times more candidates. |
|
|
|
Hello,
Anyone tested on old GPU like HD-5970?
try it out works on 6970/50 While it may work, pre GCN cards are bad at primecoin mining, there's no way around it. |
|
|
|
2 MadMax
the solo-mining server
At what address wallet coins will come in the case of finding the block.
What percentage of a developer?
no dev fee inside. The patched wallet probably can use the blockchain and keys on the same system where you installed the official wallet. Else, it will be a new address Yeah, it's a new address for each block, just like the original code. And yes, there is no dev fee. |
|
|
|
Link for linux version fixed, thanks for reporting. Linux xpmserver: https://mega.co.nz/#!NZAHWC6b!FyeF6aKZ32KPs_Ns0NwZsEGaOWkNAlwfSz76hO-Dg_kEDIT: Guys please, targeting 11-chains is only more profitable when diff >10.99 at least (sunny king ain't stupid and my calcs show this also) Currently the miner does not support uneven targets (resulting in wrong CPD readings) because i didn't expect anyone to go for 11 anytime soon. However supercomputing is testing a fix right now, so we'll see. |
|
|
|
NEWS: I've finished the solo-mining server. Good  But it can't work with standard primecoin client from official site. Why? I've tested and it works. Next (experimental) patch https://www.dropbox.com/s/q9kzdvpl0rx8rf3/patch_v4.tar.gz[GPU 0] T=-1C A=-1% E=0 primes=0.102244 fermat=710117/sec cpd=7.66/day
[GPU 1] T=-1C A=-1% E=0 primes=0.102266 fermat=741074/sec cpd=8.01/day
[GPU 2] T=-1C A=-1% E=0 primes=0.102105 fermat=702950/sec cpd=7.48/day
Nice job |
|
|
|
NEWS: I've finished the solo-mining server. The solo-mining server code is at: https://github.com/madMAx43v3r/xpmserverThe solo-mining server binaries can be downloaded at: For Windows: https://mega.co.nz/#!hRAmGRAQ!cbYlm-meXprzImw-vQ5COnBQiWtgPFXJeJtTs-041AIFor Linux: https://mega.co.nz/#!NZAHWC6b!FyeF6aKZ32KPs_Ns0NwZsEGaOWkNAlwfSz76hO-Dg_kNote: The windows version crashes on shutdown, have not been able to fix this. The binary zips also include a README.txt you should check out to get started. EDIT: If you have dynamic ip: There is a bug somewhere in the bitcoin network code that can cause the server to loose all connections to the network after your external ip has changed. It will still show 8 or more connections but if you look in debug.log you will no longer see new blocks or transactions. In this case you need to restart the server. The chance of this bug to happen is around 50%. So be careful, if your external ip changes and you don't check the server and the bug has happend you will produce 100% orphan blocks. |
|
|
|
Yeah, looks like my fermat test wasn't top of the line  Was working on the solo miner, but since Claymore is now faster, don't need to bother really. Let's see if eXtremal can match claymores speed. |
|
|
|
|
Just realized how important this is.
Will start working on solo miner first thing tomorrow. It will be a stripped down version of the pool server, without database, without website, but with Qt GUI.
And you can connect the existing pool miner to it just like it was a pool server.
I'll try to push for a same day release, but no gurantees.
|
|
|
|
|
xpmpool repo has just received a fix, the Makefile for leveldb was incorrectly ignored and thus was missing in the repo.
EDIT: I've also updated the README.md with more info.
|
|
|
|
|
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.
|
|
|
|
You can be proud of your self making the best miner, even more for this decision. 30 XPM donated.
Thanks, have received it. |
|
|
|
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.htmA 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.htmlIt'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.htmlhas 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  |
|
|
|
would be cool if he made a solo release so we can use it now like cgminer with a donation address attached to pay for improvements
If in 2 days nobody has done so (with open source), i will do it. great would be cool if u made it cgminer like where we can set temps clocks etc Well i'm using cgminer ADL code anyways, so shouldn't be that hard to enable those features. |
|
|
|
would be cool if he made a solo release so we can use it now like cgminer with a donation address attached to pay for improvements
If in 2 days nobody has done so (with open source), i will do it. |
|
|
|
Wow mate you are really something else you know that. Good move you definitely belong in this space in my opinion, good luck and i'm donating 280xpm cause that was a bloddy good move. You are a real man! and you are wise because this is how you breath life into xpm possibly...wait till mike gets a hold of this code Thanks man, have received the 280 XPM. Who is mike? |
|
|
|
NEWS: I've decided to go open source. See the official thread: https://bitcointalk.org/index.php?topic=602292.0EDIT: 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. |
|
|
|
Maybe you know me from my other thread where i launched a new XPM pool + GPU miner: https://bitcointalk.org/index.php?topic=598542.0If yes, you also know that it failed because of DOS attacks and other general server problems. I've now decided to go open source, with the pool server and the GPU miner. Now everyone with the expertise can create an XPM pool and also create new miners that work with the same protocol. Also anyone with basic bitcoin code knowledge can make a solo-miner out of it. EDIT: It's now available. The pool server code is located at: https://github.com/madMAx43v3r/xpmpoolAnd the GPU miner code is at: https://github.com/madMAx43v3r/xpmclientUPDATE: The solo-mining server code is at: https://github.com/madMAx43v3r/xpmserverThe solo-mining server binaries can be downloaded at: For Windows: https://mega.co.nz/#!hRAmGRAQ!cbYlm-meXprzImw-vQ5COnBQiWtgPFXJeJtTs-041AIFor Linux: https://mega.co.nz/#!NZAHWC6b!FyeF6aKZ32KPs_Ns0NwZsEGaOWkNAlwfSz76hO-Dg_kNote: The windows version crashes on shutdown, have not been able to fix this. EDIT: If you have dynamic ip: There is a bug somewhere in the bitcoin network code that can cause the server to loose all connections to the network after your external ip has changed. It will still show 8 or more connections but if you look in debug.log you will no longer see new blocks or transactions. In this case you need to restart the server. The chance of this bug to happen is around 50%. So be careful, if your external ip changes and you don't check the server and the bug has happend you will produce 100% orphan blocks. Please use this thread to discuss and/or ask questions about the code. If you like my work you can donate XPM to: ATHHPkcWjhUSqXpgJhTut7jzWo3JEbNj9J |
|
|
|
|
Server is now crashing consistenly. Some bug in bitcoin function ConnectSocketDirectly is causing the issue.
This is just too much, i've been baby sitting this thing for over 48h straight now.
FINAL UPDATE: The pool will close. All balances will be PAID once they are mature. I WILL release a solo miner.
Need to sleep now...
|
|
|
|
|
Doing a server restart, something aint right...
|
|
|
|
...
(Or it is shown as height 532231 instead?)
Yep |
|
|
|
|
