Topic: TT-Miner 2022.4.1 KAWPOW, PROGPOW, ETHASH, ETCHASH, EPIC, SHA512256D, GHOSTRIDER - page 35. (Read 132169 times)

thank you for reply TrailingStop

I tried different configs, memory +200 core +200,  also tried MTP-100 and MTP-101

also tried -i auto 1024 10240 256
it finds best grid etc but still randomly crashing.

was using other miner before with +200/+200 and had no issues..

those rejected shares appeared on any of cards randomly..

PS: using Awesome miner and it adds the "stratum+tcp://" by default, do you think that can be problem?
if its not that, what you mean by your suggested config, cant see any difference ?

Will try to remove all OC

Hi,

what do you mean in detail with card crashes detecting? In the about sample TT detects the cards that crashes, first GPU 0 crashes, then 2, 3 and 4. In the coming release it will continue to report crashed and/or not working cards - is it that what you mean?

Hi,

the error 702 indicates a cuda-timeout. It takes too long until the kernel finishes and the driver terminates it. Please try to use intensities/grid sizes below 10240. For MTP I would start without any OC. Please try to get a stable configuration first.

You can make you command line somewhat simpler - so TT will find the best CUDA version for your installed driver/interface:
-A MTP -P abcdefghasjdhaklsdjallkajdl.worker:[email protected]:3000 --api-bind 127.0.0.1:4033

RAM and Virtual RAM looks OK - Celeron is fine as well.

