|
jtoomim
|
 |
October 12, 2015, 10:38:48 AM |
|
someone should hold leadership with this to say, guys, to put this and this is the best way for now... and even why not to vote for major changes and p2pool bitcoin.conf best template form
you as a provider of quite big part of p2pool hashrate would be that
I disagree. That would be centralizing p2pool. We all have to make our own decisions about how to configure and use this system. |
Hosting bitcoin miners for $65 to $80/kW/month on clean, cheap hydro power. http://Toom.im |
|
|
|
|
|
|
|
|
|
"In a nutshell, the network works like a distributed
timestamp server, stamping the first transaction to spend a coin. It
takes advantage of the nature of information being easy to spread but
hard to stifle." -- Satoshi
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
|
|
|
|
|
|
p3yot33at3r
|
|
October 12, 2015, 11:52:21 AM |
|
someone should hold leadership with this to say, guys, to put this and this is the best way for now... and even why not to vote for major changes and p2pool bitcoin.conf best template form
you as a provider of quite big part of p2pool hashrate would be that
I disagree. That would be centralizing p2pool. We all have to make our own decisions about how to configure and use this system. Exactly, plus no two setups will be the same - settings that work fine for one, might not work well for another. @ forrestv - if you're lurking - how is your testing of jtoomim's performance going? Nice to wake up to a block  |
|
|
|
|
|
idonothave
|
|
October 12, 2015, 01:35:20 PM |
|
someone should hold leadership with this to say, guys, to put this and this is the best way for now... and even why not to vote for major changes and p2pool bitcoin.conf best template form
you as a provider of quite big part of p2pool hashrate would be that
I disagree. That would be centralizing p2pool. We all have to make our own decisions about how to configure and use this system. Exactly, plus no two setups will be the same - settings that work fine for one, might not work well for another. @ forrestv - if you're lurking - how is your testing of jtoomim's performance going? Nice to wake up to a block disability to cooperate is not an advantage. we are here to learn |
|
|
|
|
|
p3yot33at3r
|
|
October 12, 2015, 01:54:08 PM |
|
Nice to wake up to a block ..make that 2 |
|
|
|
|
Meuh6879
Legendary
 Offline
