Farm mode (getWork) deliberately looses valid shares. Lowered efficiency.

[AndreaLanfranchi]

For first time readers ! This issue is only related to farm mode (getWork) ie using eth-proxy or connecting to pools still using getWork mode. Stratum mode is not affected.

Logic inside EthGetWorkClient is wrong by design due to a misinterpretation about --farm-recheck argument value.

Summary : all work is performed inside WorkLoop routine which is paused at every cycle by the amount of milliseconds defined in --farm-recheck cli argument (which defaults to 500 ms)

Problem : WorkLoop does not limit to check if new work is available from source but also sends found solution(s) on next loop. This causes two issues :

1. Solution found may stay in waiting state for submission up to --farm-recheck ms value (thus increasing the probability for it to become stale)
2. Before the --farm-recheck period expires another solution may be found and the latter overwrites the previous one which has not been submitted yet

This leads to increased stale share ratio and possibly lowers the miner efficiency (as valid shares may never get submitted). To mitigate this users may enter insanely low values for --farm-recheck which leads to a huge overhead while hammering source with get_work and submissions of hashrates.

/CC @chfast

[chfast]

Great analysis!

How important this feature is nowadays? Are there any pool depending on this protocol? For sure this is the only way to communicate with some Ethereum clients like geth and aleth (cpp-ethereum). I think parity implemented stratum.

Personally, I'd just deprecate the "getwork" protocol and inform the user that this is not optimal to use it.
For Ethereum clients I'd rather implement stratum server there.

[AndreaLanfranchi]

How important this feature is nowadays ?

I think it's still the only option for solo mining where you connect to a geth daemon.
Nevertheless there are some pools still offering this connection mode

• Dwarfpool getWork port 80
• Nanopool getWork port 8888

In addition there are still many users convinced (and thus using) that eth-proxy is efficient when more than one rig connected through a poor network link.

We should decide wether amend the logic or completely drop getWork mode : in this last case we could also get rid completely of the json-rpccpp external project (already removed in API server) and finally won't see --farm-recheck put randomly in stratum mode.

But, I reiterate, it seems like getWork mode might be useful for (not so) few people.

[AndreaLanfranchi]

Opinions from @smurfy and @jean-m-cyr welcome too.

[AndreaLanfranchi]

Another addition ... afaik EthOS ships bundled with eth-proxy and binds ethminer to it (one instance per GPU).

[chfast]

Dwarfpool getWork port 80
Nanopool getWork port 8888

Both pools have also stratum support. I don't think we should care about this case.

The eth-proxy only supports getwork to communicate with the workers?

Can more abstraction in PoolConnection help here? I mean can we abstract the logic of when solution are delivered from the protocol used? That could help both getwork and code quality in general.

[AndreaLanfranchi]

The eth-proxy only supports getwork to communicate with the workers?

Yes. As they state eth-proxy it's a bridge eth_getwork => stratum
Noticeable that it's last update it's 2 years old.

Can more abstraction in PoolConnection help here?

I believe not. PoolConnection has already a good level of abstraction. It's the implementation in the derived class which sucks. For instance those two methods do nothing else than setting two variables overwriting previous values.

void EthGetworkClient::submitHashrate(string const & rate)
{
	// Store the rate in temp var. Will be handled in workLoop
	m_currentHashrateToSubmit = rate;
}

void EthGetworkClient::submitSolution(Solution solution)
{
	// Store the solution in temp var. Will be handled in workLoop
	m_solutionToSubmit = solution;
}

SubmitSolution, at least, should send immediatley the solution instead of waiting for workloop.

[jean-m-cyr]

GetWork is definitely necessary to bind to a geth node.

[AndreaLanfranchi]

Solved.