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

[somaton]

Ok, will try and report back when it is released. One more request: is it possible to show real, human readable block number + block difficulty (something like t-rex: x21s block 194268, diff 281.436)? It will be very usefull to know for example which coin/block is mining right now, because something like this "received new job 10d5e" is just plain useless, with no real info. Thanks for your work!

[1715037409]

1715037409

[1715037409]

1715037409

[1715037409]

1715037409

[1715037409]

1715037409

[hogwash.89m]

because PM works once in a day have to write answer here: looks like beta2-version fixed connections bug for me. But miner doesn't pausing process while no connect.

Yes, it pause the mining and then when connection is restored it continues mining (on failover pool if at the moment try connect to it)

1. normal mining power consumption (954 W)
2. cable (connection lost) power consumption (311 W) after around ~1 minute (miner don't suspend mining at the moment when connection is lost, which is OK)
3. message in miner, after LAN cable is pluged back mining resumes on retrying pool (cloud be failover one)

https://imgur.com/a/QMdSZrn

Off topic, but what is the power-monitoring device you have plugged in in your last picture in your link? 

@dkmontague you asked about power monitoring device.
In last picture it's just desktop with TT-Miner and Afterburner (Watts in TT-Miner are readings from Nvidia NVLM API, software reading).

And device in power outlet is I think this one, EU socket type:

https://www.aliexpress.com/item/230V-50Hz-Power-Meter-Energy-Monitor-EU-Watt-Volt-Amp-Frequency-Monitor-Analyzer-Cumulative-Kilowatt-Hour/32817695107.html

(PS: I think it can be found cheaper on other shops)

Or this one US plug type:

https://www.amazon.com/FLOUREON-Electricity-Monitor-Voltage-Measuring/dp/B07B3VQBZH

All the best,

[dkmontague]

because PM works once in a day have to write answer here: looks like beta2-version fixed connections bug for me. But miner doesn't pausing process while no connect.

Yes, it pause the mining and then when connection is restored it continues mining (on failover pool if at the moment try connect to it)

1. normal mining power consumption (954 W)
2. cable (connection lost) power consumption (311 W) after around ~1 minute (miner don't suspend mining at the moment when connection is lost, which is OK)
3. message in miner, after LAN cable is pluged back mining resumes on retrying pool (cloud be failover one)

https://imgur.com/a/QMdSZrn

Off topic, but what is the power-monitoring device you have plugged in in your last picture in your link? 

@dkmontague you asked about power monitoring device.
In last picture it's just desktop with TT-Miner and Afterburner (Watts in TT-Miner are readings from Nvidia NVLM API, software reading).

And device in power outlet is I think this one, EU socket type:

https://www.aliexpress.com/item/230V-50Hz-Power-Meter-Energy-Monitor-EU-Watt-Volt-Amp-Frequency-Monitor-Analyzer-Cumulative-Kilowatt-Hour/32817695107.html

(PS: I think it can be found cheaper on other shops)

Or this one US plug type:

https://www.amazon.com/FLOUREON-Electricity-Monitor-Voltage-Measuring/dp/B07B3VQBZH

All the best,

Thanks brother!

[artful]

where link to linux version ?

[platinum4]

2.2.2b2 does not honor -gs, adding -gs #### doesn't work just runs as default

[TrailingStop]

2.2.2b2 does not honor -gs, adding -gs #### doesn't work just runs as default

Hi,

-gs does not work together with -i. Can you please check if you add both options to your command line?

Thanks,

[TrailingStop]

Version 2.2.2 release

- re-connection doesn't work on some systems after the connection was interrupted
- miner continues with work after connection was interrupted
-  new function to find best grid size settings for your system/algo combination
       -i auto [startvalue] [endvalue] [stepsize]
        the miner will iterate through all gridsizes from startvaue to endvalue. For example: i- auto 1024 2048 128 will go from 1024 to 2048 with a
        stepsize of 128. If all samples are tested the miner prints the result onto the console and selects the best performing gridsize as working parameter.
        You might want to use the value and modify you command line to use the -gs option with the found value to avoid new tests in the next run.
        This check takes quite long - depending of course from you parameter, but it might take some time for each sample until the hashrates are stable.

         Please keep in mind that the hashrates changes (will drop) when you GPU reaches temp or power limit.

Please let me know if you run into any issues.

downloadlink: https://TradeProject.de/download/Miner/TT-Miner.zip

Happy mining!

[dragonmike]

Hi, sorry been out of the loop for a little while... Can you suggest a good gridsize range to test with on 1080's please? Would like to give that new version with auto testing a try... Something like 4096-8192 maybe?

[TrailingStop]

Hi, sorry been out of the loop for a little while... Can you suggest a good gridsize range to test with on 1080's please? Would like to give that new version with auto testing a try... Something like 4096-8192 maybe?

Hi,

No problem. I would start with 1024 to 8192 step 1024. Then go with a smaller stepsize around the resulting best performing value and maybe a second time again around the best performer.

Let me know if you see any benefit in that function. I'm not sure if it makes sense the long term?

[dragonmike]

Hi, sorry been out of the loop for a little while... Can you suggest a good gridsize range to test with on 1080's please? Would like to give that new version with auto testing a try... Something like 4096-8192 maybe?

Hi,

No problem. I would start with 1024 to 8192 step 1024. Then go with a smaller stepsize around the resulting best performing value and maybe a second time again around the best performer.

Let me know if you see any benefit in that function. I'm not sure if it makes sense the long term?

It definitely makes sense - how long does it test each step?
Btw the miner is definitely faster than it used to be. I seem to already be doing around 2.44 MHs/1080. Looking forward to the final figure @ sweetspot gridsize...

[TrailingStop]

Hi, sorry been out of the loop for a little while... Can you suggest a good gridsize range to test with on 1080's please? Would like to give that new version with auto testing a try... Something like 4096-8192 maybe?

Hi,

No problem. I would start with 1024 to 8192 step 1024. Then go with a smaller stepsize around the resulting best performing value and maybe a second time again around the best performer.

Let me know if you see any benefit in that function. I'm not sure if it makes sense the long term?

It definitely makes sense - how long does it test each step?
Btw the miner is definitely faster than it used to be. I seem to already be doing around 2.44 MHs/1080. Looking forward to the final figure @ sweetspot gridsize...

Hi. It is not possible to say how long a single sample may take. For the hashrate I use 5 second buckets that contain the hashrate for the 5 seconds period. The I calculate for 12 buckets the standard deviation.  If all samples lay in the interval -sigma to +sigma I treat this hashrate as stable and continue with the next sample....

[joseph32]

Something is bugged in the new version if you set a fixed gridsize, instead of just the intensity. The hashrate jumps every few minutes up or down. It doesn't matter if it's a single rig, or a multi-rig. All cards jumps up or down together in the same time.

2.1.20 was fine, 100% stable hashrate with intensity (sorry, never run with gridsize)
2.2.1 haven't tested yet, so dunno if that bug excist there too

Windows 10, latest updates. nVidia 419.67. Tested with 1080 Ti's, 2080 Ti's, 2070's.

Here are two screenshots from just one card. You can clearly see the jump from 3.5 MH/s to 4.3 MH/s, between it jumped from 4.3 back to 3.5 and 10 minutes later again from 3.5 to 4.3. The time between jumping isn't fixed, it can be few minutes, or 10-20 minutes, or anything else. But its jumping all the time on every rig.




Edit: just did a quick 1-hour-test on that rig. -i 16 gives a 100% stable hashrate of 3.3. Going back to -gs 41472 its jumping to 3.5 or 4.3. It doesn't matter which gridsize, its always jumping up or down. So the gridsize seems to be buggy.
Edit 2: Also checked the core clock between the jumps, just in case. But the core stays always in the same range, no matter if it jumps up or down.
Edit 3: Will also check the pool-hashrate later after few more hours running. Will it be the lower hashrates, or will it be the average between low and high...
Edit 4: Checked again the older 2.1.20 with the same gridsize which I got from 2.2.2 auto tune. There are no strickt jumps from (for example) 3.5 to 4.3 and 4.3 to 3.5. But a very smooth sinus-wave between (in this case) 3.7 to 4.0 to 3.7 to 4.0... Strange picture and dunno if this is supposed. Can you please check that? Pool is 2Miners if this matters. Thanks!

[dkmontague]

There is something wrong with this release.... After I ran it, my miners started going 3.3 instead of 3.65-3.7.  

[TrailingStop]

Something is bugged in the new version if you set a fixed gridsize, instead of just the intensity. The hashrate jumps every few minutes up or down. It doesn't matter if it's a single rig, or a multi-rig. All cards jumps up or down together in the same time.

2.1.20 was fine, 100% stable hashrate with intensity (sorry, never run with gridsize)
2.2.1 haven't tested yet, so dunno if that bug excist there too

Windows 10, latest updates. nVidia 419.67. Tested with 1080 Ti's, 2080 Ti's, 2070's.

Here are two screenshots from just one card. You can clearly see the jump from 3.5 MH/s to 4.3 MH/s, between it jumped from 4.3 back to 3.5 and 10 minutes later again from 3.5 to 4.3. The time between jumping isn't fixed, it can be few minutes, or 10-20 minutes, or anything else. But its jumping all the time on every rig.

Edit: just did a quick 1-hour-test on that rig. -i 16 gives a 100% stable hashrate of 3.3. Going back to -gs 41472 its jumping to 3.5 or 4.3. It doesn't matter which gridsize, its always jumping up or down. So the gridsize seems to be buggy.
Edit 2: Also checked the core clock between the jumps, just in case. But the core stays always in the same range, no matter if it jumps up or down.
Edit 3: Will also check the pool-hashrate later after few more hours running. Will it be the lower hashrates, or will it be the average between low and high...

Hi, my guess is that it is related to the extreme gridsize you use. Can you please confirm that you use 41471? That will put a workload of about 13,271,040 Threads to the gpu. That in turn will take about 4 seconds to finish. Since the miner uses streams it puts several of these workload to the GPU. For the hashrate calculation is uses time frames of 5 seconds. Maybe it happened sometimes that a bucket is left without hashrate it might be that you see jumps in the hashrate. I will make you a version with a 10 seconds timeframe so that you see a stable hashrate. Anyway I think you should consider to use smaller gridsizes. I made the observation that these very high values doesn't give you stable high hashrates - they seem to drop over time to a level that you can get with lower gridsizes as well. It have also other advantages to use lower vales. First is that the miner waits until all thread a finished until it send the solution to the pool. So the sooner the work is done the sooner you get your shares at the pool. With a smaller workload the miner can also react much faster on new jobs and the risk of rejected shares isn't that high.

Please let me know if you see more stable hashrates with the modifies version. I send you the link in a DM.

Thanks.

[TrailingStop]

There is something wrong with this release.... After I ran it, my miners started going 3.3 instead of 3.65-3.7.  

Hi,

you have some more information for me please? Algo, gpu, pool, intensity or gridsize?

Thanks.

[joseph32]

Wow, late in the night and you are still here

Yes, its the highest number I get from auto-tune, so I thought its fine to use. I also thought that they are high, even higher as with intensity 16 or 17. Will test your version later today after sleeping and let you know, thank you!

So is it better to try a lower gridsize with an OK hashrate instead of the max possible hashrate, but also a very high gridsize? Here I have a good example:

GPU0 Grid: 52736 Hashrate: 5.400
GPU0 Grid: 27136 Hashrate: 5.557
GPU0 Grid: 36352 Hashrate: 5.584
GPU0 Grid: 38400 Hashrate: 5.623

Better take the 27136 and not the 38400?

Maybe you have already some recommendations for good gridsizes?

[TrailingStop]

Wow, late in the night and you are still here

Yes, its the highest number I get from auto-tune, so I thought its fine to use. I also thought that they are high, even higher as with intensity 16 or 17. Will test your version later today after sleeping and let you know, thank you!

So is it better to try a lower gridsize with an OK hashrate instead of the max possible hashrate, but also a very high gridsize? Here I have a good example:

GPU0 Grid: 52736 Hashrate: 5.400
GPU0 Grid: 27136 Hashrate: 5.557
GPU0 Grid: 36352 Hashrate: 5.584
GPU0 Grid: 38400 Hashrate: 5.623

Better take the 27136 and not the 38400?

Maybe you have already some recommendations for good gridsizes?

HI,

yes- support in important and I want to fix new bugs as soon as possible - and it is early here 4:40 am

Yes, that is correct - always choose lower numbers, that will give you advantages over the long run. I never tried values m,ore than 8192. What gpu do you use?

[joseph32]

1080 Ti's, 2080 Ti's, 2060's and 2070's. Usually I used -i 16 on all, a few 1080 Ti's also with -i 17 because of better hashrate.

The auto tune is a great tool, so will do more tests later today with lower grids and your 10-sec-version.

[TrailingStop]

1080 Ti's, 2080 Ti's, 2060's and 2070's. Usually I used -i 16 on all, a few 1080 Ti's also with -i 17 because of better hashrate.

The auto tune is a great tool, so will do more tests later today with lower grids and your 10-sec-version.

That's great. Thanks for testing and reporting.

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