|
are there historic stats available via the API? I wonder if you could log stats then graph them to see temp v hash v hw v diif etc over time.
If not then mm could simply collect the samples it gets and plot those.
|
|
|
|
|
hey mdude, just some feedback.
I now have the monitor open with 1 second refresh as a live view of hash and error/reject rates. the api makes this possible.
thanks for adding that in and thanks for the updates.
|
|
|
|
Hi, I've read through a good chunk of this thread and wanted some guidance or at least to clarify some things.
I am running S1s and S2s and have only recently come across this thread. I have had a little look at the CGMiner source code, most of which is beyond me at the moment but I haven't delved that deeply yet.
First question, there is mention that Bitmain's S1 (and S2) drivers have a few flaws and kano recommends using his (for the S1 so far anyway). If I load kano's latest version of CGMiner onto my S1s is that issue addressed and can be forgotten about?
Secondly I would really like to compile a version of CGMiner from the source and load it onto one of my S1s, even if it is just a copy of an existing version. Can this be compiled on anything (e.g. Windoze 7) or does it need to be compiled on Ubuntu to then run on the S1? Once I have a machine that is set up to compile CGMiner successfully so it can be loaded onto an S1, I want to delve deeper into the workings of CGMiner (not that there will probably much benefit to that, it is more out of interest). I have MinGW etc. on my system and there appear to be a couple of issues building CGMiner on it but haven't really looked into that yet as there is little point if I can't then run it on the S1.
Any help would be greatly appreciated.
as I understand it Kano's patch makes more of a difference in regards to p2pool mining and you need to build it (cgminer, not necessarily kano's driver as it's prebuilt for the S1) on the same flavour of Linux. in this case openwrt and there are guides if you just search build cgminer on openwrt |
|
|
|
it obviously got broken again or there is some requirement we are missing. |
|
|
|
So now that there are more eyes looking at P2Pool's code... and talk of brainstorming the BIG fix items like variance for smaller miners... I'd like to make a teensy tiny request... from forrestv, the Templar Crypto Research team, or anyone really... Could someone fix the Memory Usage graph so that it can actually work on anything other than Linux? This is what it looks like on a Mac and Windows (minus my big red arrow and commentary):  Haha I run windows servers and have the same issue. I'm also lucky enough to not really be resource restrained so not a huge issue for me. I agree it would be nice but you'd have to write WMI for windows and god knows what for mac. Essentially though mac is Linux, well close enough, so the task should be somewhat easier. I was looking at some powershell stuff to feed into the p2pool front end to report on server stats but my coding knowledge just isn't that great. |
|
|
|
Another thing I'd add to the list...
Fix being able to get lots of transactions without GetBlocktemplate Latency going through the roof. OR something that alleviates the problem. Long term p2pool isn't going to cut it if it can't get transactions.
M
Is that reliant on bitcoind only or also peers? I've been doing some tuning of bitcoind but struggle to keep it below 0.5 secs and not topping 1s. Is that a bitcoind issue or a p2pool issue? Its not p2pool issue, use ssd disk and should be able to put blockprioritysize=0 #blockminsize=2000 blockmaxsize=1000000 mintxfee=0.00001 minrelaytxfee=0.00001 With just 0.2s, with merged mining namecoin, fusioncoin, ixcoin and devcoin i'm using fc disk and large caching. I've not seen blockprioritysize=0 before. that does that do? also do you set maxconnections? If i put maxconnections over 20 bitcoind starts to upload blocks with all upload bw, so I keep it 19 blockprioritysize=0 prevents 0 fee transactions thanks, I've just set blockprioritysize and it looks like latency is down lower than its been. now around 0.2~0.3 but will monitor. ive got maxconns at 20. did you find that extra 1 really made a difference? I have a 50mbit fibre link that achieves up to 70mbit up so I don't think i'll have any bandwidth issues with maxconns. |
|
|
|
Another thing I'd add to the list...
Fix being able to get lots of transactions without GetBlocktemplate Latency going through the roof. OR something that alleviates the problem. Long term p2pool isn't going to cut it if it can't get transactions.
M
Is that reliant on bitcoind only or also peers? I've been doing some tuning of bitcoind but struggle to keep it below 0.5 secs and not topping 1s. Is that a bitcoind issue or a p2pool issue? Its not p2pool issue, use ssd disk and should be able to put blockprioritysize=0 #blockminsize=2000 blockmaxsize=1000000 mintxfee=0.00001 minrelaytxfee=0.00001 With just 0.2s, with merged mining namecoin, fusioncoin, ixcoin and devcoin i'm using fc disk and large caching. I've not seen blockprioritysize=0 before. that does that do? also do you set maxconnections? |
|
|
|
Dear all, development of p2pool has sparked up again and there are several developers working on some new features and fixes, including the lead dev forrestv. Starting from here https://bitcointalk.org/index.php?topic=18313.9100 there is much discussion about where it can go and what needs to happen to make it more feasible in regards to large and small miners and variance. I think in the coming months we might see a truly viable new model for how Bitcoin is mined. |
|
|
|
Since I had a little bit of time... here's v2.1. Lots of little things. v2.1 - Added some more error handling and debug code around the API logic. - Enabled alerts for the web screenscraping logic (non API). - Fixed a typo that would complain about an S2 temp alert not being set when it was S1 turned on not S2. - Visual change to make it clear how to add Ant addresses, and the local IP address is for scanning, nothing else. - Added an email governor to prevent email alert spam. Set to this minimum time between EMail alerts. Note this runs by Ant, and defaults to 10 minutes. - Added a difficulty column to the Ant output grid. It assumes the last difficulty for the first "Alive" pool is the right one. - Added the ability for it to remember column positions. - Added single instance logic, to prevent you from accidentally running more than one at a time. Download link: MAntMonitor21.zipM Thanks for the update! |
|
|
|
Another thing I'd add to the list...
Fix being able to get lots of transactions without GetBlocktemplate Latency going through the roof. OR something that alleviates the problem. Long term p2pool isn't going to cut it if it can't get transactions.
M
Is that reliant on bitcoind only or also peers? I've been doing some tuning of bitcoind but struggle to keep it below 0.5 secs and not topping 1s. Is that a bitcoind issue or a p2pool issue? I thought anything more than 0.1 sec is too high? If that's wrong I'll adjust my settings.. M Well my node seems fine with anything up to 1s. I only have 1 orphan out of 13. www.norgzpool.net.au |
|
|
|
I have a programmer and 2 computer science / mathematics major interns going over the code this weekend should know more on Monday about the full scope of what needs to be fixed / implemented and a rough timeline hopefully, **fingers crossed**
Don't forget we have this http://p2pminers.ideascale.com/ to help identify ideas and help collaborate. If we can identify issues and assign them to devs as well as using github, we can hopefully avoid duplication of effort. |
|
|
|
Another thing I'd add to the list...
Fix being able to get lots of transactions without GetBlocktemplate Latency going through the roof. OR something that alleviates the problem. Long term p2pool isn't going to cut it if it can't get transactions.
M
Is that reliant on bitcoind only or also peers? I've been doing some tuning of bitcoind but struggle to keep it below 0.5 secs and not topping 1s. Is that a bitcoind issue or a p2pool issue? |
|
|
|
Me and my development team here at Templar Crypto Research currently are analyzing the code of p2pool to see the viability of implementing fixes as well as new features such as a gui as well as some of the requested changes, hopefully it shouldn't be to difficult
Great to hear and look forward to your input. |
|
|
|
|
I managed to generate 14money and 1norgan overnight. Anything longer starts to quite weeks and years. Also use -I on vanitygen so it doesn't worry about case as that adds quite a bit of time to find one.
|
|
|
|
As jedimstr said, I did receive a sizable donation from the Litecoin foundation, and I have since been brainstorming and prototyping ways to fix the core problems with P2Pool - scalability and excessive variance for small miners. I prototyped a way to do trustless verification of blocks with O(1) storage so that we could free most P2Pool nodes from needing a local *coin node. I've spent a ton of time thinking of ways to implement parallel sharechains so that we can have shares more often, decreasing variance for small miners, while decreasing the strict latency requirements for hardware, sadly without any concrete results yet. Because this is a hard problem. I spent hundreds of hours in the summer of 2011 thinking about how P2Pool could possibly work, in a time before merged mining or pools with coinbase payouts even existed. Any further improvements that get us out of this local maxima that we're stuck in will require comparable amounts of thought. Some relief though - a few days ago, when people prodding renewed my eagerness, I may have made a breakthrough in ideas for how to get parallel sharechains to work (which I discussed in #p2pool). Despite that, it is hard to work on this project when most people insist on cutting off the pool donations to me. When I see guides telling people to use --give-author 0 without any mention made of what it does, people blindly following them, or people asking me for help, providing screenshots of them running P2Pool with donations disabled, it hurts a bit. Actually, more than a bit. Right now, I get 0.09% of the revenue from P2Pool due to node donations (which default to 1%), which likely means that about 90% of people have completely disabled donations. That doesn't result in much revenue. Just today I spent about 10 hours getting http://p2pool.info/ working, which is the equivalent of two weeks of pool donations - if I were being paid minimum wage! I don't have a job (I am a student) and I do have other side-ventures that I'm working towards that look a bit more optimistic, so pardon me for rationally allocating my free time. I don't believe anybody disabled donations because of a lack of development - pool donations have been comparably low for a very long time, since before this development hiatus - so I don't think I'm being "punished" for not working hard enough or obviously enough. I don't think that most miners ever think about their donation amount again after setting it or pay attention to development. (I don't blame them for not dedicating their lives to tweaking P2Pool.  ) But this is vicious downward cycle and anyone running P2Pool with donations lower than the default while demanding improvements (or even planning to use P2Pool for an extended amount of time) is a hypocrite. It's simply a lack of foresightedness when miners decide to prioritize an amount of income that is invisible in the noise of variance of P2Pool payouts over the sustainability of P2Pool. Perhaps we'd be better off if I hadn't changed the mandatory 0.5% fee to an optional 0.5% donation (does anyone here even remember that?). I do plan to continue working on P2Pool, and eventually great changes will happen. Unless something changes though, don't expect it to happen too quickly, and don't be surprised if people who disable donations get bugged a bit more when they start P2Pool (or with any other similar change to increase donations). Thank you Forrestv, i'll update the code at p2poolinfo.azurewebsites.net as soon as I get a chance. Appreciate getting it working. Thanks for coming here and updating everyone, although not all will be satisfied with this. I fear the only thing that will silence the critics will be the release of some new p2pool code. I'm glad some of my prodding has spark some more interest and follow with great interest. I think we node operators should promise to turn on donations once we get some fixes through if not now. I'll be looking at my nodes and adding a donation back in also. |
|
|
|
3. Vertical scalability that reduces variance for all miners.
This is where the real challenges lie.
For p2pool to support large mining operations, and still be able to attract medium, small, and micro miners we need completely new share difficulty and payout structures.
The first step here has nothing to do with code, some completely new concepts need to be developed and generally accepted by p2pool miners. Once we have those concepts down, and can demonstrate them to be technically possible, we can seek out devs with the chops to pull it off.
This may seem like no big deal, but I assure you it is. Here is my first crack at it:
Payouts
While miners meeting a certain threshold could still be paid directly from the generation TX, smaller miners under the payout threshold when a block is found, lets say BTC0.01 to start, would be able to see their p2pool earnings down to the Satoshi in real time, but would not receive a payout until reaching the threshold.
We (read as: nonnakip) are currently developing pretty much this exact thing right now for our node at nastyfans.org:9332. We have been calling it P2Pool PPS... Cool, is this something you will submit back to github? |
|
|
|
|
Show Posts
