Hi,

finally, the days of the blockchain compute beta drivers are numbered.

Here is an update of Cast XMR. The 99% refer to the performance when the same memory clock is set.

Regards,
glph3k


Cast XMR Version 0.9.2 (2018/03/29)

  - Improvements for RX Vegas that achieve 99% the performance of the Blockchain Compute Beta driver with the latest standard Radeon Driver 18.3.4

Download Cast XMR 0.9.2 for Windows (64bit)

SHA256 hash of cast_xmr-vega-win64_092.zip:
83e35e16e4e4c57065113323ab9dfd1782935154265f9730bd18877dfbe1adfe

This nice app can do it: https://github.com/anadventureisu/cast-xmr-ui

Regards,
glph3k

Hi,

a new version is available:

Cast XMR Version 0.9.1 (2018/03/22)

  - 0.5% overall performance improvement for Vega based GPUs

  - --ratewatchdog experimental option to monitor the hash rate, in case an occasional happening drop of the hash rate is detected the kernel will be resetted to restore the optimal hash rate

  - fully tested CryptoNight variant (CryptoNightV7) for the Monero V7 Network Upgrade PoW Change which is now scheduled for the 6th April.

  - In case you want to mine the Graft coin use the --algo=0 option, an automatic detection of the used CryptoNight variant is not possible for this coin. For all other known CryptoNight coins the hash variant seems to be detected correct

  - In case you are mining with nicehash.com or any other automatic coin switching pool that has the Graft coin in the mix the --algo=0 option is advised to prevent invalid shares on the Graft coin. Be aware to remove the option when the Monero V7 network upgrade is happpening otherwise it then will clash with mining Monero!



Download Cast XMR 0.9.1 for Windows (64bit)

SHA256 hash of cast_xmr-vega-win64_091.zip:
fe347f919ea2af7a1d901d14aca6a28871206c94f95de0dc0ca7d36a200ceeb2

It just compares the current hash rate with the average hash rate if it is below a certain threshold it resets the kernel for the affected GPU.

It should be faster then a complete restart and if only some GPUs have an hash rate drop only those have to be reseted and it does not lose the current job state.

The exact reason for a sudden hash rate drop is still to be found, but it seems to be rooted deep in the driver. I suspect that it has to do something with power level switichings (ACPI) or similar.

Regards,
glph3k

Use the option --algo=0 to force classic CryptoNight.

Graft reports that it is Version 7, the flag which Monero uses for the upcomming switch to their new CryptoNight variant.

The kernel for 'classic CryptoNight' did not change and is technical the same as in version 0.8.5  so a change in power consumption would be strange.
 
The CryptoNightV7 kernel is a little more complex but the additional instructions are still masked by the memory accesses and do have no real performance influence.

So if still running with classic CryptoNight the power consumption an therefore fan speed should be the same. For CryptoNight V7 a tiny increase would be explainable.

Regards,
glph3k

Hi,

found the coin that has problems with CryptoNightV7: GRAFT

https://www.graft.network/

It reports that it is CryptoNote V7, but relies on the classic CryptoNight hash.

Unfortunatly nicehash.com has Graft in its CryptoNight mix.

So in case you want to mine successful Graft or are using nicehash.com, please use the --algo=0 switch for cast XMR 0.9.0.

Will try to sort it out in the next update.

regards,
Glph3k

It is a know issue. Maybe related to heating or some internal driver problem. A fix is to use a mining monitor like:

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

It will automatically detect the drop and restart cast XMR.

Hi,

thanks, that is indeed interesting.

There seem to be CryptoNote currencies around and in the mix of nicehash.com that already use the version 7 flags.

The version 7 flag is used in Monero for switching to the new PoW hash, which then clashes with other currencies that have also a version 7 but uses classic CrypthoNight.

Will have to find out which currencies that is/are.

The problem is not only cast XMR related, but a general problem of nicehash.com and/or CryptoNight hashing.

Sorry, bleeding edge, probably one of the first to encounter. Will report on the Monero forums.

To fix the current issue with cast XMR when using nicehash.com is to use the "--algo=0" flag, to force the current CryptoNight PoW.


Regards,
glph3k

Using Nicehash all the time, no problems.

With which error messages are they rejected?

How many GPUs?

Which pool?

Hi,

an Cast XMR update is available.

The main reason for the update is the integration of the PoW changes to CryptoNight for the Monero V7 network upgrade which are documented here:

