search

fireice-uk / xmr-stak

Free Monero RandomX Miner and unified CryptoNight miner
GNU General Public License v3.0
4.05k stars 1.79k forks source link

GeForce GTX 1080 Ti default config is crashing #1390

Closed borzaka closed 6 years ago

borzaka commented 6 years ago

The default config for GeForce GTX 1080 Ti is crashing immediately: image

Default nvidia.txt

"gpu_threads_conf" :
[
  // gpu: GeForce GTX 1080 Ti architecture: 61
  //      memory: 9309/11264 MiB
  //      smx: 28
  { "index" : 0,
    "threads" : 54, "blocks" : 84,
    "bfactor" : 6, "bsleep" :  25,
    "affine_to_cpu" : false, "sync_mode" : 3,
  },
  // gpu: GeForce GTX 1080 Ti architecture: 61
  //      memory: 9309/11264 MiB
  //      smx: 28
  { "index" : 1,
    "threads" : 54, "blocks" : 84,
    "bfactor" : 6, "bsleep" :  25,
    "affine_to_cpu" : false, "sync_mode" : 3,
  },
  // gpu: GeForce GTX 1080 Ti architecture: 61
  //      memory: 9310/11264 MiB
  //      smx: 28
  { "index" : 2,
    "threads" : 54, "blocks" : 84,
    "bfactor" : 6, "bsleep" :  25,
    "affine_to_cpu" : false, "sync_mode" : 3,
  },
],

If I change the bfactor to 8, problem solved.

Basic information

Additional information

Spudz76 commented 6 years ago

I have never had autoconfig result in anything worth running for long. I'm not sure why people use it other than as a loose starting point.

Better off searching the Internet for what worked nice for others with similar GPU model and just use those. Autoconfig is guessing, using math and based on memory amount and GPU capability, but still guessing. Newer versions guess a little more aggressive and can/do crash. Turn down threads to 19 and I bet it works also (similar to higher bfactor, but bfactor hurts more than less threads as far as I can tell from testing).

borzaka commented 6 years ago

It would'nt be nice that the default settings was working out-of-the-box for dummies? If there is a better settings for 1080 Ti, why isn't it integrated/recognized?

I'am lowered the threads to 48, but crashed again. Changing bfactor from 6 to 8 was solved this problem too. So, obviously 6 for bfactor for 1080 Ti is a wrong default setting.

Spudz76 commented 6 years ago

Noted, but not sure why that helps. I run like bfactor 0 or 1 on everything and tune the rest to not crash.

I think the autotune 'rules' may be different (wildly different) depending on the card and its specific design. Much of that can't be probed or calculated to the extent that would allow for the correct best settings to be known.

Things like memory bus width vs CUDA cores vs "warps" vs who knows what else. Currently I believe the autoconfig only looks at memory total and the "smx" count and comes up with ideas only from that. Of course a card with 13 smx but a 128 bit memory bus would not be happy on the same settings as a 384-bit memory bus. Bottlenecking in a different place, essentially. Autotune would have to be able to know what each card models weaknesses and strengths were.

Not too many people had been using the 10xx series because they are still useful for Ethereum and do more profit that way. The 3GB cards just recently (some months) became useless for eth due to DAG size and so now people started trying CryptoNight on them.

