Pages:
Author

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

newbie
Activity: 15
Merit: 0
Hello, Im getting randomly these error:

16:43:00.036 GPU[0]: 2.427 MH/s  CClk:1.607 GHz MClk:3.999 GHz 37C 50% 32W 75.834 kH/W [A49:R2 3.9%]  LastShare: 00:03:09
16:43:00.037 GPU[1]: 2.437 MH/s  CClk:1.607 GHz MClk:3.999 GHz 38C 50% 31W 78.623 kH/W [A44:R1 2.2%]  LastShare: 00:01:57
16:43:00.037 GPU[2]: 2.320 MH/s  CClk:1.607 GHz MClk:3.999 GHz 36C 50% 31W 74.837 kH/W [A37:R0 0.0%]  LastShare: 00:04:05
16:43:00.038 GPU[3]: 2.332 MH/s  CClk:1.607 GHz MClk:3.999 GHz 38C 50% 31W 75.218 kH/W [A47:R0 0.0%]  LastShare: 00:04:06
16:43:00.038 Rig-Speed[2 min]: 9.516 MH/s 125W 76.126 kH/W [A177:R3 1.7%] Uptime: 00:52:33  LastShare: 00:01:57
16:43:12.082 POOL: Received new job#: 169c
16:43:12.084 Miner: Error ******** GPU[0] CudaError: 702
16:43:12.085 Miner: Error ******** GPU[0] Not enough memory to run algo. GPU disabled.(0/1)
16:43:12.087 Miner: Error ******** GPU[0] Please check if your Virtual Memory setting is OK. You can also try to
16:43:12.088 Miner: Error ******** GPU[0] reduce the intensity/grid-size command line value to fix this problem.
16:43:12.089 Miner: Error ******** GPU[1] CudaError: 702
16:43:12.090 Miner: Error ******** GPU[1] Not enough memory to run algo. GPU disabled.(0/1)
16:43:12.091 Miner: Error ******** GPU[1] Please check if your Virtual Memory setting is OK. You can also try to
16:43:12.092 Miner: Error ******** GPU[1] reduce the intensity/grid-size command line value to fix this problem.
16:43:12.099 Miner: Error ******** GPU[2] CudaError: 702
16:43:12.099 Miner: Error ******** GPU[2] Not enough memory to run algo. GPU disabled.(0/1)
16:43:12.103 Miner: Error ******** GPU[2] Please check if your Virtual Memory setting is OK. You can also try to
16:43:12.106 Miner: Error ******** GPU[2] reduce the intensity/grid-size command line value to fix this problem.
16:43:12.108 Miner: Error ******** GPU[3] CudaError: 702
16:43:12.111 Miner: Error ******** GPU[3] Not enough memory to run algo. GPU disabled.(0/1)
16:43:12.114 Miner: Error ******** GPU[3] Please check if your Virtual Memory setting is OK. You can also try to
16:43:12.115 Miner: Error ******** GPU[3] reduce the intensity/grid-size command line value to fix this problem.
16:43:12.116 Miner: Error ******** All GPUs are disabled. TT-Miner cannot continue and will exit now
16:43:12.125 POOL: Lost connection to zcoin-eu.mintpond.com:3000
16:43:12.126 POOL: Mining temporary stopped


Happening after 10, 30 , 60 minutes. randomly.. any clue ?

This is my config:
  -A MTP-100 -P stratum+tcp://abcdefghasjdhaklsdjallkajdl.worker:[email protected]:3000 --api-bind 127.0.0.1:4033

I tried different intensity or grids..
gtx 1070 ti
using latest NVIDIA drivers
8 GB RAM, 32 GB virtual memory, Celeron CPU

PS: what OC is best for gtx 1070 ti ? increase core? mem ?

Hi,

the error 702 indicates a cuda-timeout. It takes too long until the kernel finishes and the driver terminates it. Please try to use intensities/grid sizes below 10240. For MTP I would start without any OC. Please try to get a stable configuration first.

You can make you command line somewhat simpler - so TT will find the best CUDA version for your installed driver/interface:
-A MTP -P abcdefghasjdhaklsdjallkajdl.worker:[email protected]:3000 --api-bind 127.0.0.1:4033

RAM and Virtual RAM looks OK - Celeron is fine as well.

