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

[TrailingStop]

Ahem, so I let it mine for almost a day now with the auto gridsize tuning.

How do I know which gridsize it finally picked? My console output doesn't go back 24 hours...

Good question - that is a point I didn't consider ;-( sorry. I was always waiting for the result - (more like debugging). But you may have enabled the logfile (-log)? Maybe I should print the summary every hour? If you use lager steps it shouldn't take too long until it finishes. I guess the average is between 2 and 4 minutes per sample.

At least - is the performance OK?

[dragonmike]

Ahem, so I let it mine for almost a day now with the auto gridsize tuning.

How do I know which gridsize it finally picked? My console output doesn't go back 24 hours...

Good question - that is a point I didn't consider ;-( sorry. I was always waiting for the result - (more like debugging). But you may have enabled the logfile (-log)? Maybe I should print the summary every hour? If you use lager steps it shouldn't take too long until it finishes. I guess the average is between 2 and 4 minutes per sample.

At least - is the performance OK?

Hah of course not, I forgot to enable logging!
No worries, restarting now with "-i auto 4096 8192 512". Will fine-tune later.
Perf looked good, I had an average of 2.44 MH/s per 1080, which is quite a bit better than it was in earlier versions. I'm not even on the latest driver too so there might still be room to improve.

PS: maybe not printing every hour... I believe the console wouldn't go that far back either. Why not just add it at the end of every hashrate report?

[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!

[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,

no it is not passed - will add that for the next release, good point.

Thanks for pointing to this.

[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,

no it is not passed - will add that for the next release, good point.

Thanks for pointing to this.

Great, Thanks!!!!!!

[merkminer]

Good question - that is a point I didn't consider ;-( sorry. I was always waiting for the result - (more like debugging). But you may have enabled the logfile (-log)? Maybe I should print the summary every hour?

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?

[TrailingStop]

Good question - that is a point I didn't consider ;-( sorry. I was always waiting for the result - (more like debugging). But you may have enabled the logfile (-log)? Maybe I should print the summary every hour?

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?

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?

[dragonmike]

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

[platinum4]

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

[TrailingStop]

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

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.

[joseph32]

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.

[platinum4]

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

[laik2]

Any plans to port it to linux?

[TrailingStop]

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,

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.

[TrailingStop]

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

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?

[TrailingStop]

Any plans to port it to linux?

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).

[darkneorus]

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

[TrailingStop]

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

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

[darkneorus]

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

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

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?

[TrailingStop]

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

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

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?

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.