Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool - page 140. (Read 2591920 times)

I think you can also just use the smit1237 firmware. If I remember correctly, if you want to use a custom cgminer with smit1237's FW, you just stick the new cgminer into /config (which is non-volatile) and that becomes the new default.

No, this is for the S5. 4.9.0 cgminer is working fine but I want to make it survive a reboot.

For which Antminer?  The S7?

Also, step 8 seems a bit off... you sure you want to tell people to brick their Antminers?

Interesting random fact: 9 of the last 20 p2pool blocks are BIP101.

From looking through the update code on the Antminer, it looks like it's a fairly straightforward process...

1)Obtain latest firmware
2)Unpack firmware
3)Uncompress RamFS image
4)Substitute custom cgminer for original cgminer
5)Recompress RamFS image
6)zip only new image into tgz file
7)Use upgrade page on the web interface to update
8)Cry over bricked antminer (?)

If anyone is interested in this and it works, I could put it for download somewhere.

Any other changes that might be worth slipping in?

no ! me NO greedy, want to harvest for the dry season. dry spell for over 4 days is no good

well im giving up on trying this vps and i have just booted my server 2x E5440 @ 2.83ghz 12gb of ram and 146gb hdd

going to install ubuntu and duck dns so my ip stays connected to the domain i have a good firewall in the house so im not worried about folk trying to hack in for my £0.01 in btc hahaha

hopefully will be up before i go away on holiday if not atleast i will have the ssh port and the 9332 9333 8333 ports open 

There was zero reason for him to inject the block size discussion into this thread, particularly the way he chose to do so. I have a side but I see no need to denigrate those who have a different opinion.

Ahh I see you're pushing XT for political reasons; backing MitGavin and GoogleHern.

So greedy. We just gave you one seven hours ago.

(It was from one of our nodes running jtoomim_performance on pypy on BitcoinXT, in case you're curious.)

just downloaded, running now to test it out ! thx for the upgrade running smoothly.

can we have more blocks ?

This isn't really the right thread or forum for that discussion. I'll give a brief bullet-point answer. If you want to have a conversation about this, we should probably move it to a different forum or a separate thread so as not to derail this one.

1. Because I think that large blocks are technically feasible, and will not make Bitcoin insecure, inaccessible, or excessively centralized.
2. Because I think that Bitcoin can handle much larger blocks (up to about 32 MB) and transaction volumes than we currently have without any code changes (except the block size limit) or exotic hardware.
3. Because I think that there are enough possible optimizations in both code and semi-exotic hardware to bring us safely up to 8 GB blocksizes in 5 years if we try hard, and in 20 years if we are lazy.
3. Because I think that BIP101 is better than BIP100 or any other proposal out there due to its simplicity, predictability, and because I think its growth rate is reasonable and unlikely to require later changes. BIP100 would be a distant second place in my opinion if it were implemented.
4. Because I think that large blocks are the most feasible method of paying miners enough in fees once the block subsidy drops below 12.5 BTC.
5. Because I do not think that consensus among developers is a reasonable method for making technical decisions for large or controversial projects.
6. Because I do not think that consensus among any group is a reasonable method for making political decisions, much less consensus among a subset of developers.
7. Because I like the way Gavin thinks about technical and political problems.
8. Because, although I think his conduct could be more gracious and polite, I think that Mike Hearn has been right about a lot of technical and political issues lately.

You can also see some of my comments on the issue here:

https://www.reddit.com/user/jtoomim/

Thanks. I don't think those instructions are directly relevant but they point in the right direction. Looks like I'll need to cook up my own cramfs

Yes it is, I just can't figure why he's pushing XT? Anybody with the technical skills to re-code p2pool with a 42% improvement in speed should have the good sense to stay away from this XT nonsense.

That's a big improvement - impressive 

Tying it out now.

CPU usage results for pypy vs python using branch jtoomim_performance of p2pool after 21.7 hours:

Regular python:
68 minutes 3 seconds, 5.22% average

pypy:
39 minutes 20 seconds, 3.82% average

That's 42% lower CPU usage for pypy.

This is multiplicative with the jtoomim_performance benefit, so using the jtoomim_performance branch with pypy has about 65% lower CPU usage than using the head branch with regular python.

Test conditions: Core i7 4790k processor, 12 peers, 76 to 80 TH/s load (SP30s). Both nodes were run on the same server at the same time, with a local BitcoinXT bitcoind.

read this: https://bitcointalksearch.org/topic/best-undervoltunderclock-for-s4-882402
there is howto set cgminer fixed after restart for S4. with another bitmain devices it should be similar

Getting weird chain info with that version of cgminer. Hashrate seems to be sane though so I may leave it for now. (Apologies for the poor formatting.)

Chain#    ASIC#    Frequency    Temp    ASIC status
1 30 350 63 oooooo oooooooo oooooooo oooooooo
2 113 350 59 xxxxxxxxxx xxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xooooooo oooooooo oooooooo oooooooo

Any way to make the cgminer change permanent?

Edit: Restarting cgminer fixed the chain weirdness.

  and my question : you use a REMOTE P2Pool node (with others mining devices) or a LOCAL P2pool ?










it's a critical question.

S7s do not work well on p2pool. Until someone comes up with a new version of cgminer for the S7, they will lose hashrate when run on p2pool. I suggest moving it onto a traditional pool at least for testing.

However, in my testing, they only lose about 300 GH/s, not 2500 GH/s. I suspect something else may be wrong as well.

You're getting a high HW error rate, over 1%. Your power supply might not be putting out enough voltage (should be above 12.0 V, and ideally probably around 12.3 V), or you might have bad hardware. If you can't adjust your power supply's output voltage, I suggest you try reducing the clock speed as well to see if that reduces the HW error rate and improves hashrate.

simmilar solution as with S4? set minimal difficulty?