 Show Posts
|
|
Pages: « 1 2 3 [4] 5 »
|
Hi, a new version is available: Cast XMR Version 0.8 (2017/12/14) - kernel optimizations result in subtle performance improvements - --fastjobswitch option (experimental) to force fast switching to new jobs. When enabled the GPUs will switch to the new job within less then 100ms. This improves the effective hash rate by 1 to 5% as nearly no GPU performance will be wasted on calculating outdated shares anymore. The drawback is a slightly lower displayed hashrate as while switching no hashes are calculated. - improved support for more then 8 GPUs - support for Radeon RX 470/RX 570 (Polaris) added - --forcecompute option to force kernel for compute mode on Polaris (RX470/570/480/580) GPUs. In the Radeon Settings GPU Workload has to be switched to 'Compute'. This option is available in Crimson 17.10.2 (or later) driver and reaches nearly the same performance on Polaris based GPUs as with the Blockchain driver. - openCL platform is auto detected if --opencl is not specified - --nonicehash option to disable nicehash support - nicehash support will automatically disabled if more then 8 GPUs are used. Otherwise search space could be exhausted to early and the GPUs search in overlapping nonce ranges. Download Cast XMR 0.8 for Windows (64bit)Happy mining! |
|
|
|
Hi, a new cast XMR version is available: Cast XMR Version 0.7 (2017/11/29) - network and job status added to current statistics - remote access to get current status at http://127.0.0.1:7777 in JSON format (enable with --remoteaccess) - command line option to specify number of reconnects to pool (default 100) before giving up (set with --reconnects n) - fix for nicehash to support upto 8 GPUs (before only 4 were possible) Download Cast XMR 0.7 for Windows (64bit)Happy mining! |
|
|
|
So I have tried several different pools and no matter what I do I end up getting roughly 5% rejected shares due to expired job.
2 KH - 5% = 1.9 KH
Sort of evens the mining software playing field if you look at it that way.
Has anyone solved the rejected shares problem yet?
Is there a fix in the works?
The problem is system immanent and the outdated shares correlate with the job time which should be 120 seconds for Monero. As the high hashrate is achieved by the high parallel processing of the hashes, the Vega computes 4000 Hashes at once, so for the outdate shares: To calculate 4000 hashes with 2000 Hashes per second it takes about 2 seconds for the flight to get the results. 2 seconds round trip time divided by 120 seconds average job time gives an maximum dead time of 1,7%. If the job time decreases the rate will increase but will also decrease when job time goes up. I see about 2% outdated shares after running 24 hours, which is perfect in line with the prediction. One idea is to faster cancel the current job if a new job is incoming could have the outdated percentage to less then 1%. Currently evaluating if it has an benefit... maybe in an upcoming version.... |
|
|
|
New update available: Cast XMR Version 0.6 (2017/10/27) - improved queue sync which results in an 0.1% higher average hash rate - experimental support for Radeon RX 480 / RX 580 GPUs added - pessing 's' key prints the current statistics - count outdated and invalid shares separate - fixed random crash when quitting app - bugfix: invalid command line arguments did hang app Download Cast XMR 0.6 for Windows (64bit)Happy mining! |
|
|
|
Ok thanks.
Must i test all freq for RAM ?
I set at 1030 yesterday by misstake, and i stay at 1730, instead 1830 with 1025Mh for RAM.....
1020/1025 for mem clock seems to be a sweet spot, probably some resonating effect of memory and cpu clock. The range between 1025 - 1050 seems not to be very effective. Memory clocks at 1050 and above are more faster then 1025, but depends on the the card if it can handle it. |
|
|
|
i use nanopool - Share difficulty is static and equal to 120000. its small diff?  ? Should be ok. |
|
|
|
The driver only has the compute option for RX 4XX/5XX GPUs not the Vega series. Hope they put in the next version. OK. So stay with Beta ? If you want to mine with your Vega with higher hash rates then 1200, yes. |
|
|
|
Yes
i have same problem with Rejected shares
my is 5% to 10%
Please fixed
As written earlier in the thread. The rejected shares occur mainly with a low difficulty. A round-trip on the GPU takes 1-2 seconds. If in the time the job has changed the calculated solution is submitted but then rejected by the pool because they are outdated. Next version will distinguish between outdated nonces and technical invalid nonces (probably 0). Best solution is to mine on a pool with higher difficulty to only go for the big ones. |
|
|
|
The driver only has the compute option for RX 4XX/5XX GPUs not the Vega series. Hope they put in the next version. |
|
|
|
Vega56 1408/1148 is doing only 1970h/s.
The main drawback here that I need to use lower intensity than with Vega64.
Vega56 is not stable with 2016/1800 setup I use with Vega64
Well that is the inefficient structure of stark. The vega56 can easily do 2000 hashes/s out of the box with 960 mem clock, PL 0 no heavy modding or bios tinkering needed. Just use cast-xmr  |
|
|
|
[13:27:47] Shares: 681 Accepted, 19 Rejected | Total Hash Rate: 3959.2 H/s | Avg Search Time: 255.2 sec
Still finding that I am getting lots of Rejected shares.
It seems to be the same problems as was described earlier in the thread where the shares are expired and still completed and submitted anyway.
Try lowering your memclock. That is a high rejection rate and I had the same issue when I ran my memclock too high. Doing 920 for memclock now and seeing about 1.5% rejected. [16:04:39] Shares: 759 Accepted, 11 Rejected | Total Hash Rate: 5710.5 H/s | Avg Search Time: 35.2 sec
All there cards doing around 1900h/s. The hashes are checked by CPU before sending to pool, as long as you don't see no "GPU error - nonce incorrect" after "Found Nonce" the GPU is working fine. When writing "submitting..." it is technical valid and sent to pool, but the pool is already working on a new job... |
|
|
|
hmm..always gets lower hash on specific GPU (raiser seems ok, and i have toggle and apply the HBCC Memory Segment ) OS : win 10 pro Driver [Suspicious link removed]pute Driver Version 17.30.1029-170808a2-317304E-CrimsonReLive GPU : 6 x MSI vega56 Overclock : -4%,945,-10%  One has to toggle the HBCC Mememory Segment setting for each GPU (really annoying), those giving below 1800 Hash/s (GPU1, GPU3, GPU5) seems not have been toggled. |
|
|
|
Hashrate drops every few seconds on diffrent gpus.
Sometimes GPU0 1950 - drops for 1 sec to 1600 then back to 1950 and that goes on and on on diffrent gpus.
The drops are happening because on some GPU the compute queues have to be resynced to keep optimal throughput. It should not happen more then once every 60 seconds, and only effects 1 frame. The overall loss is probably less then 5 Hashes/s. But still looking to optimize it away. Happy mining, glph3k |
|
|
|
There is an update available: Cast XMR Version 0.5 (2017/10/19) - support for multiple Vega GPUs. Specify multiple GPUs comma separated with the -G switch like "-G 0,1,2,3" - monitor temperature and fan speed for each GPU - subtle performance improvements in core Download Cast XMR 0.5 for Windows (64bit)Now hash with full 4 KHashes/s with 2 GPUs:  |
|
|
|
Can you post all commands cast_xmr --help wont work. My first gpu is intel so I cant get miner working. Error GPU0: Intel(R) HD Graphics 610 | 12 Compute Units, how i turn it off? Btw 6xRX Vega 64 Limited.
I found fix --opencl 1 -G 1 but how writ it to start mining for all 6 cards?
Currently only one instance per card possible, but you can start multiple instance, each for a different card. Working on a multi GPU version |
|
|
|
I'm experiencing high rejected shares with your miner, currently on 12 rejected shares with 167 accepted, is that common or maybe you have any insight?
My setting is a low noise one with -40% Powlim, -100 mV through recent afterburner update, and 800Mhz Mcloclk with 1584 H/s avg and 1700 peak,
Are the rejected shortly (1-2 seconds) after a new job was received? Something like this:
[08:11:00] New job received. Avg Job Time: 15.7 sec
[08:11:00] Difficulty changed. Now: 40000.
[08:11:01] Found Nonce, submitting...
[08:11:01] !Rejected, Nonce Invalid!
Then the reason is that there is already a new job and the calculated nonce are from the previous job. A roundtrip takes 1-2 seconds in the GPU, an improvement would be to faster cancel the current job and throw the old results away. Currently it tries to submit them. Will try to fix in the next update. |
|
|
|
What are the settings of the vega in your screenshot?
The screenshot shows a Sapphire Vega 56 with following settings: Core clock: -5% MemClock: 990 Mhz PowerLimit: +24 Fan Min Speed: 3000 RPM The voltage control is still on auto. The GPU consumes 260 watts. |
|
|
|
Good job, better performance than Dagger, profit is better with one Vega 64.
I got 1877H/s with the followed setting with my MSI Vega 64.
Core Frequency: -10.5%
Memory Clock: 1025 MHz
Power Limit: -23%
Don't know if i must adjust this, or just close all, or anything else.
Sometime i got 1900, but never 2000. The power consumption is not my first priority, just get the best hashrate.
About consumption, i check without miner, 285W (for the total of PC) during mining, 460W. So 175W at full ??
Ok, maybe the Vega gets to hot, it has the habit to throttle down if it gets close to 70°. So to stay above 1900 you can increase the fan speed. Flick the "Speed (RPM)" toggle an enter a value for min fan speed like 1200 and apply, the temperature should drop. If you want to go for the 2000 and more you have to go all in. Turn up the min fan speed to "3000" RPM. Crank up memory clock to 1100 and increase power limit in steps, core frequency can stay. It gets really loud but you should reach 2000 hash/s and it will eat up another 50-100 watts. My suggestion of the above values are in my opinion the most efficient ones, but if you don't care about the power usage it is worth a try. Also one can edit the Voltage Control down, there are some threads where the experts are debating what the best settings are to bring the wattage down again... but please do on your own risk |
|
|
|
so this is working only with 1 gpu?
1 GPU per instance, yes. But you can run as many instances as you like. So start a new terminal and run "cast_xmr -S [server] -u [wallet address] -G 1" to start a second instance mining on your second GPU and so on for 3rd GPU.... |
|
|
|
 "-G x" dont working -G select the GPU with "--opencl x" one selects the openCL plattform, default x=0 which in your case seems to be the Intel OpenCL driver. Please try: "--opencl 1 -G 0" |
|
|
|
|
