Quote from: majika on March 25, 2021, 02:37:41 PM

Quote from: Ursul0

...

Im trying to figure out a way *if possible at all ** to track pool reply times / stratum get_work response times - if, for example, it takes grater than >100ms from current pool port But at the same time whilst tracking ping reply from the other pool ports are <100ms =40ms (faster) then get the miner to switch to the faster pool port to continue mining.

..in a nutshell monitor real-time (or on average) pool ping/latency times..

My observations is that during the late evening /early hrs morning (my time) they deprioritize traffic coming from .EU region and ping times climb, Then when they have more activity over in .ch time pings drop. along these lines, similar to that effect.

I haven't manged to track all their ports in-depth but cursory observations confirm this.
To date the best way I have to do this is to restart the miner on the new port when I see my stales counts climb.
But since this requires me to monitor rig console then it can be inefficient as I do need some sleep

Perhaps a way to look at this is to track the stale's report count and if it goes over the set threshold then trigger miner to swap ports.. As opposed to actually tracking stratum-ping times with hat utility i posted a few pages back in this thread maybe this could be one approach to skin the same cat sort of speak.

interested to get feedback/suggestions/tip's/ideas.
cheers

This is something that we have on our "nice to have" list but not sure when (or even if) it will be implemented, as it crosses the boundary between miner, and rig management software. In any case, we will start implementing at least part of this functionality by tracking the average share acceptance times (these are better than just the pings because they also reflect the pool load), and the average times between jobs which can be used to estimate the expected stale shares.

Quote from: AnotherTreatment on March 25, 2021, 03:49:16 PM

Just a note for the Devs:

It would be great to have a feature to limit the mining power of new NVIDIA cards, taking into VRAM junction temps... I'm not sure if that's possible, but if I would have a parameter to let the miner knows that I don't want to go over (let's say) 90ª on VRAMs Junctions and the miner would reduce the power to achieve that...would be awesome....

Just a silly idea, but wanted to share it with you.
hope it helps
Regards,
AT'

We are working on this, it will be ready for AMD cards in the next release but it may take a little bit longer for 3080/3090 cards.

Quote from: CrayjeksAjek on March 25, 2021, 09:19:16 PM

I am having trouble getting my AMD card (GPU1) to dual mine. Ive attached a log section below:

Code:

2021.03.24:20:47:42.539: GPU2 GPU2: Using v2 Ethash/Blake2s CUDA kernels (GeForce GTX 1070)
2021.03.24:20:47:43.303: GPU1 GPU1: DAG generated in 11.9 s (356.1 MB/s)
2021.03.24:20:47:43.305: GPU1 GPU1 doesn't support Blake2s dual mining
2021.03.24:20:47:43.305: GPU1 GPU1: Using Ethash OCL kernels (Ellesmere; -clkernel 1)
2021.03.24:20:47:43.305: GPU1 GPU1: no -gt value specified, switching to auto-tune
2021.03.24:20:47:43.305: GPU1 GPU1: starting auto-tune process
2021.03.24:20:47:44.922: eths Eth: Received: {"id":0,"jsonrpc":"2.0","result":["0xe8bb18defe634eee06dde26328d90f26752a435ecfa6a31aa279552b71ab9d54","0x3ba1ec7dd7e5aad3c65bafbe04baad8cc72d5157dbce5701db30c476f182011f","0x0000000112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0xb8b50a"]}
2021.03.24:20:47:44.922: eths Eth: New job #e8bb18de from ssl://us1.ethermine.org:5555; diff: 4000MH
2021.03.24:20:47:45.720: eths Eth: Send: {"id":5,"jsonrpc":"2.0","method":"eth_getWork","params":[]}

2021.03.24:20:47:45.720: eths Eth: Send: {"id":6,"jsonrpc":"2.0","method":"eth_submitHashrate","params":["0x2d7978d","0xae5b37a78617066d76c2a23c32b570f7930171b8db0f4663914e4bd06954ffff"]}

2021.03.24:20:47:45.764: eths Eth: Received: {"id":0,"jsonrpc":"2.0","result":["0xe8bb18defe634eee06dde26328d90f26752a435ecfa6a31aa279552b71ab9d54","0x3ba1ec7dd7e5aad3c65bafbe04baad8cc72d5157dbce5701db30c476f182011f","0x0000000112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0xb8b50a"]}
2021.03.24:20:47:46.263: main Eth speed: 47.669 MH/s, shares: 0/0/0, time: 0:00
2021.03.24:20:47:46.263: main GPUs: 1: 20.483 MH/s (0) 2: 27.186 MH/s (0)
2021.03.24:20:47:46.263: main B2S speed: 271.859 MH/s, shares: 0/0/0
2021.03.24:20:47:46.263: main GPUs: 1: 0.000 MH/s (0) 2: 271.859 MH/s (0)

Dual mining on some AMD cards is not supported with driver 20.5.1 or newer.

Quote from: janding on March 25, 2021, 11:19:01 PM

Is there a secure SSL Port for mining ETC on ethermine.org like this:
ssl://us1.ethermine.org:5555

I can only seem to find this that works:
us1-etc.ethermine.org:4444

Surely I missed this somewhere.

Thanks

The following works without problems: -pool ssl://us1-etc.ethermine.org:5555 -wal 0x... See here for the other addresses: https://etc.ethermine.org/start