I have two Antminer S2s. Both misbehave the same way with p2pool. Within minutes of pointing them at p2pool, my hashrate drops to 930gh/s or lower.
It shows this way on p2pool, on the S2 LCD, and on the S2 web UI.
It stays this way, or gets worse, as time goes by. I've run against p2pool for days this way trying different things, and the result is always the same. Yet running on a conventional pool (like Eligius), things run fine immediately and ongoing.
I've tried adjusting my pseudo share size.
I've tried running on a local node, my public node (other side of the country), and at least one other public p2pool node that was close to me.
Since S2s use cgminer, I was hoping a dev might be able to shed some light on this for me.
BTW, my S1s work fine with p2pool. At 1/5 the hashrate, but they do work fine.
I apologize if this has been mentioned already. I stopped following this thread a while ago.
Thanks.
M
You are running bitmain's S2 driver. Don't do that on p2pool. Also don't do that with bitmain's S1 driver.
Bitmain does some terrible things in their driver including ... discarding stale work in the driver before passing it to the work validation code.
This means on p2pool that if you find a stale block that is still a valid network block, it will be discarded. Oh well.
Use my driver for S1 if you don't want to throw such valid blocks away on p2pool.
My S2 driver is still in development - I'm still trying to work out why the device thinks it's a good idea to have >8000 work items queued in it - more than 30s of work - and to work out how to reduce that without letting it get idle - so I'm still waiting on source code from bitmain.
My blackarrow minion RPi driver is able to handle > 2TH/s of work at 1diff verifying every share returned at 1diff.
The S2 driver, on a faster BBB, should be able to handle 1TH/s of work at 1diff also. It doesn't. So I need to work out how to fix that - but I need the SPI kernel driver code bitmain wrote, for me to work that out.