This is a bit off topic, and is probably something major that I should know, but why does p2pool use such high share difficulties?
No it is perfectly on topic. p2pool tries to maintain a 10s LP windows (10s between shares). This is a compromise. Shorter LP window = higher orphans. Longer LP window = higher difficulty. One way to look at it is p2pool is ~350 GH/s. At diff 1 shares that is ~81 shares per second or <0.01s between shares. Work would become stale before it even finishes propogating the network. So the difficulty is simply a compromise. It takes difficulty of ~800 to keep 350 GH/s producing 1 share per 10 seconds. |
|
|
|
When you exchange the heat into you warm water for your house you can make your rigs more efficient. This is what i am planning to do with the heat of my serverroom.... in germany its called luft-wärme-pumpe... in english it could be air-heat-exchanger (or something similar). your efficiency is even higher if you can exchange the heat of water to water....
Yeah that is the goal once this is done and stable. A water-water heat exchanger to preheat the cold water line of hot water heater. |
|
|
|
Given the can of motor oil on the shelf, I assume this is in your garage? Yeah. Any plans for a backup pump or will you just do software throttling?
No plans for backup pump at this point. I have the ability to cut power to the rigs (the reason among others for the watchdog server). I intend to install both a current transformer and flow meter. In a pump failure situation the relay board in the watchdog server will trip power on all 6 rigs. cgminer is already set to do software throttling (reduce clock @ 60C, idle thread @ 70C) but the "power kill" provides a further layer of protection. It likely isn't necessary but it does buy some piece of mind when you go $4K worth of GPU relying of coolant. This weekend I intend to waterblock some/all of the last 12 GPUs. God I am not looking forward to that.  |
|
|
|
My understanding is that > 98% of P2pool's DOA's have the potential to solve a block. The only ones that would not be useful are those DOA's that came right after a real block chain LP, ie once every 10 minutes. This also matches up well with the 1-2% of shares that regular pools reject, and I agree, 100% of these regular pool rejects are useless and have no chance of solving a block.
Your numbers don't make sense. You agree conventional pools have 1% to 2% stales due to bitcoin LP and invalid hashes. Let's say 1.5%. If 98% of p2pool DOA were NOT due to those reasons then 2% of them are. Thus 1.5%/2% = 75% it would have an overall DOA rate of 75%. For 98% of p2pool DOA to be due to 10 sec LP then it would need to have a DOA rate of 75%. Obviously the % due to 10s LP is much lower. If p2pool has a 4% DOA rate (??) and 1.5% of that is due to Bitcoin LP and invalid hashes then they make up ~40% of all DOAs. Still I think I was confused. p2pool doesn't track global DOA only global "stales" which if forrest can verify I believe is orphans only. One correction: The only ones that would not be useful are those DOA's that came right after a real block chain LP, ie once every 10 minutes. You are forgetting invalid hashes. No GPU produces 100% flawless hashes. Some % (0.1% to 1% depending on overclock, temps, ASIC quality, etc) are just bad. Nonsense hashes that solve no block. TL/DR version Conventional pool rejected shares = invalid hashes + stale hashes (after Bitcoin LP) p2pool DOA shares = invalid hashes + stale hashes (after Bitcoin LP) + "pre-orphaned" hashes (hash that would be 100% orphaned it submitted) Only the last one is valid work which can solve a block. |
|
|
|
They are only DOA with regard to the 10 second shares, but they are probably hashing away on a perfectly valid 10 minute real block. DOA simply means the share is invalid by the time the local node gets it. Don't make any assumptions beyond that. Conventional pools reject a sizable number of shares and they have no 10 sec LP. "Some" DOA may still be valid but not all of them are. And I see your point.. in the extreme case a terribly connected miner, who will never solve a real block, could be hashing away and getting say 50% stales and 50% DOA. The "horrible" miner is just an example. IF (and I am not sure they are) DOA are included in p2pool.info luck calculations they will skew them. |
|
|
|
It [SS incrementing with submit stale on] was fixed in 2.3.3
Thanks. I can confirm 2.3.4 is working on my system as expected. Donation coming your way. |
|
|
|
1) Someone modifies their p2pool code so they submit shares as normal but never submit a block. Stupid and unlikely, but theoretically possible.
2) Some obscure bug in some combination of bitcoind and p2pool, such that rarely a found block fails to be passed on to bitcoind (and yet shares and getworks continue to flow freely, the bug would have to only affect the case where it is an actual block solve)
Regarding #2 doesn't the local p2pool node pass the block to p2pool peers also. So a failure on one node's bitcoind would prevent block propagation. Now it may result in slower block propagation so we should see that in a higher block orphan rate (which we don't) rather than just lower luck. If I am mistaken and p2pool node doesn't do that this may be a way to make the network "stronger" so that the failure of one bitcoind can't lower block finding rate. |
|
|
|
|
Hmm. Let me try 2.3.3 on one of the rigs.
|
|
|
|
I wasn't suggesting Merrick1 for Bitcoin for those reasons. The cut down Merrick6 is a better board initially to talk about. Doing a derivate design for Bitcoin it could be possible to up the power supplies to support all devices by simply say removing DDR chips to make space. The 12A regulator circuit we use could fit into the space taken by 2 DDR chips and we could end up with 6/7 FPGAs each with 12A of core voltage.
That's all viable to do and that sort of design change could be done in a few days maybe a week. A prototype could be turned in about another week if we pushed although that fast gets expensive.
That would be an interesting option. If possible, a 4-pin Molex or SATA power connector might be more useful. I know a lot of my PSUs have 1 floppy power connector but a dozen SATA and 4-pin connectors. Or PCIe 6 pin connector. Most ATX PSU group all the MOLEX, SATA, and floppy connectors to a single rail because they are generally low current. Even single rail designs will use current limiting circuit for safety. So connecting a large number of boards to MOLEX connectors may be problematic. A 1000W PSU may have 980W of 12VDC but it may only have <200W on the rail powering MOLEX connectors. Even a single rail design will have some over current circuit on each "virtual rail" limiting the usable power on MOLEX connectors. |
|
|
|
|
Have you looked at other board offerings?
Various 2x Spartan 150 boards are available for ~$500
One 4x Spartan 150 board is available for ~$1000
Your price point is roughly double and the other Spartan boards face stiff competition from BFL which acheives roughly double the performance (MH/$). Your board would be in the ballpark of ~450 MH/s for $1000 vs BFL Single ~820 MH/s for $600.
A dual Spartan board for $1000 isn't going to fly.
|
|
|
|
I have submit stale also on also.
About 700 000 shares total submitted and SS still 0 like it should be.
What version of cgminer? I noticed that it doesn't affect my rigs running 2.1.2 but it does affect the ones running 2.3.1f & 2.3.2 |
|
|
|
|
If submit-stale = true (or pool is using submit-stale flag) shouldn't SS always be 0?
If submit-stale = true and SS is > 0 what is happening.
A) cgminer is not submitting share? err?
or
B) cgminer is.
B is less of a problem but it results in bogus stats. If share is submitted then it will either be returned as rejected (R count ++) or accepted (A count ++). If SS is also being incremented then the same share is being counted twice.
The reason I ask is I have submit-stale = true and lately have been noticing an SS count of > 0. It is a low % (say 0.5%) but it should always be 0 right?
On edit: so I looked at all my rigs. It seems only "newer" cgminer has SS > 0.
I have some rigs still on cgminer 2.1.2 (BAMT 0.4) they all properly show SS = 0 (one has been running 60 days w/ SS = 0).
I have some rigs on cgminer 2.3.1f (BAMT 0.5) they all have SS > 0.
|
|
|
|
ckolivas, it's your baby, do what you want with it. If I were you, I would just strip it down to the bare minimum, then run all the extra shit off of plug-ins. Want a different interface, use a different plugin, want support for super-duper-FPGA-miner-3000? Get someone to write a plugin for it. Want Luke and Kano to stop fighting? Let them write their own separate plugins.
You sir, wrote an great little piece of software, but you will never make everyone happy, don't try.
THIS. |
|
|
|
The dead shares are not relevant to the bad luck since they can actually solve for a block and result in everyone getting rewarded. P2Pool does look at them and double check if they solve a block before reporting back to cgminer as 'rejected'. Of course they are relevent. Most DOA can't solve a block. They are stale (due to bitcoind LP) or invalid. All pools have these (commonly called rejected). They are never included in luck calculations because they weren't good work to begin with. Say the average DOA rate is 3%. If those 3% of shares (unpaid, worthless work) are included in luck calculations that the expected # of blocks will be inflated by 3% making the pool appear to be 3% unluckier. No conventional pool includes rejected shares in their luck calculations. As an example of how invalid it is to include DOA shares I could point my miners towards a normal pool and have the found shares also submitted to p2pool. Obviously the shares wouldn't be valid for p2pool so it would be a 100% DOA rate. If the DOA rate is/was included in luck calculations then I made the pool appear x% unluckier. So I will ask again. 1) HOW does p2pool network know the DOA rate? 2) Are they included in p2pool.info luck calculations? |
|
|
|
|
How does the p2pool know the # of dead shares?
Aren't DOA shares detected at the node level, rejected, and then never forwarded to peers?
Do the p2pool.info charts include dead shares? If so they are slanting the luck measurements.
Note: the questions refer to dead, aka DOA, aka dead on arrival, aka "rejected" (in cgminer) not orphaned shares.
|
|
|
|
~$250 for a five-fold speed up on 1600 tests? Sounds a little cheap.
So you are going to pitch in x more and make it a little less "cheap"? |
|
|
|
But i mean is there a standalone OS that can handle more than 5-6 GPU's?
Both Windows & Linux can handle 8 GPUs but no more. |
|
|
|
The still unanswered question remains:
Is p2pool in fact statistically "working", in the sense that 100 Th will yield the [statistically] same amount of blocks as 100 Th on a single bitcoind or centralized pool?
Ente
I'm beginning to suspect not. back when the pool was at 91% luck over 90 days, the odds of it having such a poor reward after so much hashing was ~2%. It was never 2% when @ 91% luck over 90 days. I will run the probability numbers for current luck. |
|
|
|
|
Updated first post w/ more pics & details.
|
|
|
|
|
Sorry guys. By midnight EST. Guess I should have been more specific.
|
|
|
|
|
Show Posts
