Topic: [Cast XMR] high speed XMR/CryptoNight miner for RX Vega GPUs (2 KHash/s) - page 86. (Read 206404 times)

Hi All,

I've been working on a simple GUI wrapper around the miner to monitor it in a more user-friendly way and to restart the miner automatically if the hashrate drops below a specified amount.  I'm sure there's lots of bugs (very little validation in the GUI), but it might be useful for some of you.

https://github.com/anadventureisu/cast-xmr-ui

https://i.imgur.com/wpSvkSL.png

my display is connected to the integrated  graphics of mobo .. so all vega64 are pure .. i read it 5 times .. i'm not a piece of shit .. i'm asking help

Are you using the GPU in question to display to a monitor, or teamviewer?  This can effect hashes greatly as it has to use GPU power to render everything.  Use onboard graphics or get a crappy GPU for display purposes only.  By the way if you bothered to sift through these pages of posts you would have found your answer quiet a few times.  Don't be a lazy piece of shit, we got enough of those around here.

Can somebody explain me pls ?

Just change the URL of the download link to a 070.

http://www.gandalph3000.com/download/cast_xmr-vega-win64_070.zip

lol there are much better, easier and faster ways to mine with other drivers, and no there are no plans to "fix" this miner as its not his fault the newest drivers don't enable compute mode for Vegas.

You are a pain in the ass!

Let me do some quick reading for you of completely and readily available information provided with minimal searching from this thread, you utter pillock!

Surprise! the miner has been updated!

Now pay close attention here to the bold fonts down below you completely illiterate and incapable troglodyte!

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.

As you can plainly see the miner has already been updated --forcecompute to use the new drivers. HOWEVER! Why you say does this not work for the VEGA mr CAST-XMR miner dude dev??

Well let me tell you! The Vega cards don't use the "COMPUTE" option. ***IMPORTANT*** - COMPUTE IS NOT AVAILABLE FOR THE VEGA! as per AMD. See the link here --> https://community.amd.com/message/2837889#comment-2837889  

Well you may now conclude that it is back to our lowly CAST-XMR Dev to just fix this problem right!?! Get rid of that pesky blockchain driver requirement! Given the remarks from AMD related to the Vega architecture being "already optimized" and therefore does not need the "Compute" option in the driver, this tells me they(AMD) think everything is super great.

Well just hold on there now little guy! With that little nugget of info one can quickly find that it has already been reported that using the latest AMD driver to mine XMR with a Vega (using another miner since that pesky blockchain check is there in CAST XMR) yields a much lower 1300h/s rate than the blockchain driver 2Kh/s.

So to sum this up for you, it looks like AMD needs to enable the "COMPUTE" option for the Vega in its latest driver now doesn't it! And further more CAST-XMR is ready to handle just such a change should it ever come our way! SHAZAAAAM!!!!

So if you are getting better performance/stability over the CAST-XMR/blockchain driver combo reports, that would be a different type of news now wouldn't it?? Cause my Vega's "behave" just fine in the current configuration. No changes needed sir!

You must be using some other miner to mine XMR or some other cryptonight algo based crypto currency to be getting a faster hash rate with the latest AMD driver. I think that would be interesting news for Vega owners now wouldn't it if you would share that?? Please indulge us won't you? What type of hash rate are you getting? What miner is it you use?

What other currency would you bother to mine with a Vega, which does its best work on cryptonight. ETH?? No I don't think so. Something new??



 

Does anyone know if there is any plans to update this miner past the Aug. Blockchain driver?

Vegas behave much better under the current driver vs the August driver.

DDUing the drivers to switch coins is a pain in the ass.

It's not really a problem with CAST-XMR now is it. That is you choosing to overdrive the card and then demand that that the tool fix it for you. Maybe you should spend more time accepting a stable hash rate per card and live with it. Its really a driver issue anyway and you are taking risks when overclocking that you will put the system into an unrecoverable state.

I personally don't need a feature in CAST that disables the cards and I don't think that would be helpful for people who have configured their systems correctly. I reboot once a week for windows updates, other than that I don't really look at the rigs.