Basically too 'new' to know what exactly they enjoy for settings (as compared to a 770 or 970 people have been xmr-stak'n for quite some time). Also adding to the problem is nVidia nerfed the 10xx series pretty hard for mining (P2 lock / no P0 without Windows and hacks on top of that, and who knows what other intentional hurdles they added).

Pretty sure autotune would suck on a Titan also, because nobody is running CryptoNight coins on such a crazy expensive and overpowered card when they could be mining something way more profitable on it.

Spudz76 commented 6 years ago

I still think in your case mostly it's the 11GB is causing it to overestimate and set way too high both threads and blocks. Higher than the smx's can handle. Again, you're probably the first person on the planet to run CryptoNight on such a huge card.

borzaka commented 6 years ago

I know that 1080 Ti is not for CryptoNight, but I think you have heard about the Monero hard fork. It was the most profitable for a couple of days. And I started mining it with all I've got :) These times are over, I just wanted to share my experience with XMR-Stak and the default 1080 Ti settings.

I'll look into this P0 state stuff, thank for the heads up.

Spudz76 commented 6 years ago

The only reason it got profitable was all the users trying and failing to adjust their software, so the network overall hashrate dropped, making each post-fork miner worth more until everyone got their new-fork software working. Many "noobish" users got banned from pools for not knowing they had to change software (100% invalid shares, booted, byeeee). So many had to jump pools or wait or hit up support and get unbanned, etc (delays keeping the network hashrate low).

Also all the wormed/trojanned computers out there on basically every slightly unprotected server (Monero leader is proud of) all broke too, unless they got rewormed with the new versions. So a large chunk of aggregate hashrate disappeared as well, no doubt.

Truly on a PPLNS there was no actual higher profit, by the time it scored your 6/12/24-hour average (whatever the pool basis is) the cash grab was over. You would have had to be mining hard before during and after the fork, to really see any sort of bump.

Also the USD/BTC to XMR values went to dirt (comparatively) at the same time which balanced it out to pretty much no profit bump. I used to have over 90 bux of XMR now it's freakin maaaaybe 60 / who cares if I made $2/day more for a week, it was lost in the valuation burp. Not real sure if I'm going to bother to wait for it to come back up to $220/xmr or just trade out now and ride some other coin on the exchanges.

All that being said, Karbo is really hosed up right now which I had changed to just before the fork (when the Bitmain CryptoNight ASIC miner came out, which was the main reason for the hardfork). Now there is some bug with difficulty, Cryptopia had it locked for deposit and withdrawls, and even though its unlocked now and I got a destination address and paymentid the KRB that I sent has 0 confirmations and it's been two days and counting. Plus, its value went to crap too.

So basically I fell for FUD about the ASICs and whether or not the hardfork would even work to block them, switched all my rigs to Karbo, and then Monero had its little moonrise, and then the entire Karbo net pretty much crashed apparently. So now that my Karbo pool is AWOL, payments won't work, and I can't get anything out of the wallet, I'm back on XMR because I'm not trying that bullcrap again (electroneum keeps whispering to me, must IGNORE)

JerichoJones commented 6 years ago

How-TO and tuning your hardware is not within the scope of Github support and will most likely be ignored. It is just not possible for us to know how to tune every model/version of a component.

How-TO and tuning type questions are better suited to forums such as REDDIT/r/moneromining. There is a much larger audience of people that have probably already been through and resolved the same issue.

Make sure you have reviewed the documentation on the Github as well as running:

    xmr-stak --help

^^ This will answer most How-TO type questions. ^^

borzaka commented 6 years ago

There is nothing in the docs, nor in the --help about bfactor, and how to adjust it. I have found this in the source code, but haven't seen in my case, only the error in my first post screenshot.

suggestion: Try to increase the value of the attribute 'bfactor' in the NVIDIA config file.

So, this error massage is not working/showing?

I still believe, that XMR-Stak should generate a working default config file, what can be improved by the user. Someone said that now it's too aggressive. Make it less aggressive to work with higher probability out-of-the-box.

I'am trying to help you guys with my suggestion. I have found a problem and figured out a solution for a GeForce GTX 1080 Ti, and shared here.

Spudz76 commented 6 years ago

This is a knife-edge situation. Change autoconfig to work at all costs, everyone posts bug reports about how it's too slow and stupid it should be fast always. Change autoconfig to be more like they asked for, and then you people come around bitching it crashed for picking too aggressive.

Pretty soon, it will have no autoconfig and you can go get your example configs from Reddit.

psychocrypt commented 6 years ago

The problem ist that is not as easy to generate a working config which also give good performance for nvidia gpus. There is an technikel issues with the runtime memory which can not calculated in advanced. The other point is the fact that windows kills all cuda kernel those run a few seconds. On other OS bfactor is not needed it is only the shitty OS Windows. anever the less I work on a solution for that but it is a question of time to imolement it.