Aber gerne ich konnts halt nicht recht glauben;)
Ist auch kurios. Der Saturn hatte ja mehr geliefert als eigentlich zu erwarten war. Zufälle gibt's. Ts.
Ein Problem ist auf jeden Fall, dass die KNC Miner nach einem gefundenen Block die bereits erhaltene Arbeit nicht verwerfen und stur weiter rechnen, was natürlich nur zu stales führt. Genau diesen Fehler hatte BFL bereits mit deren FPGAs gemacht
Das hatte ich gelesen - und gedacht, es wäre beim KnC inzwischen durch ein FW-Update behoben. Das wirkt sich dann natürlich richtig schlecht bei einem P2Pool aus.
Auch die Avalons hatten Probleme mit p2pool, da die Blöcke da ja nur 10 Sekunden (wenn ich mich recht erinnere) betrugen, durch Anhebung auf 30 sek kamen die Avalons dann besser zurecht.
Evtl. ist das auch noch ein Problem oder es gibt noch andere Gründe...
Sieht so aus. Im P2Pool-Thread wird das langsam deutlicher:
The fault lay with the hardware manufacturers, not p2pool, as p2pool was around long before they started making their ASICs. If all the newer hardware follows the same pattern, things will only improve, and old hardware becomes irrelevant very fast in this world anyway.
To forrestv's credit, he made a LOT of changes leading into the ASIC era, like beefing up stratum support, variable difficulty, clamping down on memory leaks and the longer blocks. There is ALWAYS more work to be done when the landscape is changing so fast in the bitcoin mining world, but it's clear the manufacturers till now have not put p2pool on their radar at all.
OMG what a flamer.
The ONLY trouble that HARDWARE has witch P2pool is that LP/work reset is making HARDWARE to stop hashing for like 10 sec, or HARDWARE is IGNORING LP/WR signals at all.
ANY thing that ckolivas or forrestv do will NOT help if HARDWARE is NOT working witch STANDARDS that are around like YEAR or more.
BE BLADE is working ONLY on diff=1 and are IGNORING LP signals.
KNC stuff are FREEZING for like 10sec every LP it got.
How our devs can fight that? Where we NOT have ANY access to BEB soft, and KNC just published miner sources few days ago... not even on git... Still if this is HARDWARE issue we cant do NOTHING to make those wrong designed ASICS to work properly on P2pool.
Looks like you re missing ROOT of the trouble. As one and only DECENTRALIZED pool P2pool has to manage some way to keep track of work done by miners and calculate payout in way, that cannot be forged, stolen or broken in any way. Bitcoin block chain is the way. P2pool is using 30 seconds blocks (shares) to keep track of work done by miners and allow every node to correctly calculate payout to all miners in SAME way. This is why we have LP/WR signal every 30s. In "normal" (centralized) pools this is done on one machine and LP is only on block change in bitcoin network - about every ~10 minutes.
So miner that is trying to mine on P2pool and freezing for ~10s every LP is "missing" ~30% of time. Miner that need ~10s to compute one WU and is also ignoring LP has 30% doa.
This is NOT P2pool fault but badly coded/designed miners. LP spec is there like 2 years now, so I not see ANY explanation for miner designers that they NOT implementing it in proper way.
Same is for stratum and vardiff that IS implemented in P2pool. If miner is NOT using it why blame pool?
Wenn's also letztlich am ASIC-Design liegt, ist KnC da erstmal raus. Offensichtlich ist das Design anderer Hersteller hier besser vorbereitet:
There is light at the end of the tunnel. Hashfast's ASICs will have a fast longpoll/block change/flush work implementation and it looks like Cointerra's will too.
Warten wir's ab.
p2pool ist halt recht speziell
Ja. Aber ein toller Ansatz. Nur leider keiner, den man mit einem KnC-Miner sinnvoll unterstützen kann.
