Quote from: KyrosKrane on June 30, 2016, 05:18:49 AM

Is it possible we have a bona fide fork in the p2pool share chain? That is, someone generated a share that was incompatible with v16, causing v16 nodes to reject it and fork away. That v15 chain continued building, and is the reason we're seeing massive influx of invalid shares on v16 nodes. New pools starting up now have a (small) chance of picking up the old v15 chain, which causes the v15 shares to get propagated to the network. As independent nodes connect to both v15 and v16 nodes, the poor performance we see starts to happen - massive lumps of shares appear, requiring huge CPU time to process, since they don't integrate neatly with the existing share chain. In the end, the incompatible shares are rejected, but they still take time to handle. (To be clear, this is just a guess at what's going on in terms of the big picture. Jtoomim seems to have a handle on the technical aspects of why the performance is poor.)

That is sort of pretty much what is going on.. The current upgrade process is that once the majority of the network is upgraded to the next version, a new version is released that bans the old peers and restores performance to the majority network. Currently the remaining old version peers are spamming the majority network with invalid shares.

We need an automatic implementation of this function as currently it seems to be manual...? There should be a way to support both versions of peers until majority has reached and maintained the consensus threshold, and then the older peers are banned from the network and the new version is fully enforced. This would prevent what is occurring and seems to occur every hardfork. :s

The fix has been merged into master. Upgrade to the latest git version to restore performance to your node.