Hey everyone, I'm having an error with my P2Pool node. It says. Warning: A MAJORITY OF SHARES CONTAIN A VOTE FOR AN UNSUPPORTED SHARE IMPLEMENTATION! (v13 with 52% support) An upgrade is likely necessary. Check http://p2pool.forre.st/ for more information.
Any ideas what the problem is?
Thanks in advance.
The pool info is located here.
https://bitcointalksearch.org/topic/2ghs-official-coinchat-mining-pool-thread-252455
Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool - page 514. (Read 2591928 times)
Pool rate and the version 11 rate have been dropping with a fairly constant slope, without returning as version 13 rate. Curious.
I upgraded to p2pool 13.1 and it works great!
Question though, when I run it, version is reported as this:
Version: unknown 666f7272657374762d7032706f6f6c2d38333235366538
Is this the correct version? I installed the p2pool 13.1 snapshot from Github (downloaded the snapshot tarball itself, did not use Git to pull the source).
Thanks!
Josh
Question though, when I run it, version is reported as this:
Version: unknown 666f7272657374762d7032706f6f6c2d38333235366538
Is this the correct version? I installed the p2pool 13.1 snapshot from Github (downloaded the snapshot tarball itself, did not use Git to pull the source).
Thanks!
Josh
how many percent was updated? where can we see? can wait for the switch.
The "desired versions" graph shows this.
almost 33% on bitcoin and 20% litecoin so far.
On 1 good share it is normal.
It may not be fast but boy I like this stat:
308MH/s (0.0% DOA)
Efficiency 123.3%
308MH/s (0.0% DOA)
Efficiency 123.3%
how many percent was updated? where can we see? can wait for the switch.
The "desired versions" graph shows this.
Hi,
Do you have compatible stratum mining proxy as Windows binary? I need it for litecoin mining, but mining_proxy 1.3.0 from guiminer-scrypt is not compatible with p2pool.
Thank you in advance!
Do you have compatible stratum mining proxy as Windows binary? I need it for litecoin mining, but mining_proxy 1.3.0 from guiminer-scrypt is not compatible with p2pool.
Thank you in advance!
Hey Kano,
Check this out:
https://github.com/luke-jr/BitForce_SC/blob/e9e6a41fd76050a3aea2ab973c808f4cede174eb/BitForce_SC/HostInteractionProtocols.h#L42
ZPX (custom nonce range) and p2pool is programed into the firmware, it's just not hooked up (missing below):
https://github.com/luke-jr/BitForce_SC/blob/master/BitForce_SC/Main_BitforceSC.c#L424
...
ZPX has always been there, but as I said in my post on the BFL forum:Check this out:
https://github.com/luke-jr/BitForce_SC/blob/e9e6a41fd76050a3aea2ab973c808f4cede174eb/BitForce_SC/HostInteractionProtocols.h#L42
ZPX (custom nonce range) and p2pool is programed into the firmware, it's just not hooked up (missing below):
https://github.com/luke-jr/BitForce_SC/blob/master/BitForce_SC/Main_BitforceSC.c#L424
...
https://forums.butterflylabs.com/announcements/913-bitforce-sc-communication-protocol-draft-revision-2-a-8.html#post31853
there needs to be a que job version like ZNX with a nonce range but more importantly a que job pack version like ZWX with a nonce range
My comment about ZPX is here:
https://forums.butterflylabs.com/announcements/913-bitforce-sc-communication-protocol-draft-revision-2-a-10.html#post37469
You can see in graphs
how many percent was updated? where can we see? can wait for the switch.
I'd also like to know what percentage of the network has upgraded. Based on http://p2pool-nodes.info/, its 96 nodes are still at < v13.0 and 32 at > v13.0, so around 25%.
how many percent was updated? where can we see? can wait for the switch.
Hey Kano,
Check this out:
https://github.com/luke-jr/BitForce_SC/blob/e9e6a41fd76050a3aea2ab973c808f4cede174eb/BitForce_SC/HostInteractionProtocols.h#L42
ZPX (custom nonce range) and p2pool is programed into the firmware, it's just not hooked up (missing below):
https://github.com/luke-jr/BitForce_SC/blob/master/BitForce_SC/Main_BitforceSC.c#L424
and here's the callback:
https://github.com/luke-jr/BitForce_SC/blob/e9e6a41fd76050a3aea2ab973c808f4cede174eb/BitForce_SC/HostInteractionProtocols.c#L2320
notice:
also the comment in Main-BitforceSC.c
it looks like it was in and working but removed...
initial code had lots of p2pool support
https://github.com/luke-jr/BitForce_SC/blob/f569b10e05ff468e823b2e44573cd9cdda6b6850/BitForce_SC/Main_BitforceSC.c
EDIT:
And here is the commit p2pool was removed from the firmware
https://github.com/luke-jr/BitForce_SC/commit/73590d015c614c8b40bf8a8fe25de7169c347c53
EDIT2:
ZPX doesn't seem to help too much either since it's independent of queue
https://forums.butterflylabs.com/announcements/913-bitforce-sc-communication-protocol-draft-revision-2-a-10.html#post37469
looks like i'm going back to finding a way to hardcode in a reduced nonce range to the SCs...
Check this out:
https://github.com/luke-jr/BitForce_SC/blob/e9e6a41fd76050a3aea2ab973c808f4cede174eb/BitForce_SC/HostInteractionProtocols.h#L42
ZPX (custom nonce range) and p2pool is programed into the firmware, it's just not hooked up (missing below):
https://github.com/luke-jr/BitForce_SC/blob/master/BitForce_SC/Main_BitforceSC.c#L424
and here's the callback:
https://github.com/luke-jr/BitForce_SC/blob/e9e6a41fd76050a3aea2ab973c808f4cede174eb/BitForce_SC/HostInteractionProtocols.c#L2320
notice:
Code:
ASIC_job_issue(p_job,
p_job->nonce_begin,
p_job->nonce_end,
FALSE, 0, FALSE);
p_job->nonce_begin,
p_job->nonce_end,
FALSE, 0, FALSE);
also the comment in Main-BitforceSC.c
Code:
/* BUG FIX LOG
* ------------------------------------------------------------------------------------------------
* July 3rd 2012 - Fixed the P2P JOB problem (range_end - range_begin, which was inverse)
* June 2nd 2012 - Realized the system must run a 16MHz to ensure compatibility with flash SPI
*
*/
* ------------------------------------------------------------------------------------------------
* July 3rd 2012 - Fixed the P2P JOB problem (range_end - range_begin, which was inverse)
* June 2nd 2012 - Realized the system must run a 16MHz to ensure compatibility with flash SPI
*
*/
it looks like it was in and working but removed...
initial code had lots of p2pool support
https://github.com/luke-jr/BitForce_SC/blob/f569b10e05ff468e823b2e44573cd9cdda6b6850/BitForce_SC/Main_BitforceSC.c
EDIT:
And here is the commit p2pool was removed from the firmware
https://github.com/luke-jr/BitForce_SC/commit/73590d015c614c8b40bf8a8fe25de7169c347c53
EDIT2:
ZPX doesn't seem to help too much either since it's independent of queue
https://forums.butterflylabs.com/announcements/913-bitforce-sc-communication-protocol-draft-revision-2-a-10.html#post37469
looks like i'm going back to finding a way to hardcode in a reduced nonce range to the SCs...
P2Pool release 13.1 - commit hash: 94b87f6c9c04c292bca9565961f83198438f0f76
Windows binary: http://u.forre.st/u/xmqipwes/p2pool_win32_13.1.zip
Windows binary signature: http://u.forre.st/u/apxlhewu/p2pool_win32_13.1.zip.sig
Source zipball: https://github.com/forrestv/p2pool/zipball/13.1
Source tarball: https://github.com/forrestv/p2pool/tarball/13.1
Changes:
The hardfork hasn't happened yet, and this release fixes a potential problem that could cause people mining with non-standard transaction inclusion options to have their shares orphaned more often.
Windows binary: http://u.forre.st/u/xmqipwes/p2pool_win32_13.1.zip
Windows binary signature: http://u.forre.st/u/apxlhewu/p2pool_win32_13.1.zip.sig
Source zipball: https://github.com/forrestv/p2pool/zipball/13.1
Source tarball: https://github.com/forrestv/p2pool/tarball/13.1
Changes:
The hardfork hasn't happened yet, and this release fixes a potential problem that could cause people mining with non-standard transaction inclusion options to have their shares orphaned more often.
The new P2Pool is frequently freezing up and using 50% CPU for a minute at a time.
Update: Restarting them along with the node after the initial share download fixes it. I've repro'd this issue on 2 machines.
Update: Restarting them along with the node after the initial share download fixes it. I've repro'd this issue on 2 machines.
Considering BFL have been too lazy to make P2Pool a consideration, they really should throw some of that BTC1000 donation fund they setup towards forrestv, cg and bfgminer teams for doing this work for them.
They just don't care. Josh doesn't even know what is p2pool. This perfectly fits his "money printing" conception. They should start shipping standalone miners with pre-set standard config: main pool Guild, backup pool 50BTC, option to set your MtGox and bank account, so after quick configuration you just power it up and receive USD straight to your account, and forget about bitcoins
Considering BFL have been too lazy to make P2Pool a consideration, they really should throw some of that BTC1000 donation fund they setup towards forrestv, cg and bfgminer teams for doing this work for them.
I just look at the original of 1.2.5 from Nasser, but yeah with a few minor changes in there you could make it hash a fraction of a nonce range every time instead of the full range.
The only (minor) catch is that of course you are sending n times the amount of work and generating n times the amount of work in cgminer.
It becomes a major catch if you are dividing it too much.
You'd also have to change my FULLNONCE definition in driver-bflsc.c (around line 77)
The only (minor) catch is that of course you are sending n times the amount of work and generating n times the amount of work in cgminer.
It becomes a major catch if you are dividing it too much.
You'd also have to change my FULLNONCE definition in driver-bflsc.c (around line 77)
great summary by Kano on BFL forums, https://forums.butterflylabs.com/announcements/3282-bitforce-sc-firmware-version-1-2-5-a-5.html#post46125
Quote from: kano
I job per chip is worse, not better (for p2pool) 
However if it runs 50% faster, well I guess that doesn't matter
Anyway,
the biggest issue with the MCU design in the FPGA was that it doesn't give you an answer until it completes the work.
The SC does the same thing.
So e.g. with 10 chips doing 4GH/s each, instead of getting 1 answer in 0.093 seconds, you get 10 answers in 0.93 seconds.
Thus latency is worse with the 1 job per chip firmware.
As I have said elsewhere (since 20-Jun), the simple fix is grade school maths level:
Divide the job up based on the speed of each chip, not give each chip it's own job, faster chips get a larger nonce range, slower chips get a smaller range.
Basically, set it so that all chips complete about the same time based on their performance.
The total number range is 4,294,967,296 so it's not hard to divide it up and get a very close finishing time for each chip
(and you can determine the ranges once and use them until it readjusts the chip performance)
With 1.2.5 on 10s p2pool, you'll still get roughly 9.3% stale on all BFLSCs - each chip will be doing work when an LP hits and the MCU will wait for each chip to complete it's job before it starts a new one and have a stale result from each - being 9.3% of the 10s share LP time (or 3.1% of the soon to be increased 30s LP)
However if it runs 50% faster, well I guess that doesn't matterAnyway,
the biggest issue with the MCU design in the FPGA was that it doesn't give you an answer until it completes the work.
The SC does the same thing.
So e.g. with 10 chips doing 4GH/s each, instead of getting 1 answer in 0.093 seconds, you get 10 answers in 0.93 seconds.
Thus latency is worse with the 1 job per chip firmware.
As I have said elsewhere (since 20-Jun), the simple fix is grade school maths level:
Divide the job up based on the speed of each chip, not give each chip it's own job, faster chips get a larger nonce range, slower chips get a smaller range.
Basically, set it so that all chips complete about the same time based on their performance.
The total number range is 4,294,967,296 so it's not hard to divide it up and get a very close finishing time for each chip
(and you can determine the ranges once and use them until it readjusts the chip performance)
With 1.2.5 on 10s p2pool, you'll still get roughly 9.3% stale on all BFLSCs - each chip will be doing work when an LP hits and the MCU will wait for each chip to complete it's job before it starts a new one and have a stale result from each - being 9.3% of the 10s share LP time (or 3.1% of the soon to be increased 30s LP)
node: lenny.dnsd.me:9332
I setup BE Blade to use +1 pseudoshare (+1 to username). However, I am still getting these errors, but not so often as before.
Log below:
There's also someone mining on my node right now on BE Blade (12.6GH/s hashrate, 7.6GH/s of it - DOA). Looks like he setup +1 to username as well.
I cannot prevent other users to connect to my node and start mining with BE Blades. If they will not setup +1 to username, my p2pool log will be spammed with thousands of error messages. How to fix it in p2pool code?
I setup BE Blade to use +1 pseudoshare (+1 to username). However, I am still getting these errors, but not so often as before.
Log below:
There's also someone mining on my node right now on BE Blade (12.6GH/s hashrate, 7.6GH/s of it - DOA). Looks like he setup +1 to username as well.
I cannot prevent other users to connect to my node and start mining with BE Blades. If they will not setup +1 to username, my p2pool log will be spammed with thousands of error messages. How to fix it in p2pool code?
50% DOA is just what is expected and it will probably drop to about 18% after share period switch.
Blades send diff1 shares regardles of what the node tells, so if the difficulty is set higher, a part of pseudoshares will be reported 'hash > target'. Those rare cases reported when you set diff to 1 are just hardware errors which are not filtered by the blade's software (my AM USB's chip produces about 1% or less HW errors depending on temperature).
Any code tweaks most likely won't decrease your node load. If you want to get rid of these messages in your log, just comment out lines 413 to 415 in p2pool/work.py.
so before we can expect to see any better behavior with ASICS we need to wait until 95% of the pool has upgraded, correct?
However, the BFL 1.2.5 firmware makes the Jalapeno worse and all the rest of BFLSC the same.If the chips are doing 4GH/s it takes ~0.93s to do a nonce range (and they are not divided up across the chips)
So expect around 3.1% work loss (when p2pool goes to 30s) just due to the way the BFLSC firmware works.
As I've stated long ago on the BFL forum, the fix for p2pool is quite straight forward, but still no response about it being done.
https://forums.butterflylabs.com/announcements/913-bitforce-sc-communication-protocol-draft-revision-2-a-8.html#post31853
If we hack
https://github.com/luke-jr/BitForce_SC/blob/e9e6a41fd76050a3aea2ab973c808f4cede174eb/BitForce_SC/ASIC_Engine.c
in function
ASIC_calculate_engines_nonce_range()
and divide line 1761 by some factor
https://github.com/luke-jr/BitForce_SC/blob/e9e6a41fd76050a3aea2ab973c808f4cede174eb/BitForce_SC/ASIC_Engine.c#L1761
we should reduce the nonce range by that factor.
This is a myopic hack, but would it work? you know the code intimately, i'm just pulling at straws here.
The only (minor) catch is that of course you are sending n times the amount of work and generating n times the amount of work in cgminer.
It becomes a major catch if you are dividing it too much.
You'd also have to change my FULLNONCE definition in driver-bflsc.c (around line 77)
Jump to: