|
Is anyone uses old 270X cards? Wich settings best for V7 and heavy? What speed you're have?
|
|
|
|
I found interesting thing...
As we know 1.5.8 creats srb files every launch... But names of this files differes (they even have different file size) every time. I make suggestion that different speed at mining connected with these different kernels. To achive max mining speed I relaunched 1.5.8 miner many times until it gives me max speed.
1.5.9 version creates srb files only if them absent. But I tried many times relaunch miner with deletion of srb or on the same kernel file. But I can't get max speed... Maybe I just unlucky, or maybe 1.5.9 can't compile best kernel...
After I make next steps:
1. Roll back to 1.5.8. Relaunched them until it gives max speed. Copied last created srb file into backup safe place.
2. Installed 1.5.9. Launched them once to recieve srb file in cache dir.
3. Close miner. Replaced srb file in cache dir from 1.5.9 by srb file created on 1.5.8 giving max speed with the name from file 1.5.9.
4. Voila! Now 1.5.9 have quick launch without recreating srb file and gives max speed everey launch (I hope - I just tries several times).
This can help peoples who have troubles with unstable max speed.
doctor, can it be that 1.5.9 miner can't compile best kernel due to driver issuies or something else?
I have a theory of what could be the cause of this, great experiment by the way  On which card/cards is this happening? edit: damn, 1.5.9 is also doing it, so you were unlucky. I started/deleted cached files 5x times and the 6x time it really hashed a little bit faster. This will be interesting to find the cause of it. I suggested that 1.5.9 also doing that... But 1.5.8 automatically creates new without needs to delete existing )))) You must find why it's happening and how to create best kernel! Cards is RX 580 8Gb hynix memory. Another one problem - it's happens not too often but sometimes miner gives error - "Invalid nonce; is miner not compatible with NiceHash?". |
|
|
|
|
I found interesting thing...
As we know 1.5.8 creats srb files every launch... But names of this files differes (they even have different file size) every time. I make suggestion that different speed at mining connected with these different kernels. To achive max mining speed I relaunched 1.5.8 miner many times until it gives me max speed.
1.5.9 version creates srb files only if them absent. But I tried many times relaunch miner with deletion of srb or on the same kernel file. But I can't get max speed... Maybe I just unlucky, or maybe 1.5.9 can't compile best kernel...
After I make next steps:
1. Roll back to 1.5.8. Relaunched them until it gives max speed. Copied last created srb file into backup safe place.
2. Installed 1.5.9. Launched them once to recieve srb file in cache dir.
3. Close miner. Replaced srb file in cache dir from 1.5.9 by srb file created on 1.5.8 giving max speed with the name from file 1.5.9.
4. Voila! Now 1.5.9 have quick launch without recreating srb file and gives max speed everey launch (I hope - I just tries several times).
This can help peoples who have troubles with unstable max speed.
doctor, can it be that 1.5.9 miner can't compile best kernel due to driver issuies or something else?
|
|
|
|
Well, I tried opening GPUZ while the miner was running just now and I can confirm that I did get a boost of ~50-60 Mhz per GPU. That's with 6 x Rx 580 8GB, 5 Micron Memory, 1 Hynix Memory - all stock Bios - 1250 Core, 2150 Memory, 925 mv Core, 950 mv Memory 18.5.1 drivers.
GPU-Z what version? |
|
|
|
Omg, people!.. After all, try the SRBminer.
Supported cryptonight type normal, normalv7, lite, litev7, heavy, ipbc, artocash, alloy, marketcash, b2n, stellitev4.
For my Asus RX 560 2Gb for normalv7 with Claymore - 495 h/s, with SRBMiner 515 h/s.
On previous series of AMD cards 2xx and 3xx with 3Gb+ video memory Claymore 11.3 on V7 is faster than SRB miner. It's important. |
|
|
|
GUI version will updated?
Of course! I was spending time on development tools so that I could rewrite the Ethash kernel per your request.  These things take time, you know... Yes, I know. You just wrote about lite command-line version, that's why I asked. When you finish kernels and go to window, can you add possibility to add 2nd chart on main dashboard? On normal monitors it's too much free space in top of dashbord window. I think it'll good, if peoples with big monitors can enable checkbox to add 2nd statistic charts... |
|
|
|
I can beat stak and xmrig, they both use the same old code from Wolf0.
And claymore is a beast on CN-Classic on HD7000/2xx with 9.7
With 10+ i get high displayed hashrate on hd7000 but 10% bad shares, i can fix them by lowering intensity but then the hashrate itself drops by 10%.
On my dual Baffin i use the most for tests, i cannot get more than 915 on CN-v7 from Claymore, with a pool hashrate reported around 870. I made JCE run at 965 and stak at 940 with my current status. I didn't even started optim of CN-Heavy, it's a very different algo when implemented on GPU.
SRB, i'll do the tests you advised with my HD7870.
I also tested my Bonaire, which sends 240 on JCE, 265 on old Claymore 9.7 but is not even supported by Claymore 10+
That's consistent with the current 10% loss against Claymore 9.7
No dev today, my whole rig is dedicated to stability tests. Uptime 24h on all my GPU, no crash. I'll go back to dev after 48h of uptime, that will be enough to say it's stable. Testing during dev is very long, a bug in the OpenCL usually crash the GPU since the GPU memory is not virtualized like the one of a CPU. Sometimes the drivers can reset the gpu, but usually it just crashes.
On my 270X 4Gb Windows 10 x64 1803 AMD 18.5.2 Claymore 11.3 gives more speed than 9.7 because of -dmem 1 option in 11.3. But, i think on 2Gb cards 9.7 will be faster. |
|
|
|
doctor, check please releasing video memory on closing miner. I suspect that it doesn't releases them all...
describe the problem you have? I don't know is that bug from miner or from driver... I noticed that if I restart miner many times (one of methods to achieve max speed) my amount of RAM decreases in time... When it's start to grow my pagefile.sys file to 35Gb I decided to find - where is memory leak... No one process didn't use so many RAM (I have 12Gb RAM and 24Gb pagefile size). 1st i didn't find who eat my memory, and just restart computer to stop that. Than I start to remember - after what it start, and I remembered that it starts after I start to use SRB miner... After I run GPU-Z and didn't believe my eyes! GPU-Z shows on both of my RX 580 8Gb cards used video memory 14Gb on 1 card and 15Gb on 2nd! I don't know how it can be, but after closing miner, used vmemory on cards decreased to 7Gb and 7,5Gb. GPU chips usage is 0%, but vmemory is used! I start to run and close miner, and I notice that after each closing used vmemory on idle cards grows... During GGS and Claymore usage I didn't have this problem... |
|
|
|
|
doctor, check please releasing video memory on closing miner. I suspect that it doesn't releases them all...
|
|
|
|
detailled settings and comparative results, exactly what i needed, thanks
i also observed srb being 10% lower than claymore, on hd700 (270X is a rebrand) but my pool reports hashrate 10% lower than expected on claymore miners (while my proto jce sends exactly what it displays, as expected)
i've a hd7870 so i'll be able to do the same compare.
As I understand right, SRB is more for new cards... On old cards like 2xx and 3xx series Claymore is faster, but Claemore didn't support heavy algo... I didn't tried XMR-stak and XMRig GPU, but i don't think that they are faster than Claymore on v7 or SRB on heavy... |
|
|
|
|
We must rise topic. Maybe Claymore looks at amount of peoples needed miner update!
+100500
|
|
|
|
|
I have Pitcairn card. 270X with 4Gb vmem. Best speed on cnv7 is on Claymore 11.3 - it's about 500-510 h/s. Settings are -h 460 -dmem 1
On SRB cnv7 about 450-475 h/s with intensity 58-59, worksize 8, threads 2.
Heavy algo on SRB - about 400 h/s with intensity 26, worksize 8, threads 2.
|
|
|
|
Next version fixes .srb file creation on every miner run Thanks, waiting... Does any thoughts about why all my cards shows as 3rd card name except corenames? is this happening in cast and xmr stak also? everything working ok, except that gpu model is displayed incorrectly? Cast XMR use only core names. GGS detects cards with the same bug. XMR-stak didn't used. Everything works ok, exept gpu model is displayed incorrectly and srb files creates with that wrong name. it means we are all using the same opencl call to get gpu name, and that the driver returns it incorrectly. I am sure this will be fixed in newer driver versions. Allready 3 drivers (18.4.1, 18.5.1 and 18.5.2) with that bug. I'm losing hope to fix it by AMD... |
|
|
|
|
GUI version will updated?
|
|
|
|
Next version fixes .srb file creation on every miner run Thanks, waiting... Does any thoughts about why all my cards shows as 3rd card name except corenames? is this happening in cast and xmr stak also? everything working ok, except that gpu model is displayed incorrectly? Cast XMR use only core names. GGS detects cards with the same bug. XMR-stak didn't used. Everything works ok, exept gpu model is displayed incorrectly and srb files creates with that wrong name. |
|
|
|
Next version fixes .srb file creation on every miner run Thanks, waiting... Does any thoughts about why all my cards shows as 3rd card name except corenames? |
|
|
|
before u have 1 file : 687f. without extension and this is it. now you co,mpile every time when start .before you compile only 1 time for 1 algo.
That's because on earlier versions there was a bug preventing creation of cached files for VEGA gpu's, so they were compiled every time, but 1 empty file was created  Those numbers all have a meaning, like worksize, num of CU's etc etc, thats how the miner knows which kernel to use. Im just curious does it really every time , even if you did not change ANYTHING in config file like algo, or anything in gpu_conf, create a new file ? Every time. i not chg any. i go on loki back to hevy and go on new RYO. i try triton and go on saronite and back again to heavy, now i have 60 more file and 160mb lose space on disc. this is not good. version 1.5.1 work fine. -  and first compile is to long. and start again miner again i must wait so long for compile. 1.5.1 - first start wait long time. but second miner start in 2 sec. Miner ti jednostavno ne prepoznaje fileke koje sam proizvodi. i stalno iznova mora napravit compajliranje koje traje li traje. iritira. i mislim d ase vracam na staru verziju jer ja mjenjam koinove po dificultu a to je barem 20 puta dnevno i taj veci HR mi ne znaci tolko kolko mi znaci da miner krene odma a ne nakon minute. barem stavi da se fileki brisu kad izadjem iz minera da ne mora mjos i t orucno radit dok ne nadjes gdje je greska prepoznavanja...sto se veceg HR tice. Moram barem 3-4 put apokrenut minera da krene s tim vecim HR-om. znaci nista ne diram samo palim i gasim minera. i to stvara fileke... da li kartice podesavas kroz gpu_conf parametar? Ako da, da li bi mogao da probas da obrises sve .srb fajlove, i iskomentarises gpu_conf, stavi samo gore intensity 0, pa nek kreira tako fajl, i probaj pokreni majner ovako par puta, da li ce i ovako svaki put da kreira novi .srb ? znaci bez gpu_conf, tj. rucnog podesavanja. edit: i probably found the cause of cached files recreation, if someone could just test this for me: comment gpu_conf and just leave intensity 0 on top of config, so miner sets everything. Before this delete all .srb files. Miner should now create a new .srb file. Stop miner and start it again. If im not mistaken , it wont create a new .srb file, but instead use the cached version. Yes, you're right. Until gpu_conf commented, srb file didn't creates... Only 1st time. But if after that set gpu_conf again, srb files start to recreates again... |
|
|
|
There are hundreds of SRBMiner users without any problems, where the miner works flawlessly. Or they just didn't write about them... Many added deleting of .srb files into start.bat... Please, don't get mad on me... I just think that all next AMD drivers will be with the same features as 18.4.1, 18.5.1 and 18.5.2. What about duplicate shares? ok, you know everything, no need for me to write anymore You are always just demanding, and so negative. Don't be like that. I'll try to be less negative)))). But my demands are fair for the most part. |
|
|
|
Claymore, please add heavy algo support. You can return the fee and update miner!
+1 +1 Not sure the miner is actively supported anymore, remember that he removed the devfee. He can return fee back and update miner. +100500 |
|
|
|
|
Show Posts
