 Show Posts
|
|
Pages: [1]
|
Your file name is wrong, it's called "cpu" instead of "gpu".
If you have some errors in HWInfo64 so your overclocking goes too far, maybe the warmup of 0.31f did not trigger the error but that's still a too strong overclocking. Maybe retry from stock frequency then rise back by steps. I'm not arguing that overclocking is great for these cards, I simply state the fact that on the sapphire rx550 11268-16-20G the latest version is not the best option. I ran the test on this version of the miner, the launch is possible only with a memory frequency of 1820 MHz, but this is already 488 h / s from the card, which is a total minus 100 h / s from the rig. But it's still better than competitors because they give out less actual speed on the pool. All of the above is not a reproach, but for the information of possible owners of similar cards. I like your miner for stability without rebooting for weeks. Thank you. |
|
|
|
Unfortunately for sapphire rx552 cards with memory elpida of 6000 MHz running at the limit does not fit the version  During the warmup the cards start to give out memory errors in HWInfo and after a while the blue screen, reducing the frequency to 1800 MHz does not help, apparently it is necessary to look for other timings for now I remain on version 031f. |
|
|
|
I plan to put a Claymore-like watchdog: in case a GPU falls under a certain hashrate (default: 0) the miner quits. Then it's up to you to have a script (.bat or .sh) whose next line is a reboot command.
it seems to me that this does not always help those who do not have a hardware watchdog. I have one or two cards falling and when I close the miner it just hangs for a long time (20 minutes the system may hang in this state), so the next line will not be executed for a long time and the reboot will not happen. It may be better to call a pre-defined script, even if it's empty, but there everyone will write what he needs in it. |
|
|
|
|
good afternoon.
On the first versions when I first started using this miner, I could install on the cards Sapphire RX552 "multi_hash": 464 and the cards were given out at 520 h/s, but now I can not install more "multi_hash": 432 everything above the card is not keep the memory frequency and reset again and as a result the speed is from 0 to 60 h/s. The system did not change anything, tried to reduce the frequency to indecent 1800 MHz, the result was not given. Tell me what it can depend on, because it's on the forum guys use 464 on similar cards and I like everything hangs on the line
{ "mode" : "GPU", "worksize" : 8, "alpha" : 128, "beta" : 16, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta" : 4, "index" : ..., "multi_hash":432 },
{ "mode" : "GPU", "worksize" : 8, "alpha" : 128, "beta" : 16, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta" : 4, "index" : ..., "multi_hash":432 },
|
|
|
|
I already took a look and gave up. it's not just a fork of cn-v7, they completely changed the network protocol too. the changes are far more important than for Nicehash.
it would be too complicated to handle both, and even themselves just made a webchain-only miner from xmrig but not one that handle all CN variations. i cannot afford time to handle two separate netcodes.
any feedback about cn-heavy hashrates of 0.32f ?
I tried on bittube it slightly increase hashrate about 5-10 h/s per card and no rejected shared which is good. Edit : the things need to take note is like Sx5000 said on some card it really difficult to reach peak hashrate, I need to fire GPU-Z over and over. Same as me about hard to reach the hashrate peak, should run gpu-z more than once. Very small increase on hashrate, it is about up to 5 h/s only on mine. Currently back to 0.32a. in the same way, RX552 start badly, from 13 cards 2-3 cards can either generally 0 h/s or 470 h/s and does not rise. back to 0.32a. |
|
|
|
Hello, Are they 2Gb cards ? It sounds that's some RX550 or 560 with those speed. With 2Gb i've a stable hashrate with multi-hash (intensity) of 432, and 448 or 464 when no screen is plugged. You've a rig of 13 cards, that's big under windows, maybe you reach some drivers limits somewhere. JCE is a pure OpenCL miner, i let OpenCL and the drivers allocate resources, so if your driver makes your hashrate drop, JCE tries nothing to prevent it. Safety first. I'm building 0.31f right now, with: Linked against official AMD SDK 3.0
Invalid shares detected by CPU now logs the Thread and Lane (good for memory diagnostic)
Still new OpenCL code, it's good on all my cards (HD7000, RX550, 560) but blind-experimental on RX570, 580 and vega. Reads: perfs may be worse than 0.31c
edit: 0.31f onlineYes it is RX552. The same situation is evident in other miners of the latest versions, but only on lexa cards. I'll try the new version. Thank you. Your miner I really like, good speed on the pool and the main stability without falling into the blue screen |
|
|
|
|
Good evening. Can anyone come across a situation, there is a rig for 13 cards. 10 cards on the buffin work stably at 500 h/s, and 3 cards on the Lexa give out 515 h/s but regularly drop to 440 h/s and run at this speed from 2 minutes to 15 minutes, then the speed is again restored to 515 h/s. After a while everything repeats itself. The intensity reduced, alpha and beta, too, the same result.
now everything works with such settings:
{ "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta" : 4, "index" : 3, "multi_hash":432 },
{ "mode" : "GPU", "worksize" : 8, "alpha" : 64, "beta" : 8, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta" : 4, "index" : 3, "multi_hash":432 },
I tried with these, the same result
{ "mode" : "GPU", "worksize" : 8, "alpha" : 128, "beta" : 16, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta" : 4, "index" : 3, "multi_hash":432 },
{ "mode" : "GPU", "worksize" : 8, "alpha" : 128, "beta" : 16, "gamma" : 4, "delta" : 4, "epsilon" : 4, "zeta" : 4, "index" : 3, "multi_hash":432 },
Drivers 18.5.1
the frequency does not decrease in these moments
|
|
|
|
|
Miner is beautiful for RX550, but you need a wachdog. Sometimes one or two cards fall and until you see the rig itself is not working at full capacity.
|
|
|
|
|
Hi guys. Has anyone tried Masari on RX550 / 2 GB. I can not adjust parameters either as stable. on the buffin, the cards give out a maximum of 950 h/s for a short time and then the system drops, and 4 cards on the Lexa give out only 800 h/s and then the system drops.
|
|
|
|
|
Good afternoon, doctor. I have a 13-card rig.
1) 9 cards of Sapphire RX550 / 2Gb on baffin
2) 1 card of Sapphire RX550 / 2 Gb on gfх804
3) 3 cards of MSI AERO RX550 / 2 GB on gfx804
On version 1.6.0, all cards worked with parameters 26.3 / 12 and issued:
1) at 497 h/s
2) 498 h/s
3) at 513 h/s
to my great regret at the transition to 1.6.1, and now on 1.6.2 with the same parameters of the cards began to give different results. In particular
The cards from point (1) remained at the same values, and from point (2) and (3) began to jump from 410 to 480 h/s. By reducing the parameters to 22.1/12 I was able to achieve a stable speed on the MSI cards from (3) of 499 h/s, but could not achieve an acceptable speed on the card from point (2). I went through all the intensity options from 18 to 28 in steps of 0.1 the maximum stable result was reached at 22.1 / 12 at 475 h/s.
|
|
|
|
1.5.8 shouldnt be faster than 1.5.9, cause nothing was changed that could impact speed. Placebo  unbelievable but true. my RX 550 2gb at 1.5.8 gave out stably 6590 hashes at setting 26/8/2, and on 1.5.9 neither as more than 6510 hashes what happens on 27/8/2? in this case, everything is not stable, or the cards do not start all at once, but only after a couple of reboots and after that in a couple of hours all the same 0 the hashes are shown and the reboot is going on. But on the other hand, the speed on version 1.5.8 strongly diverged by the indications on the pool, and 1.5.9 shows approximately equal values with the pool. So we stay on 1.5.9  I think 6500 with 13 RX 550 cards is a good result, the main thing is that there would be stability. Thank you for the miner. |
|
|
|
1.5.8 shouldnt be faster than 1.5.9, cause nothing was changed that could impact speed. Placebo unbelievable but true. my RX 550 2gb at 1.5.8 gave out stably 6590 hashes at setting 26/8/2, and on 1.5.9 neither as more than 6510 hashes |
|
|
|
V1.5.3
+ In previous version when using --gpureorder, and then setting up gpu's in gpu_conf, the GPU ID's did not match up with --listdevicesreordered order. This should now be fixed.
this works fine, but the error does not output for those cards, the work does not interfere, so it's easy for information [2018-05-13 08:51:08] hashrate: GPU0: 288.0 H/S
[2018-05-13 08:51:08] hashrate: GPU1: 285.0 H/S
[2018-05-13 08:51:08] hashrate: GPU2: 300.0 H/S
[2018-05-13 08:51:08] hashrate: GPU3: 0.0 H/S
[2018-05-13 08:51:08] hashrate: GPU4: 293.0 H/S
[2018-05-13 08:51:08] hashrate: GPU5: 306.0 H/S
[2018-05-13 08:51:08] hashrate: GPU6: 280.0 H/S
[2018-05-13 08:51:08] hashrate: GPU7: 273.0 H/S
[2018-05-13 08:51:08] hashrate: GPU8: 322.0 H/S
[2018-05-13 08:51:08] hashrate: GPU9: 309.0 H/S
[2018-05-13 08:51:08] hashrate: GPU10: 326.0 H/S
[2018-05-13 08:51:08] hashrate: GPU11: 336.0 H/S
[2018-05-13 08:51:08] hashrate: GPU12: 335.0 H/S
[2018-05-13 08:51:08] hashrate: Total: 3688.0 H/S
[2018-05-13 08:51:08] watchdog: GPU8 [thread16] hashing speed is 0 |
|
|
|
V1.5.2
- Added support for ADL Overdrive5, in gpu_conf add 'adl_type' = 1 for OverdriveNext , 2 for Overdrive5, if not set default is 1 (OverdriveNext)
- Parameter 'restart_devices_on_startup' now only restarts Vega GPU'S, cause others don't need restarting to get max performance
- Disable/enable GPU while mining now happens almost instantly
- Added '--gpureorder' parameter (use in bat) to order devices by BUSID like GPU-Z does
- Added '--listdevicesreordered' that lists devices in BUSID order, for usage with '--gpureorder' parameter
+ If your GPU temperature or fan speed isn't displayed when pressing 'h' , try adding 'adl_type' : 2 in gpu_conf :
"gpu_conf" :
[
{ "id" : 0, "intensity" : 0, "worksize" : 8, "threads" : 2, "adl_type" : 2}
]
Also you can try type 2 if 'target_fan_speed' isn't working for you with the default OverdriveN.
Basically :
Type 1 : Use OverdriveN (mostly for newer cards)
Type 2 : Use Overdrive5 (mostly for older cards)
+ If you want to order your GPU's like in GPU-Z or OverdriveNTool, put parameter --gpureorder in .bat like :
FOR /F %%x IN ('tasklist /NH /FI "IMAGENAME eq %EXE%"') DO IF %%x == %EXE% goto RUNNING
%EXE% --config config.txt --pools pools.txt --gpureorder
TIMEOUT /T 15 /NOBREAK
When setting up 'gpu_conf' in config but want to use the BUSID ordering, first list devices with --listdevicesreordered parameter to get the reordered gpu id's :
SRBMiner-CN.exe --listdevicesreordered
+ The 'restart_devices_on_startup' parameter now looks only for Vega GPU'S, and disables/enables only those before mining.
--gpureorder and --listdevicesreordered does not work as expected. More precisely, the first parameter works, but I get the result with the command "SRBMiner-CN.exe --listdevicesreordered", I see that I need to set "worksize = 8" for BUSID 12 and 13, which corresponds to DeviceID [7] and DeviceID [8] When setting up ' gpu_conf for IDs 7 and 8, but as a result, the values for cards with BUSID 2 and 4 change ver 1.5.1   ver 1.5.2   |
|
|
|
|
