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

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.

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

using a single RX580 to test it out

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!

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??



 

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

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

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.

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

Where can I put a LIKE on your post?