Quote from: Count_Frackula on August 29, 2014, 07:59:11 PM

Quote from: specialed101 on August 29, 2014, 07:43:33 PM

It's only a BAN issue because a bunch of us were talking about it in the BAN IRC channel. It's also a BAN issue, because the current Invalid Shares count includes the 66 million I was writing about. Let's not start trying to tell folks where and when they can write things, and let others decide for themselves what is worthwhile.

The link you've provided is exactly the file that I had used; because it is supposed to fix it. That is why I tried it. That is why I am advising others not to.

I imagine it's related to what Kano posted a little while back (see below). I know that my S1s ran fine with Kano's firmware and when I point my S3s at the pool, I have less than a 1% reject rate.

Quote from: kano on May 28, 2014, 02:45:51 AM

Quote from: mdude77 on May 28, 2014, 01:17:50 AM

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.

The p2p thing would make sense, and the elegius thing makes sense. So, yeah. It looks like a miner issue perhaps, not a pool issue effecting some people. =/ explains why I lost so much hash without explanation.