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

No- if you see a crashdump something serious bad happens. Can you send one of them to me so that I can check what happened? Please add some information link algo, coin, pool, gpu, version so that I have some more information to fix the bug? I will add an option into the next release to disable crashdumps.

TrailingStop
Is there any way to disable Crashdump file creation?

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.

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,

no - that is the nature of ProgPoW. The algo changes in case of the BCI version with the epoch. The ETH ProgPoW version will change more often than that. So it dropped for all miners.

thank you!

also, I've noticed that my ProgPoW hashrate dropped by 5-10% with epoch #12. is it expected or something is wrong on my side?

Nowhere - this is the version I'm working on now and make some fixes and add some user-requests and ideas. If it becomes public beta I will drop you a DM if you like.

Anyway: Good observation

where can I download TTMiner 2.2.3beta?
seen it mining ProgPoW on Zergpool.

I'm already working on Linux for some weeks (months already) now. Unfortunately the conversion to Linux takes more time and needs much more code modification than I was hoping. But it couldn't take much more time - so you can expect it soon (starting with an ubuntu version).

Hi,

Yes - I'm sorry about that. Try to find a more reliable way to calc hashrates with high grid sizes. Unfortunately the calculation isn't trivial with the technology I use for the algo in the case that a single work on a GPU takes more time than I expected (2-3 seconds, so that they fit into my bucket structure...).

I hope you find a good sweet spot for your system anyway?

Hi,

thanks you for your reports and your ideas - I will see what I can implement. The lines shouldn't be a big issue If a new job comes in I have to create a new Merkle Tree. during that time I know that any solution the gpu would find is invalid, so I stopped the functions that searches for new solutions and strats the creation of the Merkle Tree - I think that is what you noticed.  I will see if I can avoid these load drops in that phases of mining.
Also I'm very sorry that the hashrate calculation didn't work well for these high grid sizes - they still didn't made much sense on my GPUs. But the new RTX and the big GTXs cards seems to give some good results in these areas. I think I have to find a new and more reliable way for the calculation. At least I'm happy your find a sweet spot for your configuration - that's most important.

Any plans to port it to linux?

Yeah no the software is great i just thought I stumbled onto like the golden gridsize seems I was just enjoying inflated local numbers.

Done the gridsize testing for GTX and RTX.

For GTX and RTX a lower gridsize is better than a higher gridsize. Tested with below 10k, above 30k and a bit between too, just to be sure. A higher gridsize gives higher numbers, but only local. Also the hashrate jumps up and down (the reason a few post above), but the real pool average is below the lower numbers. The 10-sec version runs smoother, but has no effect to a higher pool hashrate compared to the 5-sec version. Its all just local. Also a lower gridsize seems to have a better session luck than a higher gridsize which is very important.

Maybe the new version with the more tolerance to higher gridsizes will boost the hashrate a bit more But still a great work!

I have two more suggestions for the MTP to make your miner even better:

1) Please post a line (or one line per GPU with the time) when the scratchpad is generated. Its a useful info.
2) From time to time you drop the load of the cards (maybe when the scratchpad is built?). But it is more healthier to the cards to not drop the load a hundred times per day, let them always stay with work like in CD.

Hi,

I guess you use an very high grid size? In that case the hashrate could be wrong if a kernel need more than 5 seconds to execute. Please use ALWAYS the reported hashrate of the pool as reference! But I think 2.2 MH/s for a 1070 on MTP isn't too bad?

I will release a new version soon that comes with more tolerance to higher grid sizes.

Anyway thanks for your report.

2.2.2b1 had the highest potential, up to 3Mh/s with a 1070; all other versions do not even go above 2.2 so I think 2.2.2b1 had either a magic solver or was reporting hashrate wrong

was up from 16H/W efficiency to 25 I think there was an error in that one or if not, it was a genius build

After testing for several hours (including fine-tuning gridsize to 7296 per GTX 1080 GPU) I can confirm there is hashrate flux.