https://github.com/monero-project/monero/pull/3253

The Monero V7 network upgrade is planned to be end of march, an exact and final block height is not set yet. So stay up to date!

Regards,
glph3k


Cast XMR Version 0.9.0 (2018/03/08)

  - support for the Monero V7 network upgrade. Read more about it here
  - the Monero PoW switch will be automatically detected, no restart of cast XMR is required. Only make sure to update cast XMR before the network upgrade is happening and that the used Monero pool supports the network upgrade
  - no decrease in hash rate for other currencies was introduced by the change
  - CryptoNightV7 will run at the same hash rate as CryptoNight
  - for any case there is the new --algo option to force which CryptoNight variant to use:
    - -1 = autodetect (default)
    - 0 = CryptoNight
    - 1 = CryptoNightV7 (Monero V7 network upgrade)


Download Cast XMR 0.9.0 for Windows (64bit)

cast_xmr-vega-win64_090.zip SHA256 fingerprint:
49fe7e231cf5d4434c5d0fcb69af261a6e4e7340441d4d6ad9f4022854e38027

Hi yondy12,

is this  also happening with the lastest version 0.8.5? I know that 0.8.3 could have such a problem.

Maybe use a mining monitor like cast-xmr-ui (https://github.com/anadventureisu/cast-xmr-ui/releases) which automatically restarts cast when it detects a performance drop.

Regards,
glph3k

Dear duyquang06,

thank you, same wishes to you.

What GPUs are you using? Testing was running 72h on Vega 56 and Vega 64 without problems. Basically the --fastjobswitch cancels the current job as fast as possible and switches to the new job.

How many GPUs are you running on one machine?

Maybe running out of virtual memory?

Regards,
glph3k

Hi,

there will be an update of Cast XMR to support the modified PoW algorithm of Monero (XMR) as soon when it is decided what the final modification will be. Make sure to update Cast XMR when the modification is available, Cast XMR will then automatically switch to the new PoW when the switch in Monero is happening. So stay tuned.


Regards,
glph3k

That is indeed a bug in the blockchain driver. But it does not matter as the value is only informative and not taken into consideration. The actually available compute units on the Vega 56 are indeed 56.

Sorry, I can also only speculate as programming with OpenCL and CGN assembler only allows to optimize what a kernel does and to some degree how the kernels are organized and scheduled.

On driver level the scheduling of kernels is implemented also on driver level probably the bandwidth of memory can be influenced as not only the CGNs need access to memory but also the other parts of the GPU that do the actual graphics rendering. Random access memory bandwidth (not compute) is for CryptoNight the limiting factor, as the algo is mainly reading and writing to random parts of memory.

So if I would make a driver for compute only stuff I would give the CGN kernels higher priority and max memory bandwidth and thereby slow the graphics rendering. Which can be experienced with the blockchain driver.

Can only guess if the AMD engineers manage or are willing to combine both use cases in on driver. As they managed for the RX 570/580 with the 'compute mode'.


Do the blockchain driver not work with non reference cards? As the OEMs are just building different cooling designs on the cards?

Sorry, for late update, but here it is:

Regards,
glph3k


Cast XMR Version 0.8.5 (2018/02/07)

  - 1% performance gain for Vega Frontier Edition with Blockchain driver (fastest GPU around)
  - 1% performance improvement with current stock driver (18.1.1) for RX Vega 56/64 (40% to go to reach Blockchain driver performance)
  - fix for random blocking console output
  - GPU now always logs with its device id not the order they are listed in the -G argument
  - --log option to log console output to a file
  - remote access includes CORS support in HTTP header

Download Cast XMR 0.8.5 for Windows (64bit)

cast_xmr-vega-win64_085.zip SHA256: 800af3739896c1012605217632a7ffa962abbb0ecd11370cfbc15e4b21a09015

Hi Macrophage,

yeah, wasting time to highly optimized a software to a very limited available hardware is for sure a good plan to steal many wallets?

Please wireshark the software.

Though will publish the SHA1 fingerprint so people can check if they have the official version and not a tempered one with the next version.

Regards,
glph3k

Please try with --opencl=0

Hi,

that the GPUs hashrate output is not ordered anymore is a known behaviour as they report their current hashrate independent. This was a fix when used with GPUs of different type were used sometimes 0.0 Hash/s was reported as one of the GPU was not ready with its task yet.

Will see if it gets sorted again in the next update