TT-Miner 2024.1.2 BLAKE3, KAWPOW, ETHASH, ETCHASH, EPIC, SHA512256D, SHA3D, ETI

[TrailingStop]

is it also work for ZANO (ProgPOWZ)? thanks

Hi,

Zano uses a different revision of ProgPoW. I will release a version within the next few days. Form my understanding they plan to go live with this algo at the end of April?

[Vivik]

Version 2.2.2 when installed by default works without problems on farm 8 card.

Hi,

thanks you for your info - can you please add some additional information like, GPUs, OS, RAM, Virtual memory settings etc?

OS: win10-x64
RAM: 32Gb
Virtual MEM: 32 GB

PL : 70%

[solotrade]

hi, im really curious that gs does actually affect anything?

[TrailingStop]

hi, im really curious that gs does actually affect anything?

gs defines together with the blocksize the number of threads to execute. Blocksize is calculated and you cannot change it.

[solotrade]

hi, im really curious that gs does actually affect anything?

gs defines together with the blocksize the number of threads to execute. Blocksize is calculated and you cannot change it.

hmm, still dont get it. it affect the lifespan of gpu or use more cpu & gpu resources with gs size?

[TrailingStop]

hi, im really curious that gs does actually affect anything?

gs defines together with the blocksize the number of threads to execute. Blocksize is calculated and you cannot change it.

hmm, still dont get it. it affect the lifespan of gpu or use more cpu & gpu resources with gs size?

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!

[artful]

where link to linux version ?

[chrysophylax]

where link to linux version ?

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

[Sun221]

hi, im really curious that gs does actually affect anything?

gs defines together with the blocksize the number of threads to execute. Blocksize is calculated and you cannot change it.

hmm, still dont get it. it affect the lifespan of gpu or use more cpu & gpu resources with gs size?

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!

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?

[TrailingStop]

hi, im really curious that gs does actually affect anything?

gs defines together with the blocksize the number of threads to execute. Blocksize is calculated and you cannot change it.

hmm, still dont get it. it affect the lifespan of gpu or use more cpu & gpu resources with gs size?

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!

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?

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.

[TrailingStop]

Hi, is GPU power info being passed in API?

I see power info correctly as TT-miner is running, but not via API

With cryptoDredge i get GPU power info passed via API to Awesome Miner...

Want to make sure i have everything setup/configured correctly in TT-Miner...

Thank you!

Hi,

to enable the power usage in Awesome miner you should follow the recommendations for "Map to system montioring".
https://support.awesomeminer.com/support/solutions/articles/35000086014-display-additional-gpu-information

Please let me know if that is what you were locking for.

Thanks.

That only works in managed miner mode (having the awesome miner software installed directly on each of the miner systems directly)
I do not use any "managed" miners - they are all external miners. And the only way to monitor an external miner is with the API.
Thank you for the info and option, If i install AM on the miner itself, this would be VERY HELPFUL.

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.

[johndoughtoo]

Hi, is GPU power info being passed in API?

I see power info correctly as TT-miner is running, but not via API

With cryptoDredge i get GPU power info passed via API to Awesome Miner...

Want to make sure i have everything setup/configured correctly in TT-Miner...

Thank you!

Hi,

to enable the power usage in Awesome miner you should follow the recommendations for "Map to system montioring".
https://support.awesomeminer.com/support/solutions/articles/35000086014-display-additional-gpu-information

Please let me know if that is what you were locking for.

Thanks.

That only works in managed miner mode (having the awesome miner software installed directly on each of the miner systems directly)
I do not use any "managed" miners - they are all external miners. And the only way to monitor an external miner is with the API.
Thank you for the info and option, If i install AM on the miner itself, this would be VERY HELPFUL.

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.

  yay

[Shivoreun]

Hi to community.
The remote API response in v2.2.2 is not working? Or there is some trick needed to get it to work?
I'am using Awesome Miner, and it can get the stats from the miner, but any other software can't connect to the specified port. The Awesome Miner uses --api-bind 127.0.0.1 network, but I assume this will allow only localhost connections, that's why it's working.
I've tried the -b 0.0.0.0:4034 and --api-bind 0.0.0.0:4034 (and different ports), but miner is not responding. According to the TCPview, the tt-miner.exe is binding on the specified port (4034), but no connection

Is there some additional options that should be set to get remote stats via API?..

Hi,

0.0.0.0 will be translated to localhost (127.0.0.1). The default port is 4068. So if you have only a single network card installed on your rig you may want to try:
-b 127.0.0.1:4034

Did it work with an older version of TT and is now broken with 2.2.2, or is this just the first time that you try to get TT to work with Awesome Miner???

Thanks for reporting.

Thanks for reply

Previously I was using 2.1.14 and there were no such problem Didn't tested another older versions yet...
Then, what I should set in "-b" option to allow API requests from any address?.. Looks like, that regardless of the settings, the miner accepts only connections from locahost

Hi,

the miner does not filter any addresses. It looks to me like you have 2 (or more) network interfaces and the API bind to the wrong. The address you use for the api command is to tell the miner which network interface to enable for api access. If you have only one localhost is fine, if you have more it makes sense to tell the miner which one to use. You can check your IPs with 'ipconfig -all' command in the console. Let me know if that help or if you still have problems to get connected.

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://<address>.nvidia01:x@zcoin-eu.mintpond.com: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?..

[Balzhur]

Commandline for the miner is:
tt-miner -a mtp -A MTP-100 -P stratum+tcp://<address>.nvidia01:x@zcoin-eu.mintpond.com: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.

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.

[TrailingStop]

Commandline for the miner is:
tt-miner -a mtp -A MTP-100 -P stratum+tcp://<address>.nvidia01:x@zcoin-eu.mintpond.com: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.

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.

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.

[Shivoreun]

Commandline for the miner is:
tt-miner -a mtp -A MTP-100 -P stratum+tcp://<address>.nvidia01:x@zcoin-eu.mintpond.com: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.

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.

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

[dkmontague]

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

[TrailingStop]

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

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.

[WARMANGALAXY]

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

[TrailingStop]

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

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.