I would guess you have a OC problem with GPU 0 and maybe GPU 1 - they show rejected shares (but I'm only guessing!).

Please let me know if removing OC helps?




thank you for reply TrailingStop

I tried different configs, memory +200 core +200,  also tried MTP-100 and MTP-101

also tried -i auto 1024 10240 256
it finds best grid etc but still randomly crashing.

was using other miner before with +200/+200 and had no issues..

those rejected shares appeared on any of cards randomly..

PS: using Awesome miner and it adds the "stratum+tcp://" by default, do you think that can be problem?
if its not that, what you mean by your suggested config, cant see any difference ?

Will try to remove all OC
member
Activity: 566
Merit: 16
I pointed out several times that TT miner is the only miner I know that doesn't detect which card crashes... you have to check every card's OC one by one, gl.

Hi,

what do you mean in detail with card crashes detecting? In the about sample TT detects the cards that crashes, first GPU 0 crashes, then 2, 3 and 4. In the coming release it will continue to report crashed and/or not working cards - is it that what you mean?

member
Activity: 566
Merit: 16
Hello, Im getting randomly these error:

16:43:00.036 GPU[0]: 2.427 MH/s  CClk:1.607 GHz MClk:3.999 GHz 37C 50% 32W 75.834 kH/W [A49:R2 3.9%]  LastShare: 00:03:09
16:43:00.037 GPU[1]: 2.437 MH/s  CClk:1.607 GHz MClk:3.999 GHz 38C 50% 31W 78.623 kH/W [A44:R1 2.2%]  LastShare: 00:01:57
16:43:00.037 GPU[2]: 2.320 MH/s  CClk:1.607 GHz MClk:3.999 GHz 36C 50% 31W 74.837 kH/W [A37:R0 0.0%]  LastShare: 00:04:05
16:43:00.038 GPU[3]: 2.332 MH/s  CClk:1.607 GHz MClk:3.999 GHz 38C 50% 31W 75.218 kH/W [A47:R0 0.0%]  LastShare: 00:04:06
16:43:00.038 Rig-Speed[2 min]: 9.516 MH/s 125W 76.126 kH/W [A177:R3 1.7%] Uptime: 00:52:33  LastShare: 00:01:57
16:43:12.082 POOL: Received new job#: 169c
16:43:12.084 Miner: Error ******** GPU[0] CudaError: 702
16:43:12.085 Miner: Error ******** GPU[0] Not enough memory to run algo. GPU disabled.(0/1)
16:43:12.087 Miner: Error ******** GPU[0] Please check if your Virtual Memory setting is OK. You can also try to
16:43:12.088 Miner: Error ******** GPU[0] reduce the intensity/grid-size command line value to fix this problem.
16:43:12.089 Miner: Error ******** GPU[1] CudaError: 702
16:43:12.090 Miner: Error ******** GPU[1] Not enough memory to run algo. GPU disabled.(0/1)
16:43:12.091 Miner: Error ******** GPU[1] Please check if your Virtual Memory setting is OK. You can also try to
16:43:12.092 Miner: Error ******** GPU[1] reduce the intensity/grid-size command line value to fix this problem.
16:43:12.099 Miner: Error ******** GPU[2] CudaError: 702
16:43:12.099 Miner: Error ******** GPU[2] Not enough memory to run algo. GPU disabled.(0/1)
16:43:12.103 Miner: Error ******** GPU[2] Please check if your Virtual Memory setting is OK. You can also try to
16:43:12.106 Miner: Error ******** GPU[2] reduce the intensity/grid-size command line value to fix this problem.
16:43:12.108 Miner: Error ******** GPU[3] CudaError: 702
16:43:12.111 Miner: Error ******** GPU[3] Not enough memory to run algo. GPU disabled.(0/1)
16:43:12.114 Miner: Error ******** GPU[3] Please check if your Virtual Memory setting is OK. You can also try to
16:43:12.115 Miner: Error ******** GPU[3] reduce the intensity/grid-size command line value to fix this problem.
16:43:12.116 Miner: Error ******** All GPUs are disabled. TT-Miner cannot continue and will exit now
16:43:12.125 POOL: Lost connection to zcoin-eu.mintpond.com:3000
16:43:12.126 POOL: Mining temporary stopped


Happening after 10, 30 , 60 minutes. randomly.. any clue ?

This is my config:
  -A MTP-100 -P stratum+tcp://abcdefghasjdhaklsdjallkajdl.worker:[email protected]:3000 --api-bind 127.0.0.1:4033

I tried different intensity or grids..
gtx 1070 ti
using latest NVIDIA drivers
8 GB RAM, 32 GB virtual memory, Celeron CPU

PS: what OC is best for gtx 1070 ti ? increase core? mem ?

Hi,

the error 702 indicates a cuda-timeout. It takes too long until the kernel finishes and the driver terminates it. Please try to use intensities/grid sizes below 10240. For MTP I would start without any OC. Please try to get a stable configuration first.

You can make you command line somewhat simpler - so TT will find the best CUDA version for your installed driver/interface:
-A MTP -P abcdefghasjdhaklsdjallkajdl.worker:[email protected]:3000 --api-bind 127.0.0.1:4033

RAM and Virtual RAM looks OK - Celeron is fine as well.

I would guess you have a OC problem with GPU 0 and maybe GPU 1 - they show rejected shares (but I'm only guessing!).

Please let me know if removing OC helps?


jr. member
Activity: 312
Merit: 2
I pointed out several times that TT miner is the only miner I know that doesn't detect which card crashes... you have to check every card's OC one by one, gl.
newbie
Activity: 15
Merit: 0
Hello, Im getting randomly these error:

16:43:00.036 GPU[0]: 2.427 MH/s  CClk:1.607 GHz MClk:3.999 GHz 37C 50% 32W 75.834 kH/W [A49:R2 3.9%]  LastShare: 00:03:09
16:43:00.037 GPU[1]: 2.437 MH/s  CClk:1.607 GHz MClk:3.999 GHz 38C 50% 31W 78.623 kH/W [A44:R1 2.2%]  LastShare: 00:01:57
16:43:00.037 GPU[2]: 2.320 MH/s  CClk:1.607 GHz MClk:3.999 GHz 36C 50% 31W 74.837 kH/W [A37:R0 0.0%]  LastShare: 00:04:05
16:43:00.038 GPU[3]: 2.332 MH/s  CClk:1.607 GHz MClk:3.999 GHz 38C 50% 31W 75.218 kH/W [A47:R0 0.0%]  LastShare: 00:04:06
16:43:00.038 Rig-Speed[2 min]: 9.516 MH/s 125W 76.126 kH/W [A177:R3 1.7%] Uptime: 00:52:33  LastShare: 00:01:57
16:43:12.082 POOL: Received new job#: 169c
16:43:12.084 Miner: Error ******** GPU[0] CudaError: 702
16:43:12.085 Miner: Error ******** GPU[0] Not enough memory to run algo. GPU disabled.(0/1)
16:43:12.087 Miner: Error ******** GPU[0] Please check if your Virtual Memory setting is OK. You can also try to
16:43:12.088 Miner: Error ******** GPU[0] reduce the intensity/grid-size command line value to fix this problem.
16:43:12.089 Miner: Error ******** GPU[1] CudaError: 702
16:43:12.090 Miner: Error ******** GPU[1] Not enough memory to run algo. GPU disabled.(0/1)
16:43:12.091 Miner: Error ******** GPU[1] Please check if your Virtual Memory setting is OK. You can also try to
16:43:12.092 Miner: Error ******** GPU[1] reduce the intensity/grid-size command line value to fix this problem.
16:43:12.099 Miner: Error ******** GPU[2] CudaError: 702
16:43:12.099 Miner: Error ******** GPU[2] Not enough memory to run algo. GPU disabled.(0/1)
16:43:12.103 Miner: Error ******** GPU[2] Please check if your Virtual Memory setting is OK. You can also try to
16:43:12.106 Miner: Error ******** GPU[2] reduce the intensity/grid-size command line value to fix this problem.
16:43:12.108 Miner: Error ******** GPU[3] CudaError: 702
16:43:12.111 Miner: Error ******** GPU[3] Not enough memory to run algo. GPU disabled.(0/1)
16:43:12.114 Miner: Error ******** GPU[3] Please check if your Virtual Memory setting is OK. You can also try to
16:43:12.115 Miner: Error ******** GPU[3] reduce the intensity/grid-size command line value to fix this problem.
16:43:12.116 Miner: Error ******** All GPUs are disabled. TT-Miner cannot continue and will exit now
16:43:12.125 POOL: Lost connection to zcoin-eu.mintpond.com:3000
16:43:12.126 POOL: Mining temporary stopped


Happening after 10, 30 , 60 minutes. randomly.. any clue ?

This is my config:
  -A MTP-100 -P stratum+tcp://abcdefghasjdhaklsdjallkajdl.worker:[email protected]:3000 --api-bind 127.0.0.1:4033

I tried different intensity or grids..
gtx 1070 ti
using latest NVIDIA drivers
8 GB RAM, 32 GB virtual memory, Celeron CPU

PS: what OC is best for gtx 1070 ti ? increase core? mem ?
member
Activity: 566
Merit: 16
Dear developer, we are waiting for 3 months of release for Linux, when this miracle will happen.

working hard on this. Please keep in mind that this is not my main job and that I do not have 20 developers behind me.
Sorry for the delay.
jr. member
Activity: 69
Merit: 1
Dear developer, we are waiting for 3 months of release for Linux, when this miracle will happen.
member
Activity: 566
Merit: 16
It seems like every few moments the miner drops the load off of the cards down to 0 then back to 100.  Maybe this is harmful to the cards to happen hundreds of times per day... Possible to keep it going like in CryptoDredge? Or am I misunderstanding? Sorry im nub

Hi,

TT-Miner stops mining if it receives a new job, because all solution it will find after that will be invalid and rejected by the pool. First TT needs to create a new Merkle Tree before it can start mining again. That is what you see. I consider to add an option to keep 'dummy' mining on during that phase and ignore solutions. Not sure if this is harmful or not - maybe always full load is harmful and the small drops is a kind of regeneration phase?Huh I do not know.
newbie
Activity: 51
Merit: 0
It seems like every few moments the miner drops the load off of the cards down to 0 then back to 100.  Maybe this is harmful to the cards to happen hundreds of times per day... Possible to keep it going like in CryptoDredge? Or am I misunderstanding? Sorry im nub
member
Activity: 130
Merit: 10
Commandline for the miner is:
tt-miner -a mtp -A MTP-100 -P stratum+tcp://
.nvidia01:[email protected]:3000 --api-bind 127.0.0.1:4035

The rig is on Win10, has local IP 192.168.128.21, firewall is disabled for all networks, WinDefender disabled via registry. IPv6 is disabled.

The telnet localhost 4035 - miner answering.
The telnet 127.0.0.1 4035 - miner answering.

Trying from another rig, in the same network (192.168.128.20)
telnet 192.168.128.21 4035 - connection denied.
No wonders as you have bound API to 127.0.0.1 which is localhost. It is not accessible from LAN.
Technically you should modify the command line to utilize --api-bing 0.0.0.0:4035

0.0.0.0 means ALL of the computer IP addresses present, so it should include 127.0.0.1 and 192.168.128.21 which I assume is your LAN IP address.

However, looking at what TrailingStop wrote above "0.0.0.0 will be translated to localhost (127.0.0.1)." I doubt this will work until TT fixes this behavior.

OR

Just use --api-bind 192.168.128.21:4035 and API will be accessible from LAN, but you may have issues with your miner (awesomeminer or NHML or smth else) if any.

Thanks for explanation Smiley
BTW, --api-bind 192.168.128.21:4035 also not working Undecided
Waiting for the new version Smiley
member
Activity: 566
Merit: 16
Commandline for the miner is:
tt-miner -a mtp -A MTP-100 -P stratum+tcp://
.nvidia01:[email protected]:3000 --api-bind 127.0.0.1:4035

The rig is on Win10, has local IP 192.168.128.21, firewall is disabled for all networks, WinDefender disabled via registry. IPv6 is disabled.

The telnet localhost 4035 - miner answering.
The telnet 127.0.0.1 4035 - miner answering.

Trying from another rig, in the same network (192.168.128.20)
telnet 192.168.128.21 4035 - connection denied.
No wonders as you have bound API to 127.0.0.1 which is localhost. It is not accessible from LAN.
Technically you should modify the command line to utilize --api-bing 0.0.0.0:4035

0.0.0.0 means ALL of the computer IP addresses present, so it should include 127.0.0.1 and 192.168.128.21 which I assume is your LAN IP address.

However, looking at what TrailingStop wrote above "0.0.0.0 will be translated to localhost (127.0.0.1)." I doubt this will work until TT fixes this behavior.

OR

Just use --api-bind 192.168.128.21:4035 and API will be accessible from LAN, but you may have issues with your miner (awesomeminer or NHML or smth else) if any.

Hi,

This is 100% correct. I bound 127.0.0.1 to localhost. I was not aware that it should bound to all. Will fix that in next release.
Thanks for pointing to this issue.
newbie
Activity: 44
Merit: 0
Commandline for the miner is:
tt-miner -a mtp -A MTP-100 -P stratum+tcp://
.nvidia01:[email protected]:3000 --api-bind 127.0.0.1:4035

The rig is on Win10, has local IP 192.168.128.21, firewall is disabled for all networks, WinDefender disabled via registry. IPv6 is disabled.

The telnet localhost 4035 - miner answering.
The telnet 127.0.0.1 4035 - miner answering.

Trying from another rig, in the same network (192.168.128.20)
telnet 192.168.128.21 4035 - connection denied.
No wonders as you have bound API to 127.0.0.1 which is localhost. It is not accessible from LAN.
Technically you should modify the command line to utilize --api-bing 0.0.0.0:4035

0.0.0.0 means ALL of the computer IP addresses present, so it should include 127.0.0.1 and 192.168.128.21 which I assume is your LAN IP address.

However, looking at what TrailingStop wrote above "0.0.0.0 will be translated to localhost (127.0.0.1)." I doubt this will work until TT fixes this behavior.

OR

Just use --api-bind 192.168.128.21:4035 and API will be accessible from LAN, but you may have issues with your miner (awesomeminer or NHML or smth else) if any.
member
Activity: 130
Merit: 10
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 Sad

Is there some additional options that should be set to get remote stats via API?..

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.
Thanks for reply Smiley

Previously I was using 2.1.14 and there were no such problem Undecided Didn't tested another older versions yet...
Then, what I should set in "-b" option to allow API requests from any address?.. Looks like, that regardless of the settings, the miner accepts only connections from locahost Sad

Hi,

the miner does not filter any addresses. It looks to me like you have 2 (or more) network interfaces and the API bind to the wrong. The address you use for the api command is to tell the miner which network interface to enable for api access. If you have only one localhost is fine, if you have more it makes sense to tell the miner which one to use. You can check your IPs with 'ipconfig -all' command in the console. Let me know if that help or if you still have problems to get connected.

No, there is no 2nd interface present. The ping command to "localhost" corresponds to 127.0.0.1
Commandline for the miner is:
tt-miner -a mtp -A MTP-100 -P stratum+tcp://
.nvidia01:[email protected]:3000 --api-bind 127.0.0.1:4035

The rig is on Win10, has local IP 192.168.128.21, firewall is disabled for all networks, WinDefender disabled via registry. IPv6 is disabled.

The telnet localhost 4035 - miner answering.
The telnet 127.0.0.1 4035 - miner answering.

Trying from another rig, in the same network (192.168.128.20)
telnet 192.168.128.21 4035 - connection denied.

When miner starting, it says:
API-Interface enabled. Listening on 1

Any ideas?..
newbie
Activity: 4
Merit: 0
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,

to enable the power usage in Awesome miner you should follow the recommendations for "Map to system montioring".
https://support.awesomeminer.com/support/solutions/articles/35000086014-display-additional-gpu-information

Please let me know if that is what you were locking for.

Thanks.


That only works in managed miner mode (having the awesome miner software installed directly on each of the miner systems directly)
I do not use any "managed" miners - they are all external miners. And the only way to monitor an external miner is with the API.
Thank you for the info and option, If i install AM on the miner itself, this would be VERY HELPFUL.

Hi,

you wish will come true. I worked together with Paktrike from AM and he made the required modifications to AM. In the next release of AM and TT will show you the power-usage of each GPU.



 Grin yay
member
Activity: 566
Merit: 16
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,

to enable the power usage in Awesome miner you should follow the recommendations for "Map to system montioring".
https://support.awesomeminer.com/support/solutions/articles/35000086014-display-additional-gpu-information

Please let me know if that is what you were locking for.

Thanks.


That only works in managed miner mode (having the awesome miner software installed directly on each of the miner systems directly)
I do not use any "managed" miners - they are all external miners. And the only way to monitor an external miner is with the API.
Thank you for the info and option, If i install AM on the miner itself, this would be VERY HELPFUL.

Hi,

you wish will come true. I worked together with Paktrike from AM and he made the required modifications to AM. In the next release of AM and TT will show you the power-usage of each GPU.

member
Activity: 566
Merit: 16
hi, im really curious that gs does actually affect anything? Huh

gs defines together with the blocksize the number of threads to execute. Blocksize is calculated and you cannot change it.

hmm, still dont get it. it affect the lifespan of gpu or use more cpu & gpu resources with gs size?

Maybe I'm too bad in explaining. Please check this information:

https://www.youtube.com/watch?v=kzXjRFL-gjo
http://cuda-programming.blogspot.com/2013/01/threads-and-blocks-in-detail-in-cuda.html

There are much more - just try to google 'cuda grid block'. You will get lots of information about grid/block/threads and how they are related to each other in GPU kernel programming.

Hope the helps more!

OK I'm no rocket surgeon here Wink

If I have a 7 card rig with decent GPU's (1070ti's) with a low-end CPU (G4400 dual-core Pentium) ...
Should I focus on smaller gridsize (perhaps between 4096-8192)?

And if I had a better CPU, a larger gridsize may or should work better?


Hi,

I can only give you my personal opinion and preference only. there will be others out there with very different opinions, I guess you have to find the best settings for you and your configuration.

For the algos that are supported by TT the CPU doesn't play a big role as well as RAM. I know of systems that works well with 8GPUs and have a celeron and 4GB RAM only. You CPU, RAM-size and HD/SSD size will not have a very big impact on your overall performance. Changing the grid-size changes the configuration of the kernel that runs on your GPU. I prefer lower values since I noticed that on my system I see much faster stable hashrates. With higher/very high (over 8192) gridsizes I see the hashrate dropping over a long period until a stable level is reached, so I chose in most cases values between 256 and 4096. But this observation is very depended of the system and GPU you use. Also please to note that I do not run hundreds of GPUs - my experience if 1070 and 1060/6GB ONLY. I never made some investigations how different gridsizes impact the lifetime of a GPU - I leave that to someone else.

So my best advise for you is to make your own tests and find the settings that works best for you and the system you have.



newbie
Activity: 6
Merit: 0
hi, im really curious that gs does actually affect anything? Huh

gs defines together with the blocksize the number of threads to execute. Blocksize is calculated and you cannot change it.

hmm, still dont get it. it affect the lifespan of gpu or use more cpu & gpu resources with gs size?

Maybe I'm too bad in explaining. Please check this information:

https://www.youtube.com/watch?v=kzXjRFL-gjo
http://cuda-programming.blogspot.com/2013/01/threads-and-blocks-in-detail-in-cuda.html

There are much more - just try to google 'cuda grid block'. You will get lots of information about grid/block/threads and how they are related to each other in GPU kernel programming.

Hope the helps more!

OK I'm no rocket surgeon here Wink

If I have a 7 card rig with decent GPU's (1070ti's) with a low-end CPU (G4400 dual-core Pentium) ...
Should I focus on smaller gridsize (perhaps between 4096-8192)?

And if I had a better CPU, a larger gridsize may or should work better?
legendary
Activity: 2912
Merit: 1091
--- ChainWorks Industries ---
where link to linux version ?

A Linux version is being worked on ...

It is not available just yet, therefore there is no link to any Linux version (Debian or RHEL based) yet.

#crysx
newbie
Activity: 59
Merit: 0
where link to linux version ?
member
Activity: 566
Merit: 16
hi, im really curious that gs does actually affect anything? Huh

gs defines together with the blocksize the number of threads to execute. Blocksize is calculated and you cannot change it.

hmm, still dont get it. it affect the lifespan of gpu or use more cpu & gpu resources with gs size?

Maybe I'm too bad in explaining. Please check this information:

https://www.youtube.com/watch?v=kzXjRFL-gjo
http://cuda-programming.blogspot.com/2013/01/threads-and-blocks-in-detail-in-cuda.html

There are much more - just try to google 'cuda grid block'. You will get lots of information about grid/block/threads and how they are related to each other in GPU kernel programming.

Hope the helps more!
Pages:
Jump to: