Topic: T-Rex 0.26.8 ETHW, ETC (+dual mining) GPU miner - page 44. (Read 174976 times)

There's no builtin hashrate monitoring at the moment. The miner can detect various errors and reboot the PC if needed, but low hashrate is not an error obviously. We'll see what we can do about that.

Hi which build to use for 1080ti cards? CUDA 11, 10 or 9?

Gotcha thanks. I have it at 2000mhz GPU boost. Watching my clocks, it really only sits at 800-1700mhz when mining. My memory is locked at 19004 though while mining, it never fluctuates.

Yeah, it turned that the problem for me was running windows 7. Updating to windows 10 fixed the problem. Now sometimes when driver fail, overclock settings from msi afterburner get reset, miner restart and start mining with default clocks.
Is there a way to make miner exit or set watchdog like in claymore to watch hashrate and if it drops below certain level - exit? CMD script will do restart thing afterwards.

Yes, CUDA 11.1 build is the only one that works with 3090. I'm assuming you're talking about ethash? You may want to try overclocking memory to achieve better results.

only GTX cards under Windows 7/8 experience hashrate drop by our observations

I am a little new, my 3090 asus strix is only doing about 92-95 MH/s, I am using t-rex-0.19.5-win-cuda11.1.zip on windows 10, is that the correct one?

Today we have found solution of performance degradation on Nvidia GPUs under Windows 7 and Windows 8.1
GMiner v2.38 includes this fix and available to download on github

Putting this info here in bold to make sure people notice it.

Massive hashrate drops on some 10xx cards is a known issue on epoch >=384 when running Windows 7 and 8.1.
According to the reports of our users updating to Win10 or linux solves the problem.


Had you been running Claymore with straps? If so, try "--mt 5" with t-rex, it will increase the hashrate.

this method didn't work in my windows 7 rigs, 1080ti gpus.

Chck for newer drivers and make sure your OC settings are correct.  My 1070ti's get 33MH @120w with 150core 650Mem with HiveOS, newest Trex cuda 11.1 and 10 work for me.

Hi, I switch today to t-rex from Claymore's miner and getting 18-20 MH/s instead of 35MH/s on 1070ti no matter the setting, set highest intensity and CPU priority and no result.
Tried running benchmark with 383 epoch with which Claymore was still functioning, gettin better 27MH/s, but still not nearly good.

After working for some days, again with untouched and same configurations, the T-rex mining software stopped on the rig using shared LTE Internet with an error "no connection" on eth.2miners.com:2020 causing by failed to ethproxy-subscribe .... can not parse Json. However, the source rig with LTE Internet is still working without problems, firewalls are all disabled.
I have also tested the TCP connection as well as UDP connection with nmap software from nmap.org and they are successfully discovered well, specially the one related to 2020 port

Thanks

T-Rex 0.19.5

* ("octopus") Up to 20% performance improvements on most 20xx and 30xx series GPUs with low PL
* ("octopus") Add solo mining support

Many thanks for letting me know about TCP which is used by mining software. After doing the test command for TCP connection in Windows 10, which returned true, it started to work again via the cable... really strange to me but it works now.

Thanks again for your comment

Hi. I'm not a network engineer, so you may want to direct your question to someone who is. What you describe sounds like a network related issue that's outside of our control. By the way, ICMP (used by ping) and TCP (used by mining software) are two different protocols, so if you don't have issues with one, that doesn't necessarily mean you won't have issues with the other.
Sorry I don't have a solution for your issue.

Dear T-rex developer,

I hope everything goes well on your side. Recently, I have tried to migrate to one of the mining software recommended by 2miners website (i.e., gminer and t-rex). However, I have face difficulties in making them start to mine through a cable based or wireless based network. I am not sure what strategies or algorithms are behind the software for communicating with the mining pools, but the issue is still there on my side.
For your information, I have been successful in using an LTE USB dongle in using the t-rex 0.19.4 by the time being, but not tried it yet in gminer. The Claymore has also the same issue and is working using an LTE USB dongle, as a couple of days ago it faced the errors of time out or no connection through ADSL router cable or the shared Internet of working LTE USB dongle shared through a switch.
In other words, recently all of the the sofwares in my side have faced an strange issue.
Additionally, the Internet network can easily ping the eth.2miners.com without any problems on all rigs using cable, wireless or LTE USB dongle.
As I am not aware of the inside of the mining program, so I can not find out why the no connection or time out messages can be issued even if the ping replies are OK.

I would appreciated it if you may kindly comment on this issue.

Thanks for your attention in this regards.

Hi,

I have used one internet connection on one system shared by Windows 10 and a switch between the other computer systems (all use Windows 10 and now Trex 0.19.4 cuda 11.10). I have no problem with the pool connection in the source system (which shared the Internet connection) and it works well and find shares. However, I get connection time out on the other ones starting from today, after the DAG sizes are set and MH/s are also visible (with all firewalls off) and working some minutes (e.g., 3 min), and hence they do not find any shares.  This process is repeated with no success such a loop.

FYI: Every thing about connection with pool was OK the previous days on Ethash algo with Claymore 15
The ping of the pool is also OK in all Windows 10 systems. I am not sure what the problem will be  

Thanks

T-Rex 0.19.4

Bug fixes:
* (Windows) Not showing temperature / power consumption details when using v460.79 video drivers
* (Linux) Miner not starting with various "TREX: xxxx" (base64 encoded) errors
* "--keep-gpu-busy" not working under some conditions

Thanks for reporting, we'll fix it in the next version.