lbr
|
|
July 19, 2014, 02:21:30 PM |
|
RAM doesn't matter at all (at least on linux, can't say for sure with Windows). I don't know who started that rumour, but it's bullshit. I have run all of my rigs on 2GB of ram, and I've never seen any performance loss or inability to mine an algorithm as a result.
Not a BS at least for Win rigs. To reproduce - set large enough TC on a rig with a lot of GPUs, f.e. 6x290 with TC 32768 or 6x7950 with TC 40960/24000. On rigs with less than 8GB?(depends) of RAM some cards will report -4 kernel error. Stick some more ram - issue will go away. Imo that's only for scrypt/scryptn/scrypt-jane(and other memory intensive algos), cause for those algos higher TC means higher GPU RAM usage. Prly thats cause of DMA or maybe OCL or Win maps GPU RAM into system RAM or something like that.. But RAM does not affect performance, only lack of it prevents some GPUs starting up.
|
|
|
|
BrewCrewFan
|
|
July 19, 2014, 04:22:22 PM |
|
RAM doesn't matter at all (at least on linux, can't say for sure with Windows). I don't know who started that rumour, but it's bullshit. I have run all of my rigs on 2GB of ram, and I've never seen any performance loss or inability to mine an algorithm as a result.
Not a BS at least for Win rigs. To reproduce - set large enough TC on a rig with a lot of GPUs, f.e. 6x290 with TC 32768 or 6x7950 with TC 40960/24000. On rigs with less than 8GB?(depends) of RAM some cards will report -4 kernel error. Stick some more ram - issue will go away. Imo that's only for scrypt/scryptn/scrypt-jane(and other memory intensive algos), cause for those algos higher TC means higher GPU RAM usage. Prly thats cause of DMA or maybe OCL or Win maps GPU RAM into system RAM or something like that.. But RAM does not affect performance, only lack of it prevents some GPUs starting up. The key is the algos you listed... for all the rest like X11 and whatnot, TC does nothing to boost speed one way or another.... in fact I just leave that blank now or dont even put it in.
|
|
|
|
badman74
|
|
July 19, 2014, 04:44:02 PM |
|
I'm currently getting a virtual TON of "stale shares detected, discarding." Which variable(s) should I add or tweak to try and fix this problem? Is this normally an Intensity issue?
Thank you ahead of time!
try to dial back you intensity till your hashrate starts to drop sometimes if you set it too high you will get stale shares also can be caused by latency to the pool server if you are on a p2pool try to find one with the lowest latency
|
|
|
|
opet
Newbie
Offline
Activity: 57
Merit: 0
|
|
July 19, 2014, 04:46:36 PM |
|
try to dial back you intensity till your hashrate starts to drop sometimes if you set it too high you will get stale shares
that worked! It seems that sg5 doesn't necessarily work well with all the settings I've used in the past with the older 4.0.1. thank you!
|
|
|
|
cgladue
Member
Offline
Activity: 97
Merit: 10
|
|
July 20, 2014, 12:53:45 AM |
|
why is it when i do a sgminer -n with the latest build on the v5 branch my card is not recognised... but if i go back and use 4.1.271 it shows up perfectly fine ?
its a Pitcairn Gigabyte R9 270 GPU
is there any reason that Pircairn support would of been removed in the latest branch of sgminer ?
|
|
|
|
badman74
|
|
July 20, 2014, 01:01:29 AM |
|
why is it when i do a sgminer -n with the latest build on the v5 branch my card is not recognised... but if i go back and use 4.1.271 it shows up perfectly fine ?
its a Pitcairn Gigabyte R9 270 GPU
is there any reason that Pircairn support would of been removed in the latest branch of sgminer ?
don't know of any reason support would be removed, but that info should be coming though the adl_sdk i think you might open an issue at https://github.com/sgminer-dev/sgminer/issues?state=openyou will be more likely to get info on that from there edit: if you built it from source be sure you added the ADL_SDK/*.h files to sgminer/ADL_SDK/ before you build
|
|
|
|
cgladue
Member
Offline
Activity: 97
Merit: 10
|
|
July 20, 2014, 01:58:48 AM |
|
why is it when i do a sgminer -n with the latest build on the v5 branch my card is not recognised... but if i go back and use 4.1.271 it shows up perfectly fine ?
its a Pitcairn Gigabyte R9 270 GPU
is there any reason that Pircairn support would of been removed in the latest branch of sgminer ?
don't know of any reason support would be removed, but that info should be coming though the adl_sdk i think you might open an issue at https://github.com/sgminer-dev/sgminer/issues?state=openyou will be more likely to get info on that from there edit: if you built it from source be sure you added the ADL_SDK/*.h files to sgminer/ADL_SDK/ before you build thank you badman, i am exploring an idea, i see somehow intel openCL drivers got installed and when i doo sgminer -n it shows Inten Open CL 1.2 but on my other rig it correctly lists AMD OpenCL ... so im blowing away the windows install and doing a fresh install and trying again... still weird why the older 4.x branch would still be able to identify my card but the 5.0 cant.
|
|
|
|
badman74
|
|
July 20, 2014, 02:17:32 AM |
|
why is it when i do a sgminer -n with the latest build on the v5 branch my card is not recognised... but if i go back and use 4.1.271 it shows up perfectly fine ?
its a Pitcairn Gigabyte R9 270 GPU
is there any reason that Pircairn support would of been removed in the latest branch of sgminer ?
don't know of any reason support would be removed, but that info should be coming though the adl_sdk i think you might open an issue at https://github.com/sgminer-dev/sgminer/issues?state=openyou will be more likely to get info on that from there edit: if you built it from source be sure you added the ADL_SDK/*.h files to sgminer/ADL_SDK/ before you build thank you badman, i am exploring an idea, i see somehow intel openCL drivers got installed and when i doo sgminer -n it shows Inten Open CL 1.2 but on my other rig it correctly lists AMD OpenCL ... so im blowing away the windows install and doing a fresh install and trying again... still weird why the older 4.x branch would still be able to identify my card but the 5.0 cant. v5_0 has a massive amount of changes from the original... also if you have onboard video on your MB it might be detecting it instead of your amd cards, this has been an issue in the past usually you can get by it by specifying "gpu-platform" : "1", in the config or --gpu-platform 1 in command line (platform 0 being the onboard video)
|
|
|
|
phzi
|
|
July 20, 2014, 03:24:45 AM |
|
I'm currently getting a virtual TON of "stale shares detected, discarding." Which variable(s) should I add or tweak to try and fix this problem? Is this normally an Intensity issue?
Thank you ahead of time!
try to dial back you intensity till your hashrate starts to drop sometimes if you set it too high you will get stale shares also can be caused by latency to the pool server if you are on a p2pool try to find one with the lowest latency Expiry has a significant effect on "stale shares". I say this in quotes, because the "stale shares detected, discarding" you were seeing are very likely not actual stale shares. To see if the shares were really stale, use "no-submit-stale" : false,
Increase your expiry (and potentially scan-time if you have it set low too) first. Only decrease intensity if you're getting REAL stale shares. I'm willing to bet that opet has expiry set to 1 or something equally silly.
|
|
|
|
jgauthier
Newbie
Offline
Activity: 41
Merit: 0
|
|
July 20, 2014, 01:09:07 PM |
|
Just started using this with my 5x7950 rig. It seems whenever the pool is set to X13, one of my GPU goes sick. X11 seemed stable for a while. I've been running this rig in scrypt mode for months. I have a GPU go sick about once every 2 weeks. I simply reboot.
However, mining X13 it's going dead in a couple minutes.
Any suggestions? I've tried lowering the GPU clock for it, but that didn't make any difference.
|
|
|
|
platinum4
|
|
July 20, 2014, 01:18:54 PM |
|
Just started using this with my 5x7950 rig. It seems whenever the pool is set to X13, one of my GPU goes sick. X11 seemed stable for a while. I've been running this rig in scrypt mode for months. I have a GPU go sick about once every 2 weeks. I simply reboot. However, mining X13 it's going dead in a couple minutes. Any suggestions? I've tried lowering the GPU clock for it, but that didn't make any difference.
Nope, allow me to introduce you to hamsi, it's an unforgiving bitch.
|
|
|
|
rldep
Newbie
Offline
Activity: 9
Merit: 0
|
|
July 20, 2014, 07:06:51 PM |
|
Here's how to nick up to 18M on nist5
Take your shaders and multiply by 5
For me was 2816x5 = 14080, this is your base thread concurrency if you specify an algo that doesn't exist, and it builds ckolivas with that TC
Next multiply this value by the total number of threads you are passing through your entire rig.
For me was 3 cards X 2 gpu-threads = 6 x 14080 = 84480 = xI: 30 as opposed to I:16=65536
Hi, platinum4! My level of knowledge does not allow to understand this magic completely :-) If I have a different cards in the rig (7950 + 7850 + 7850), how can I to calculate intencity/rawintencity? Total number of threads will be 1792*5 + 1024*5 + 1024*5 = 8960 + 5120 + 5120 = 19200. How it should be distributed to cards? And a second question: is the method above suitable for nist5 only, or for x11/x13/x15 too?
|
|
|
|
Vampiro4L
|
|
July 20, 2014, 10:08:32 PM |
|
anyone got a full 280x config to share?
|
|
|
|
platinum4
|
|
July 21, 2014, 03:04:18 AM |
|
Here's how to nick up to 18M on nist5
Take your shaders and multiply by 5
For me was 2816x5 = 14080, this is your base thread concurrency if you specify an algo that doesn't exist, and it builds ckolivas with that TC
Next multiply this value by the total number of threads you are passing through your entire rig.
For me was 3 cards X 2 gpu-threads = 6 x 14080 = 84480 = xI: 30 as opposed to I:16=65536
Hi, platinum4! My level of knowledge does not allow to understand this magic completely :-) If I have a different cards in the rig (7950 + 7850 + 7850), how can I to calculate intencity/rawintencity? Total number of threads will be 1792*5 + 1024*5 + 1024*5 = 8960 + 5120 + 5120 = 19200. How it should be distributed to cards? And a second question: is the method above suitable for nist5 only, or for x11/x13/x15 too? idk, did you just try rawintensity: 84480 and see if it increased your results?
|
|
|
|
kingscrown
|
|
July 21, 2014, 03:33:32 AM |
|
is this the best x11 and x13 miner right now?
|
|
|
|
rldep
Newbie
Offline
Activity: 9
Merit: 0
|
|
July 21, 2014, 04:54:39 AM |
|
Hi, platinum4!
My level of knowledge does not allow to understand this magic completely :-)
If I have a different cards in the rig (7950 + 7850 + 7850), how can I to calculate intencity/rawintencity?
Total number of threads will be 1792*5 + 1024*5 + 1024*5 = 8960 + 5120 + 5120 = 19200. How it should be distributed to cards?
And a second question: is the method above suitable for nist5 only, or for x11/x13/x15 too?
idk, did you just try rawintensity: 84480 and see if it increased your results? Yes. It is no significant rate changes from "intensity" : "17,20,20"...
|
|
|
|
KiloWatts
Member
Offline
Activity: 119
Merit: 10
|
|
July 21, 2014, 05:10:13 AM |
|
Wow. Confirmed, this works. A little shaky on x15 though...
|
|
|
|
KiloWatts
Member
Offline
Activity: 119
Merit: 10
|
|
July 21, 2014, 06:54:39 AM |
|
Wow. Confirmed, this works. A little shaky on x15 though... I'm behind... is this unnecessary now that we have 14.7
|
|
|
|
phzi
|
|
July 21, 2014, 08:52:47 AM |
|
Wow. Confirmed, this works. A little shaky on x15 though... I'm behind... is this unnecessary now that we have 14.7 You should get the same performance by fully installing 14.6 Beta (on Linux) or 14.7 RC (on Windows). The multi-driver setups, as far as I have seen, are only beneficial if you're still trying to scrypt mine (because scrypt performance is horrid on 14.x), but nobody with GPUs is scrypt mining anymore.
|
|
|
|
KiloWatts
Member
Offline
Activity: 119
Merit: 10
|
|
July 21, 2014, 01:48:59 PM |
|
Cool... slowly testing.
Able to get 5.4MH stable with RI:225280 and 1025/1250, as well as the Luffa_Parallel trick. Will nudge it up from here and see if I can get the fabled 6MH.
|
|
|
|
|