Activity: 1512
Merit: 1011
|
|
October 13, 2015, 12:07:23 AM |
|
and 3 ...  |
|
|
|
|
Richy_T
Legendary
Offline
Activity: 2436
Merit: 2121
1RichyTrEwPYjZSeAYxeiFBNnKC9UjC5k
|
|
October 13, 2015, 02:54:41 PM |
|
Haha. I guess a bunch of the people who left will be flooding back. Probably for another dry spell.
Has anyone done any calculation as to how much fickle miners benefit those of us who stick with it?
|
1RichyTrEwPYjZSeAYxeiFBNnKC9UjC5k
|
|
|
windpath
Legendary
Offline
Activity: 1258
Merit: 1027
|
|
October 13, 2015, 03:01:09 PM |
|
Haha. I guess a bunch of the people who left will be flooding back. Probably for another dry spell.
Has anyone done any calculation as to how much fickle miners benefit those of us who stick with it?
No calculation, but it seems when we hit a streak of bad luck folks stay for 1 more block, then leave just before it changes back to good luck... Have the data to compair luck vs. # of miners, will run it sometime... |
|
|
|
|
Meuh6879
Legendary
Offline
Activity: 1512
Merit: 1011
|
|
October 13, 2015, 10:18:39 PM |
|
4 in less than 48 hours ...  THIS IS P2POOOOOOOOOOOOOOOOOOOOOOL ! |
|
|
|
|
|
p3yot33at3r
|
|
October 14, 2015, 10:20:11 PM |
|
Interesting. Can anyone tell me what nicehash have done to improve the bitmain firmware? |
|
|
|
|
|
idonothave
|
|
October 15, 2015, 06:34:58 AM |
|
Interesting. Can anyone tell me what nicehash have done to improve the bitmain firmware? imho nothing more then having a link on website with extranonce able firmware which created someone other |
|
|
|
|
|
p3yot33at3r
|
|
October 15, 2015, 11:58:14 AM |
|
Interesting. Can anyone tell me what nicehash have done to improve the bitmain firmware? imho nothing more then having a link on website with extranonce able firmware which created someone other Right. Won't install that then...I'll stick with my old firmware & ck binary. |
|
|
|
|
|
jtoomim
|
|
October 15, 2015, 06:52:08 PM |
|
Interesting. Can anyone tell me what nicehash have done to improve the bitmain firmware?
This firmware was not developed by Nicehash. It was developed by smit1237. Nicehash is just distributing it. There are a lot of changes. The cgminer version isn't the default broken Bitmain one, but instead a cgminer 4.8.0 that still submits stale shares. It might have a different default queue and expiry setting too, but I'm not sure about that. In my testing, it gives about 5% higher hashrate than the one S5s ship with on p2pool. The smit1237 firmware also allows you to upload custom cgminer binaries to /config/, where they will persist across reboots and will be used instead of the cgminer in (IIRC) /usr/local/bin/. |
Hosting bitcoin miners for $65 to $80/kW/month on clean, cheap hydro power. http://Toom.im |
|
|
|
p3yot33at3r
|
|
October 15, 2015, 07:21:52 PM
Last edit: October 15, 2015, 07:57:18 PM by p3yot33at3r |
|
Interesting. Can anyone tell me what nicehash have done to improve the bitmain firmware?
This firmware was not developed by Nicehash. It was developed by smit1237. Nicehash is just distributing it. There are a lot of changes. The cgminer version isn't the default broken Bitmain one, but instead a cgminer 4.8.0 that still submits stale shares. It might have a different default queue and expiry setting too, but I'm not sure about that. In my testing, it gives about 5% higher hashrate than the one S5s ship with on p2pool. The smit1237 firmware also allows you to upload custom cgminer binaries to /config/, where they will persist across reboots and will be used instead of the cgminer in (IIRC) /usr/local/bin/. OK, that sounds more like it. I might give it a go on one of my S5's & have a look-see what the queue & other settings are then, thanks for that info jtoomim  Edit: Just flashed it & queue is set at 8192  Searching for the parameters now to change it............ Edit 1: OK, changed the queue setting to 1 for testing. BEWARE: This firmware does not submit stale shares - I noticed the "no-submit-stale" parameter in the /etc/init.d/cgminer.sh file (line 69), so I deleted it as it is my understanding that the default cgminer setting will submit stales - very important for p2pool......I'll monitor it & report back later. |
|
|
|
|
|
jtoomim
|
|
October 15, 2015, 11:53:17 PM |
|
Edit: Just flashed it & queue is set at 8192 Searching for the parameters now to change it............ Edit 1: OK, changed the queue setting to 1 for testing. BEWARE: This firmware does not submit stale shares - I noticed the "no-submit-stale" parameter in the /etc/init.d/cgminer.sh file (line 69), so I deleted it as it is my understanding that the default cgminer setting will submit stales - very important for p2pool......I'll monitor it & report back later. Bummer. I'm pretty sure that not submitting stale shares is true for the default Bitmain firmware as well, though. |
Hosting bitcoin miners for $65 to $80/kW/month on clean, cheap hydro power. http://Toom.im |
|
|
|
p3yot33at3r
|
|
October 16, 2015, 12:11:23 AM
Last edit: October 16, 2015, 12:22:33 AM by p3yot33at3r |
|
Edit: Just flashed it & queue is set at 8192 Searching for the parameters now to change it............ Edit 1: OK, changed the queue setting to 1 for testing. BEWARE: This firmware does not submit stale shares - I noticed the "no-submit-stale" parameter in the /etc/init.d/cgminer.sh file (line 69), so I deleted it as it is my understanding that the default cgminer setting will submit stales - very important for p2pool......I'll monitor it & report back later. Bummer. I'm pretty sure that not submitting stale shares is true for the default Bitmain firmware as well, though. Yes, it is  After running a couple of hours I noticed the load was much lower with the smit firmware (down from ~2.6 to ~0.7!), making the GUI much more responsive, but the hash rate was very slightly lower. I changed the queue setting of 1 to 0 for a while & my DOA rate has reduced nicely (not that it was high anyway) with hardly any spikes - so I'm going to run it overnight & check it again in the morning. Very happy with the lower load readings though. Edit: If the results are OK in the morning I'll do a reboot to make sure the settings keep - if they do then it's all good & I'll update my other S5's |
|
|
|
|
kano
Legendary
Offline
Activity: 4494
Merit: 1808
Linux since 1997 RedHat 4
|
|
October 16, 2015, 02:45:14 AM |
|
Edit: Just flashed it & queue is set at 8192 Searching for the parameters now to change it............ Edit 1: OK, changed the queue setting to 1 for testing. BEWARE: This firmware does not submit stale shares - I noticed the "no-submit-stale" parameter in the /etc/init.d/cgminer.sh file (line 69), so I deleted it as it is my understanding that the default cgminer setting will submit stales - very important for p2pool......I'll monitor it & report back later. Bummer. I'm pretty sure that not submitting stale shares is true for the default Bitmain firmware as well, though. Be aware that the bitmain fork also intercepts stale work and drops it inside their driver code - before the main cgminer engine gets to see it and decide based on the command line options. ... as can be seen in their fork here: https://github.com/bitmaintech/cgminer/blob/master/driver-bitmain.c#L1274 |
|
|
|
|
p3yot33at3r
|
|
October 16, 2015, 03:49:05 AM |
|
Edit: Just flashed it & queue is set at 8192 Searching for the parameters now to change it............ Edit 1: OK, changed the queue setting to 1 for testing. BEWARE: This firmware does not submit stale shares - I noticed the "no-submit-stale" parameter in the /etc/init.d/cgminer.sh file (line 69), so I deleted it as it is my understanding that the default cgminer setting will submit stales - very important for p2pool......I'll monitor it & report back later. Bummer. I'm pretty sure that not submitting stale shares is true for the default Bitmain firmware as well, though. Be aware that the bitmain fork also intercepts stale work and drops it inside their driver code - before the main cgminer engine gets to see it and decide based on the command line options. ... as can be seen in their fork here: https://github.com/bitmaintech/cgminer/blob/master/driver-bitmain.c#L1274Bloody hell. Why bitmain, why?  Right, so what I need to do is replace the bitmain bork binary with the ck one at http://ck.kolivas.org/apps/cgminer/antminer/s5/ & drop it in /config/ in order to make it permanent after reboots - amiright? If so, I might need a little help with the commands on this one...... (linux amateur I am) |
|
|
|
|
Nevril
Member
Offline
Activity: 108
Merit: 10
|
|
October 16, 2015, 08:54:45 AM
Last edit: October 17, 2015, 01:41:13 PM by Nevril |
|
EDIT: after gathering enough statistics I've decided to turn down my node.
|
|
|
|
|
|
Polyatomic
|
|
October 16, 2015, 09:49:07 AM
Last edit: October 17, 2015, 09:57:06 PM by Polyatomic |
|
Hi, May I? what is It is optimized to serve miners with at least 1THs and, most importantly, it has been specifically tweaked to work without dead times on rented hashpower from NiceHash. exactly. |
|
|
|
|
Nevril
Member
Offline
Activity: 108
Merit: 10
|
|
October 16, 2015, 10:52:58 AM
Last edit: October 16, 2015, 01:47:46 PM by Nevril |
|
Hi May I? what is It is optimized to serve miners with at least 1THs and, most importantly, it has been specifically tweaked to work without dead times on rented hashpower from NiceHash. exactly. Basically it has a minimum share difficulty target higher than the default one provided by the vardiff algorithm of P2Pool. This solves the issue often encountered with NiceHash which turns a given hashpower order in dead state if the received (virtual) share difficulty is lower than 128. This happens also if you set a specific share difficulty when passing the username (btc_addr+diff). It this case mining starts, but then vardiff may turn down the difficulty, for example, at the starting phase or if the hashrate experience a drop. In all these cases the NiceHash order becomes dead and mining stops. The new minimum value has been chosen to serve miners that are capable of at least 1 THs (the minimum NiceHash order has 5 THs). EDIT: Now that I'm thinking of... I probably said something not so correct about the minimum needed hashrate to mine on my node since we are speaking of virtual share difficulty not actual. I need to re-think of it after I get some good sleep (and bed time is still far...), but either way the issue with NiceHash is actually solved and the local DOA is around 3% on average which is near what I was trying to achieve. I'll take a better look at it tomorrow morning, time to do my real work now! |
|
|
|
|
|