17:13:15 GPU[0]: 2.592 MH/s  CClk:1.708 GHz MClk:218.03 MHz 66C 52% 147W 17.632 kH/W [A0:R0 0.0%]  LastShare: 00:00:24
17:13:15 GPU[1]: 2.592 MH/s  CClk:1.721 GHz MClk:218.03 MHz 62C 39% 152W 17.052 kH/W [A0:R0 0.0%]  LastShare: 00:01:59
17:13:15 GPU[2]: 2.592 MH/s  CClk:1.721 GHz MClk:218.03 MHz 66C 49% 152W 17.052 kH/W [A0:R0 0.0%]  LastShare: 00:00:53
17:13:15 GPU[3]: 2.615 MH/s  CClk:1.721 GHz MClk:218.03 MHz 65C 48% 154W 16.979 kH/W [A0:R0 0.0%]  LastShare: 00:02:58
17:13:15 GPU[4]: 2.592 MH/s  CClk:1.708 GHz MClk:218.03 MHz 69C 59% 151W 17.165 kH/W [A0:R0 0.0%]  LastShare: 00:10:41
17:13:15 Rig-Speed[2 min]: 12.983 MH/s 756W 17.172 kH/W [A237:R1 0.0%] Uptime: 03:01:56  LastShare: 00:00:24
17:13:18 POOL: Received new job#: 68d59d1
17:13:30 GPU[0]: 2.440 MH/s  CClk:1.721 GHz MClk:218.03 MHz 66C 52% 149W 16.379 kH/W [A0:R0 0.0%]  LastShare: 00:00:39
17:13:30 GPU[1]: 2.440 MH/s  CClk:1.721 GHz MClk:218.03 MHz 62C 38% 152W 16.055 kH/W [A0:R0 0.0%]  LastShare: 00:02:14
17:13:30 GPU[2]: 2.431 MH/s  CClk:1.721 GHz MClk:218.03 MHz 65C 49% 152W 15.993 kH/W [A0:R0 0.0%]  LastShare: 00:01:08
17:13:30 GPU[3]: 2.452 MH/s  CClk:1.733 GHz MClk:218.03 MHz 65C 48% 153W 16.029 kH/W [A0:R0 0.0%]  LastShare: 00:03:13
17:13:30 GPU[4]: 2.440 MH/s  CClk:1.708 GHz MClk:218.03 MHz 68C 59% 151W 16.162 kH/W [A0:R0 0.0%]  LastShare: 00:10:56
17:13:30 Rig-Speed[2 min]: 12.205 MH/s 757W 16.122 kH/W [A237:R1 0.0%] Uptime: 03:02:11  LastShare: 00:00:39

Hi,

yes - good idea. I think that is the way< to go - a hotkey to print additional information that are hidden otherwise. TT-Miner uses not only a single thread to send the workload to the GPU, this is somewhat more complex to cancel active kernels. in general you need to find the sweetspot when managing new workload and the overhead of thread-scheduling. I will think about it how I can make this more dedicated for the new RTX family cards - they seem to be able to handle a huge number of concurrent threads. On the 10 series cards I always notice that the hashrate drop after some minutes to a level that you can easily reach with lower grid-sizes. Maybe nvidia have redesign the scheduler and thread-switching for the RTX family cards?

Maybe add a report you can print via a key? A lot of miners have a hash report you can get by pressing a key like "h" or "r". It could print out the current gridsize of all the devices.

I also have a question pertaining to the auto intensity check... My RTX cards (a 2080 and a 2060) seem to get bigger bumps from higher gridsizes but I can't seem to find where the hashrate is valid or where it is inflated due to the timing issue you mentioned previously that can occur with too high gridsizes.  Is there a way it can report if the timing is such that it is longer than the 5 second bucket? Maybe a detailed logging mode that tells you how long each device takes to finish its workload?

There is probably a sweet spot for work loads to complete to get a stable hashrate and to better react to job changes... Can current workloads be aborted if a job change is received? That would eliminate unnecessary work on a job that is already completed right?