--farm-recheck no longer control hash rate display interval?

[jean-m-cyr]

Interval seems to be locked at 5 seconds... way too fast.

[smurfy]

Should be quite easy to add a separate param for this. I never liked that farm-recheck was misused for it. In my opinion the new param should have two modes.

value > 0 = interval in seconds value == 0 = only post stats on new work received (like claymore, not sure about the bump in hashrate after new work. but this is almost gone after work fixes)

Default either 5 or probably better 10 seconds.

[jean-m-cyr]

Indeed --farm-recheck was abused.

[AndreaLanfranchi]

IMHO the --farm-recheck has to be rearranged.

1. Most people think --farm-recheck has always a weight in staying in sync with new works. While this is true in farm mode, it's completely false in stratum mode;
2. Due to first point most people use very low intervals causing, in stratum mode with --report-hashrate, the clogging of pools with lots and lots of unuseful submissions

I think farm-recheck should be meaningful in farm mode only.

[smurfy]

@AndreaLanfranchi it is, in current master --farm-recheck has no function whatsoever in stratum mode. It only affects farm mode, as it should.

Also if someone adds display interval param, this will not affect report hashrate submits, which are currently "hardcoded" to every 10 seconds. It would only affect DBUS submits which probably can be also moved.

[AndreaLanfranchi]

Thank you @smurfy. Now it makes lot more sense.

[maxcom99]

Is anyone working on adding the display interval param?

[jean-m-cyr]

Not that I know. Most seem comfortable with the current default interval.

[maxcom99]

Perhaps this belongs as a feature request in this case then but using applications that parse the logs such as ethOS to make decisions on how to react need to have faster updating display

[maxcom99]

P.S. this change also impacts local proxies such as https://github.com/slush0/stratum-mining-proxy where the recommended re-check speed is 200ms. Or is it expected that the proxy makes the pool decision instead of getting it from ethminer?

[smurfy]

using applications that parse the logs such as ethOS to make decisions on how to react need to have faster updating display

thats just plain stupid, ethminer has api support which allows requesting the stats you are talking about at any interval needed.

stratum-mining-proxy

i think you misunderstood here. ethminer supports stratum directly so stratum-mining-proxy is not needed at all. For users which want to use it for for whatever reason, stratum mining proxy listens for getwork/farm requests, NOT stratum requests. So the --farm-recheck param is used an can be as low or high as needed. Because ethminer then uses the getwork protocol not stratum.

Hope this clears things up for you.

Edit: in my opinion there is no real need to ever use getwork these days, its inefficient and just wastes bandwidth. Stratum is designed to be async, so the miner gets the new work at the time the pool sends it, not by polling the pool every 200ms for new work.

[maxcom99]

The API addition is fairly recent and you can't expect people to catch up. I love what you guys have done here but you have also grown and with that comes some backwards compatibility responsibility. I took a look at the code as I have C experience but with the crazy interdependencies I couldn't make heads or tails of it all around version 11. I believe this is in process of being cleaned up to a readable state so perhaps I'll try again and actually contribute :)

The proxy solution is again for people with several machines that they have to manage, this proxy was just an example. There are now dashboards etc that have grown as a result of the increase in ethminer popularity that rely on features not being drastically changed without notice for all intents and purposes.

re stratum requests - this was the clarification I needed, looks like I need to reconfigure things so the proxy makes the pool decisions and then switch ethminer into farm mode, thank you.

[AndreaLanfranchi]

The API feature has been around for long time now. Only recently has been refactored only the OUTPUT.

One note about proxies. The proxy project you have pointed to acts (cit) "as a bridge between the old getWork protocol and the new stratum protocol". Now ... the difference between getWork and stratum is quite substantial. In the first case (getwork), is the miner software wich asks for work at any given interval specified by --farm-receck while in stratum mode the miner receives jobs which are PUSHED by the pool regardless any setting on the miner.

If your' a solo miner with your own geth instance you may want to play with farm-recheck. If you mine with a pool there is no need to use a getWork/stratum proxy/bridge : better say you should not use it as it adds more latency and may increment your stale shares rate.

Use ethminer to connect directly to a pool.

Note there may be cases where stratum/stratum proxies may be helpful ... not getWork/stratum.

[maxcom99]

I think the stratum/stratum proxy is another discussion - ethminer is more efficient [YMMV] when running separate instances especially in mixed cards environments. Having each process open a socket makes no sense.

[AndreaLanfranchi]

ethminer is more efficient [YMMV] when running separate instances especially in mixed cards environments.

This assumption is totally wrong. Ethminer does it's best when running a single instance on multiple gpus as each one is given a non overlapping range of nonces to search for on the same jobs.

Having each process open a socket makes no sense.

Yes it makes no sense ... but is exactly what your doing here #783

[smurfy]

Well i think the discussion here gets a bit off-topic here.

Just to recap what this issue was actually about:

In the past the parameter --farm-recheck was used if in stratum mode to control the display interval of the current hashrates. In getwork/farm mode it is used to control how often the pool is asked for new work.

Since this was a miss-use of a parameter only really relevant for getwork, the alternate usage has been removed in a refactor, without impacting its intended use. With this change the display of the hashrate has been fixed to every 5 seconds, regardless if in getwork or stratum mode.

The idea of this issue was to ask if it makes sense to add a parameter to control the display of hashrate/stats interval. For some the 5 second interval is to high for others to low.

Since adding the param would take around 5 minutes i guess i will add it soon.

[maxcom99]

@AndreaLanfranchi this is why i added "your mileage may vary" - i get 3-5M/rig more setup differently than you suggest. Your statement seems to contradict https://github.com/ethereum-mining/ethminer/issues/736 unless I misunderstood. The proxy referenced in 783 keeps a single connection to the pool.

[jean-m-cyr]

It strikes me that higher reporting rates may actually interfere with hash rate. Increasing the odds of solution submission output and HR reporting output colliding, possibly blocking the miner thread for 1 OS dispatch cycle.

[AndreaLanfranchi]

@maxcom99 Two distinct matters :

736 was about the option to ensure multiple rigs (not GPU ... but rigs) may work on same jobs with non-overlapping nonce ranges. It was a question about extending what ethminer already does on single rig with multiple GPUs. It was meant for a "cluster" of rigs.

About separate instances for GPUs. Say you have a rig with 8 cards. Do you really mean 8 separate instances of ethminer, each per gpu, provide better results ? It's 8 processes, each one querying for their own work, each one racing against the other for cpu scheduling ... etc etc.

I am keen to believe your observations mostly rely on the fact you use the "old fashioned" farm getwork by the means of a proxy.

Try a single instance of ethminer using all cards and use stratum mode against a pool. And report

[maxcom99]

@AndreaLanfranchi "ethminer only" method is precisely what I've been running for about 8mo. I recently wanted to play with overclocing on *nix and ethOS allowed me to to so easily without spending a ton of time dealing with it. I agree conceptually what you say makes sense but even the best devs overlook the simplest typos :) To not derail this further, I'll concede.