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

Great, Thanks!!!!!!

Hi,

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

Thanks for pointing to this.

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!

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?

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?

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

That's great. Thanks for testing and reporting.

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.

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?

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,

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

Thanks.

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.

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

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!

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

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,

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?

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?

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!

Hi,

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

Thanks,