If you need these bandaid scripts to monitor your hash rate cause it drops or your cards hang you have other problems that are not associated with the miner. I would rather the dev spend time improving the miner efficiency rather than adding some lame monitoring function that is completely unnecessary.

Oh and by the way I use Wattman. YIKES!

That suggests that maybe there's a typo in your pool server address or port number, or the pool server is momentarily unavailable.

can anyone help? I'm getting a socket error: Timeout while waiting for a reply

using a single RX580 to test it out

I've noticed that when Windows blocks CastXMR from accessing a GPU because of aggressive overclocking, the software doesn't handle it very gracefully. The affected GPU stops reporting its hashrate every five seconds, and after a few minutes the software hangs entirely and multiple ^C are needed to terminate the run, assuming that the system doesn't freeze entirely and need a warm reset.

A useful feature would be for CastXMR to recognize that if it is accessing a list of GPUs, each of them should report results periodically, and if one of them goes missing for, say, twice the running average time between results, then it should be considered dead, and a clean restart of CastXMR should be initiated.

Or better yet, if CastXMR could perform a disable/enable of the problem card and then reinitialize it individually, so that none of the other cards had to be bothered.

With a Mining Expert 19-slot motherboard running a pile of aggressively overclocked Vegas, you're more likely to wedge one of the cards than usual, and being able to recover gracefully from that situation would substantially improve the average hashrate.

The trouble is that the way CastXMR enumerates the GPUs makes this somewhat more difficult.

The OverDriveNTool lists the cards in PCIe enumeration order, which you get running devcon listclass display, but GPU0 on CastXMR is not the same as the first Vega GPU on the PCIe bus as shown in devcon and OverDriveN.

In addition, when you say "-G 3" to select only the fourth GPU for the run, which is not necessarily the fourth GPU in the PCIe list, the logging reports it as "GPU0" instead, most of the time. So to test your overclock, you have to figure out which PCIe device corresponds to which PCIe device.

In addition, if you add a GPU to the system, then the sequence in the PCIe enumeration order can change, so your OverDriveNTool command line has to change as well.

I was able to determine that there's no way to get the hardware serial number out of the Vega, or NVIDIA cards. The closest you can come is the Plug-and-Play identifier in the PCIe device string that devcon shows, but that can get shuffled under some circumstances as well.

Basically in order to apply specific overclock to specific devices, you need to use something like PowerShell to probe the device ID string for each of the cards in the list, and grab the PnP ID out of it and map that to a suitable OverDriveN profile based on your overclock testing, and assign that profile to the appropriate card number based on the PCIe device list, and hope that the PnP ID stays the same when you add your next card.

If you have multiple cards,
it maybe because you did not deactivated Crossfire.

Other than that, you are giving way not enough information, to make even a wild guess....

Here you go:

Memory ELPIDA, 4G

CPU Clock: 1350
CPU Voltage: 900mv
MEM Clock: 1950
Mem Voltage: 1000mv
Running at 60 C

hope this helps

i reinstalled windows from scratch as was playing up.
and still same.
i start cast_xmr and it crashes straight away with window
cast_xmr-amd has stopped working.
any idea why??

can you share your AB settings
CV
CC
MC
what is your memory ?
thanks before

Have anybody experince with Mining SUMOKOIN with the CAST XMR Miner?

I got the following issue.

I tried diffrent Pools, but always the same issue, after a couple of hours, and maybe 100-500 accepted shares, I got this Error on the miner for all GPUS:

[07:58:52] GPU0 | 43°C | Fan 3278 RPM | 1974.3 H/s
[07:58:54] GPU1 Found Nonce, submitting...
[07:59:04] !Rejected by pool! Reason: Unauthenticated
[07:59:04] Shares: 411 Accepted, 690 Errors | Hash Rate Avg: 3937.0 H/s | Avg Search Time: 128.9 sec

I start the Miner like this:
cast_xmr-vega -R -G 0,1 -S sumo.sumominer.com:4445 -p x -u MY_WALLET

Any idears how to solve this?

Thank you guys!

This is a typical riser issue.  Flakey risers can cause some very odd issues.

Where do I find version 7?