Hello Lost my writings about my rx580 rig and forgot the config values can someone plz paste me a config for monero v4? Cards are nitro+ SE 8gb Thanks  Start with intensity 70 and go up until you can {
"cryptonight_type" : "cryptonight_r",
"intensity" : 70,
"worksize" : 16,
"double_threads" : true,
"off_temperature" : 80
} |
|
|
|
Dual mining is awesome thanks!
Question - I assume that power consumption will be higher than usual?
No its not that kind of dual mining, this is something the pool supports. So with the same hashrate, same everything you can mine two coins (loki+turtle). This is called merged mining, and it exists for quite some time. Ok cool. So let me ask this. Does algo "Cryptonight Turtle" use more power than "Cryptonight BitTubeV2"? My 4 x Vega 56 rig pulls 750w when mining Cryptonight BitTubeV2 but when merge mining Loki/Turtle it pulls 850w. Right, CN Turtle is more power hungry |
|
|
|
Dual mining is awesome thanks!
Question - I assume that power consumption will be higher than usual?
No its not that kind of dual mining, this is something the pool supports. So with the same hashrate, same everything you can mine two coins (loki+turtle). This is called merged mining, and it exists for quite some time. |
|
|
|
How to dual mine Loki and Turtle coins
What is it? Is it legit? I know coin developers was trying to avoid merge mining in the past ... It is, it's working. You mine 2 coins at the same time with the same hashrate |
|
|
|
Can 1.8.2 handle more than 4 cards on a single rig? Windows 10. Have issues when i connect a 5th and 6th card. With 4 it does fine. Seems it can find the device/bus . Only finds 2 cards, shows the rest in red and not hashing, eventually DEAD, after i connect 5th card. Ok, didn't know if its another issue. I am aware that with W10 and cards more than 4 there is other things to consider. only having this problems with SBR 1.8.2
People use it with 10+ cards so yes, it can handle more than 4 |
|
|
|
Hello doktor83
I found a minor bug with setting intensity on the turtle algo. Auto settings are very good (thanks to you), and I get well over 8k hashrate with my rx480 8gb cards auto set at 104 intensity. But I do want to tweak intensity a bit for each of my cards to get the last bit of hashrate and long-running stability. However when I manually set intensity, even to the same 104 value picked by auto, hashrate drops to below 6k. Here are my settings:
--ccryptonighttype turtle --cpool pool --cwallet wallet --cpassword workername --logfile srbmineTRTL.log --ckeepalive true --cnicehash false --showstales --gpureorder --cgpuid 0,1,2,3,4 --cgputhreads 2,2,2,2,2 --cgpuintensity 0,0,0,0,0 --minrigspeed 41000
When I change only intensity setting to --cgpuintensity 0,104,0,0,0 then that one card set manually has large hashrate drop. I've tried all 5 of my cards with same results. I discovered this on v1.8.1, and it still happens with latest v.1.8.2. Didn't try it on previous versions.
I also mine haven algo, and manual intensity setting is working fine there and I can get max hashrate/stability dialed in. Thanks for taking a look at this when you get a chance.
yep a bug, i can reproduce on 480 cards. On vegas its ok. Going to fix edit:looking at it, it's not a bug afterall. Auto sets you everything : intensity, threads, worksize, fragments. On manual you should set everything. You did not set worksize, and it is using a default worksize of 16 which is not good for 480 cards. Insert --cgpuworksize 8,8,8,8,8 and you should get the same results as on auto. |
|
|
|
I prefer using SRBminer over the one I;m using now because SRB gives me higher hashrate. But what I don't understand is why my IP address is banned in hashvault if I use SRB. Yet if I switch to another mining software, it is not banned.
I don't understand this either. Which algo and how long it takes until it gets you banned? Maybe you have a long log for me ? |
|
|
|
Hey doc, it's only nicehash and nanopool that are so Hard on rejects, the miner still will send the stales right?? Cause major pools like supportxmr still use the shares for last job unless a new block is found.
This does give better hashrate for the miner. I know most people say fake hashrate, but those who understand it appreciate it 😃😃
Only Nanopool had the 'stale protection', of course they were sent already |
|
|
|
V1.8.2- Upx and litev7 algos on auto settings now have more hashrate or lower power consumption, or both- Reworked networking code, so probably get rid of a bug or two - Another try to fix V4 algo crashing - Maxnosharesent parameter default value is now 45 minutes - Fixed MarketCash , it was broken in 1.8.1 + Got some speedup on litev7 and upx algos if you use auto setup, mainly on Vegas and weak Rx550 - 560 cards, also power consumption dropped. + Another try to fix/postpone the crash that is happening on V4 algos. I would suggest to create/compile the kernel on 18.6.1 driver, then move to Adrenaline 2019 driver (19.3.2 for example). Some users reported none/less crashes on newer drivers. + Fully rewrote the networking code so now : - You will get 'Block expired' errors from some pools - Lot's of rejects on Webchain algo To explain : Some pools like Nicehash or Nanopool, do not accept stale shares (shares sent after a new job was dispatched). In earlier versions of SRB miner did not send these shares to the pool when it detected that a new job arrived in the mean time. Now these are sent too. I made this decision because i saw some discussions where people say that SRB displays higher hashrates than they really are, or steals hashrate ( ). This way user can see all shares - accepted and rejected, and can have a clearer picture of his real speed. Webchain is a similar story, it rejects stale shares. And oh, there are a lot of those, because it has a short blocktime so new jobs just bam bam bam keep coming. That's why you have 30% lower hashrate poolside than in miner. Yes i know Loud miner does not have this 'problem' so please use it instead if you have better results.
|
|
|
|
In the top post, it is suggested to use Driver 19.3.2 for Cryptonight V4. I'm running a Vega 56 on 1.8.1, but since I updated my drivers from 18.6.1 to 19.3.2, I get low difficulty shares that get rejected by the pool every now and then. Any suggestions on how to solve this? And is anyone else running 56s in a similar manner? Is CC 1400/950, MC 950/900 optimal? Thanks in advance!
The 19.3.2 are recommended if you have miner crashes, but if everything works OK for you on 18.6.1 then stay with it. |
|
|
|
When will the new version w/ the fixes for MKT be released? You should have mentioned this in the current release, I would not have released an update of my software with your newest mining software. Please push out the fix soon.
I plan on releasing the new version today, i couldn't mention that MKT isn't working because i did not know until i saw your screenshot |
|
|
|
Hi....I have 8 rigs, this is the only one that will not run the newest version. Any suggestions? Here's the log:  for marketcash use an earlier version, this bug will be fixed in the next version |
|
|
|
SRBMiner Cryptonight AMD GPU Miner All - rx 570 4gb problem
All drivers, except
Win10-64Bit-Crimson-ReLive-Beta-Blockchain-Workloads-Aug23
hash rate is 2 times lower than it should be
eg:
haven 750/780 --- 340/350
How to solve a problem?
Thank.
Why are you using a soon 2 year old driver? Maybe that's the issue, don't know. But try atleast 1.8.6.1 or any newer and enable compute mode. Oddly enough, but all video cards with 4GB of Win10-64Bit-Crimson-ReLive-Beta-Blockchain-Workloads-Aug23 show a higher hash rate! Thanks for the answer. Well if you don't have problems with the blockchain driver + you have better hashrate, why don't you stay on it ? |
|
|
|
SRBMiner Cryptonight AMD GPU Miner All - rx 570 4gb problem
All drivers, except
Win10-64Bit-Crimson-ReLive-Beta-Blockchain-Workloads-Aug23
hash rate is 2 times lower than it should be
eg:
haven 750/780 --- 340/350
How to solve a problem?
Thank.
Compute mode. Enable compute mode. https://www.srbminer.com/start.html |
|
|
|
Why am I getting a lot of rejected shares? "Pool rejected result 0x000074E1 for job[2] [low difficulty share]" By a lot I mean some, most shares are ofcourse accepted but still, quite frequent.
Pool difficulty is set at 120000 by default. May I change it for better results?
The pool I'm using is nanopool.org btw.
You get low diff shares when your gpu returns a bad result. So loosen on your OC , or depending of your card, maybe you use 'bad' mem. straps. |
|
|
|
i have just download the latest version. It works well but there is a problem if i set gpus manually. No problem on all 3 gpu {
"cryptonight_type" : "stellitev8",
"intensity" : 0,
"double_threads" : true
}
mining not started and bat file close immediately. {
"cryptonight_type" : "stellitev8",
"intensity" : 0,
"double_threads" : true
"gpu_conf" :
[
{ "id" : 0, "intensity" : 0 , "worksize" : 16, "threads" : 2},
{ "id" : 1, "intensity" : 0 , "worksize" : 16, "threads" : 2},
{ "id" : 2, "intensity" : 0 , "worksize" : 16, "threads" : 2}
]
} Is there any chances to set gpus manually ? yes, put a comma after the double thread true line |
|
|
|
No, im not interested. Someone else will probably do it. |
|
|
|
I have SRB MINER CN 1.181 running perfectly on windows 7 pushing 2 AMD 7790's Can not get it to run correctly on Windows 10 pushing 1 R9 270x. It starts and receives work from pool, but does not find any shares. Nor does it display any GPU readings "temp, fan speed etc.. shows all zeros there. It does show hashing speed of 470, and it identify's the card when I first launch it and again it receives work from pool. I have tried the recommended driver 18.5.1 and even tried different compatibility settings. Still no luck getting a share. I have a feeling its a W10 issue? as it runs fine on W7 with older cards. Any ideas? still testing other cards on different OS Thanks  When you try out different drivers every time clear the cache directory. R9 270x cards work fine on W10 and 18.6.1 drivers. |
|
|
|
It looks like newer drivers (adrenaline 2019) slow down the crashing issue that occurs because the memory or page file grows too much. Anyone else can confirm this? Testing now 19.3.2 and ONT 0.2.8, the timing level whatever i put isn't changing the hashrate for me on Vega56. Is it just me or .. ? First tests show that hashrate is worse than on 18.6.1 - tested on bittube and v4. If you use the compiled kernels from 18.6.1 on 19.3.2 then the hashrate will be also good. I think it has long been necessary to update your miner for optimal work with newest drivers. 18.6.1 is too old already. Newer is not always better, as still the best hashrate can be achieved on 18.6.1 ... old or not |
|
|
|
|
Show Posts