I would guess you have a OC problem with GPU 0 and maybe GPU 1 - they show rejected shares (but I'm only guessing!).

Please let me know if removing OC helps?

I pointed out several times that TT miner is the only miner I know that doesn't detect which card crashes... you have to check every card's OC one by one, gl.

Hello, Im getting randomly these error:

16:43:00.036 GPU[0]: 2.427 MH/s  CClk:1.607 GHz MClk:3.999 GHz 37C 50% 32W 75.834 kH/W [A49:R2 3.9%]  LastShare: 00:03:09
16:43:00.037 GPU[1]: 2.437 MH/s  CClk:1.607 GHz MClk:3.999 GHz 38C 50% 31W 78.623 kH/W [A44:R1 2.2%]  LastShare: 00:01:57
16:43:00.037 GPU[2]: 2.320 MH/s  CClk:1.607 GHz MClk:3.999 GHz 36C 50% 31W 74.837 kH/W [A37:R0 0.0%]  LastShare: 00:04:05
16:43:00.038 GPU[3]: 2.332 MH/s  CClk:1.607 GHz MClk:3.999 GHz 38C 50% 31W 75.218 kH/W [A47:R0 0.0%]  LastShare: 00:04:06
16:43:00.038 Rig-Speed[2 min]: 9.516 MH/s 125W 76.126 kH/W [A177:R3 1.7%] Uptime: 00:52:33  LastShare: 00:01:57
16:43:12.082 POOL: Received new job#: 169c
16:43:12.084 Miner: Error ******** GPU[0] CudaError: 702
16:43:12.085 Miner: Error ******** GPU[0] Not enough memory to run algo. GPU disabled.(0/1)
16:43:12.087 Miner: Error ******** GPU[0] Please check if your Virtual Memory setting is OK. You can also try to
16:43:12.088 Miner: Error ******** GPU[0] reduce the intensity/grid-size command line value to fix this problem.
16:43:12.089 Miner: Error ******** GPU[1] CudaError: 702
16:43:12.090 Miner: Error ******** GPU[1] Not enough memory to run algo. GPU disabled.(0/1)
16:43:12.091 Miner: Error ******** GPU[1] Please check if your Virtual Memory setting is OK. You can also try to
16:43:12.092 Miner: Error ******** GPU[1] reduce the intensity/grid-size command line value to fix this problem.
16:43:12.099 Miner: Error ******** GPU[2] CudaError: 702
16:43:12.099 Miner: Error ******** GPU[2] Not enough memory to run algo. GPU disabled.(0/1)
16:43:12.103 Miner: Error ******** GPU[2] Please check if your Virtual Memory setting is OK. You can also try to
16:43:12.106 Miner: Error ******** GPU[2] reduce the intensity/grid-size command line value to fix this problem.
16:43:12.108 Miner: Error ******** GPU[3] CudaError: 702
16:43:12.111 Miner: Error ******** GPU[3] Not enough memory to run algo. GPU disabled.(0/1)
16:43:12.114 Miner: Error ******** GPU[3] Please check if your Virtual Memory setting is OK. You can also try to
16:43:12.115 Miner: Error ******** GPU[3] reduce the intensity/grid-size command line value to fix this problem.
16:43:12.116 Miner: Error ******** All GPUs are disabled. TT-Miner cannot continue and will exit now
16:43:12.125 POOL: Lost connection to zcoin-eu.mintpond.com:3000
16:43:12.126 POOL: Mining temporary stopped


Happening after 10, 30 , 60 minutes. randomly.. any clue ?

This is my config:
  -A MTP-100 -P stratum+tcp://abcdefghasjdhaklsdjallkajdl.worker:[email protected]:3000 --api-bind 127.0.0.1:4033

I tried different intensity or grids..
gtx 1070 ti
using latest NVIDIA drivers
8 GB RAM, 32 GB virtual memory, Celeron CPU

PS: what OC is best for gtx 1070 ti ? increase core? mem ?

working hard on this. Please keep in mind that this is not my main job and that I do not have 20 developers behind me.
Sorry for the delay.

Dear developer, we are waiting for 3 months of release for Linux, when this miracle will happen.

Hi,

TT-Miner stops mining if it receives a new job, because all solution it will find after that will be invalid and rejected by the pool. First TT needs to create a new Merkle Tree before it can start mining again. That is what you see. I consider to add an option to keep 'dummy' mining on during that phase and ignore solutions. Not sure if this is harmful or not - maybe always full load is harmful and the small drops is a kind of regeneration phase? I do not know.

It seems like every few moments the miner drops the load off of the cards down to 0 then back to 100.  Maybe this is harmful to the cards to happen hundreds of times per day... Possible to keep it going like in CryptoDredge? Or am I misunderstanding? Sorry im nub

Thanks for explanation
BTW, --api-bind 192.168.128.21:4035 also not working
Waiting for the new version

Hi,

This is 100% correct. I bound 127.0.0.1 to localhost. I was not aware that it should bound to all. Will fix that in next release.
Thanks for pointing to this issue.

No wonders as you have bound API to 127.0.0.1 which is localhost. It is not accessible from LAN.
Technically you should modify the command line to utilize --api-bing 0.0.0.0:4035

0.0.0.0 means ALL of the computer IP addresses present, so it should include 127.0.0.1 and 192.168.128.21 which I assume is your LAN IP address.

However, looking at what TrailingStop wrote above "0.0.0.0 will be translated to localhost (127.0.0.1)." I doubt this will work until TT fixes this behavior.

OR

Just use --api-bind 192.168.128.21:4035 and API will be accessible from LAN, but you may have issues with your miner (awesomeminer or NHML or smth else) if any.

No, there is no 2nd interface present. The ping command to "localhost" corresponds to 127.0.0.1
Commandline for the miner is:
tt-miner -a mtp -A MTP-100 -P stratum+tcp://

.nvidia01:[email protected]:3000 --api-bind 127.0.0.1:4035

The rig is on Win10, has local IP 192.168.128.21, firewall is disabled for all networks, WinDefender disabled via registry. IPv6 is disabled.

The telnet localhost 4035 - miner answering.
The telnet 127.0.0.1 4035 - miner answering.

Trying from another rig, in the same network (192.168.128.20)
telnet 192.168.128.21 4035 - connection denied.

When miner starting, it says:
API-Interface enabled. Listening on 1

Any ideas?..

  yay

Hi,

you wish will come true. I worked together with Paktrike from AM and he made the required modifications to AM. In the next release of AM and TT will show you the power-usage of each GPU.

Hi,

I can only give you my personal opinion and preference only. there will be others out there with very different opinions, I guess you have to find the best settings for you and your configuration.

For the algos that are supported by TT the CPU doesn't play a big role as well as RAM. I know of systems that works well with 8GPUs and have a celeron and 4GB RAM only. You CPU, RAM-size and HD/SSD size will not have a very big impact on your overall performance. Changing the grid-size changes the configuration of the kernel that runs on your GPU. I prefer lower values since I noticed that on my system I see much faster stable hashrates. With higher/very high (over 8192) gridsizes I see the hashrate dropping over a long period until a stable level is reached, so I chose in most cases values between 256 and 4096. But this observation is very depended of the system and GPU you use. Also please to note that I do not run hundreds of GPUs - my experience if 1070 and 1060/6GB ONLY. I never made some investigations how different gridsizes impact the lifetime of a GPU - I leave that to someone else.

So my best advise for you is to make your own tests and find the settings that works best for you and the system you have.

OK I'm no rocket surgeon here

If I have a 7 card rig with decent GPU's (1070ti's) with a low-end CPU (G4400 dual-core Pentium) ...
Should I focus on smaller gridsize (perhaps between 4096-8192)?

And if I had a better CPU, a larger gridsize may or should work better?

A Linux version is being worked on ...

It is not available just yet, therefore there is no link to any Linux version (Debian or RHEL based) yet.

#crysx

where link to linux version ?

Maybe I'm too bad in explaining. Please check this information:

https://www.youtube.com/watch?v=kzXjRFL-gjo
http://cuda-programming.blogspot.com/2013/01/threads-and-blocks-in-detail-in-cuda.html

There are much more - just try to google 'cuda grid block'. You will get lots of information about grid/block/threads and how they are related to each other in GPU kernel programming.

Hope the helps more!