Quote from: nicehashdev on April 21, 2014, 05:29:24 PM

Quote from: phzi on April 21, 2014, 04:58:07 PM

The buffering I am talking about is very key. Yes, it has been done before. And you are correct that a reconnect is neccesary to change extranonce1 and possibly extranonce2_size. Having work buffered on the server ready for the miner before you force a reconnect and update the on-connect nonce params allows you to instantly provide work when the miner reconnects, essentially eliminating switch downtime.

As for the problem with idle miners - I have not observed failed auths in these cases. I see the pool accepting the auth request with p=, but not being able to provide work. This seems to occur when there are jobs at the desired profitability, but those jobs are already maxed on miner (no slots available). The pool keeps the connection open and allows the auth innappropriately. If I set p high enough that no jobs are available (full or not), this doesn't happen.

Don't know what you meant about slush's proxy. The pool I am talking about has a fully custom stratum implementation and can proxy traffic at will. The miner sees only the interupted message and mining barely hiccups.

My patch is hacky and I don't plan to publish it. Besides, right now it is giving me an advantage... why would I share when you have made this system competitive instead of fair/proportional?

I also still don't think the idle issue is a cgminer bug. The addition of stratum commands to change the extranonce params that are limited to on-connect right now would be valuable, however. Stratum is dying for a few extension like this, as well as for pool provided algorithm and nfactor.

Show me sniffed log. NiceHash will drop connection when p is too high for current order, regardless of what kind of orders are there (maxed out or not). We have seen this faulty behaviour only happening after cgminer/sgminer is running for a while, and it always *fixes* it-self when you restart the miner. Completely logical conclusion is that there is bug in cgminer/sgminer, because NiceHash keeps no track of miners, all it gets is socket with IP and port - it doesn't know whether it is a reconnect after a while or a connect from restarted miner. If the bug was on NiceHash side, then restart of cgminer/sgminer would not help you.

Your secretive behaviour does not help you with your credibility. I am not fully sure whether we should even accept your feedback input at all. You talk about some mysterious pool for several pages now already, and we still haven't learned which pool this is.

if you want to believe him or not is up to you, but i can tell you he aint lying, i don't have the smarts to explain in detail but i came from that pool.