An Introdction to RandomX, Benchmarking tool and pool/solo mining

Mining
1

This thread is about RandomX,

If you have come here from the RandomX GitHub please post questions regarding setup and issues in this thread not the GitHub - I am more than willing to help.

TXXChangecoin is pretty much a dead project. the dev just vanished one day. ah well. it served its purpose well. thankyou @txxchangecoin

This op covers basic windows desktop config. I recommend the ubuntu instructions for consistency and ease of use.

If you are new here and found this place via RandomX, welcome to zcash. We too are a privacy centred coin. Take a look around and I hope you enjoy your stay.

DISCLAIMER ABOUT TXChangeCoin, my involvement and why I focus on them

Statement of my interest and involvement.

this is from a post lower down in this thread I thought it best to add to the OP

Full disclosure I help out with TXChangeCoin. We have similar goals and they have saved me a ton of work - we have something even more exciting coming up - so I have no financial interest but I am on the team as it were.

There are a few projects that have already integrated randomx (loki and wownero) both of these have their own custom parameters for RandomX and are supported by the latest XMRIG.

I am going to concentrate on TXChangeCoin, the third coin I know of that had integrated RandomX, but uses one uses the default parameters - the same as the benchmarking tool, and most likley what Monero will be using in the October network update.

First a brief word about TXChangeCoin. - https://github.com/txchangecoin-project/txchangecoin

  • Their was no ICO/Premine,
  • there is no dev donation,
  • They do not court exchanges.
  • It is still under test so expect bugs, but everything does function.
  • We (the dev and I) are both enjoying playing with technology rather than chasing profits.
  • It is a great soak test for power consumption, noise, etc.
  • I have been running 3 servers on it for a bit. when you start mining let me know your address and I will send you some coins.
  • We are both doing this for free, so a thank you goes a long way.

This is why I am going to focus on that for the majority of pooled mining.

Because we can act more dynamically than coins that are listed on exchanges, etc, we can do a lot more adjustments to parameters, etc. But that is for a different thread.

This thread is about getting a working test environment and playing with config options.

TXChangeCoin has decided to only official build binaries and releases for XMRIG that are actual XMRIG releases. not the beta ones.

If you would like to checkout the beta releases, they will work see below:

beta releases working with default RandomX parameters

Download the release you want to try out from XMRIGā€™s GitHub (the beta I recommend is v2.99.5 for its NUMA support and bug fixes.) and follow these instructions.

In order to use the beta release you need to just change one parameter
from

./xmrig -a rx/test <rest of stuff>

The latest version of the xmrig - v2.99.5-beta now requires this to use default RandomX parameters.

./xmrig -a rx/test <rest of stuff>

If you are using a previous beta version (2.99.3-beta for example) you need

./xmrig -a rx/0 <rest of stuff>

If you ever get this error

It means you are using the wrong algo with the wrong miner switch from rx/0 (xmrig 2.99.3/4-beta) or rx/test (xmrig 2.99.5-beta) to rx/txx or vice versa.

UPDATE 19/August.

UPDATE 11/August

  • updated the command for running default RandomX parameters on XMRIG v 2.99.5-beta

UPDATE 1/August

UPDATE 30/July

  • reorganised a bunch of stuff.
  • deleted non relevant info.
  • added more disclaimers to posts and a long disclaimer to the OP about TXchangeCoin
  • moved a lot of stuff around in this post. hopefully this thread reads better now. it is still work in progress.

UPDATE 29/July

UPDATE 28/July

UPDATED 27/July :

  • After creating a guide for solo and pooled mining, it is evident that unetbootin does - not allocate more than 4gb as a persistence file no matter what size - This is because it formats the whole drive as FAT32. Updated instructions to reflect using YUMI.

UPDATED 11/July/19

Initial post. still contains some relevant info.

Initially using the benchmarking tool on windows, but I will go deep on the internals of it. Lets start out slow.

Please keep reading the thread for information about RandomX in general - for example potential optimisations, there is more info in the thread than just mining/benchmarking.

Updated op that started this thread. The wording my seem a little strange at points. I have removed a lot of out dated info and put it at the end of the post.

Get all windows updates. - if this is an issue for you see my ubuntu usb guide linked above.

The windows updates have given me a bit increase in hashrate and the benchmark program scales more inline with the outlined specs.

Test i7 Laptop

CPU-Z TXT Report

Processors Information

Processor 1 ID = 0
Number of cores 2 (max 2)
Number of threads 4 (max 4)
Name Intel Core i7 3540M
Codename Ivy Bridge
Specification Intel(R) Coreā„¢ i7-3540M CPU @ 3.00GHz
Package (platform ID) Socket 1023 FCBGA (0x4)
CPUID 6.A.9
Extended CPUID 6.3A
Core Stepping E1/L1
Technology 22 nm
TDP Limit 35.0 Watts
Tjmax 105.0 Ā°C
Core Speed 3487.9 MHz
Multiplier x Bus Speed 35.0 x 99.7 MHz
Stock frequency 3000 MHz
Instructions sets MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, EM64T, VT-x, AES, AVX
L1 Data cache 2 x 32 KBytes, 8-way set associative, 64-byte line size
L1 Instruction cache 2 x 32 KBytes, 8-way set associative, 64-byte line size
L2 cache 2 x 256 KBytes, 8-way set associative, 64-byte line size
L3 cache 4 MBytes, 16-way set associative, 64-byte line size
FID/VID Control yes

Thread dumps

CPU Thread 0
APIC ID 0
Topology Processor ID 0, Core ID 0, Thread ID 0
Type 01020101h
Max CPUID level 0000000Dh
Max CPUID ext. level 80000008h
Cache descriptor Level 1, D, 32 KB, 2 thread(s)
Cache descriptor Level 1, I, 32 KB, 2 thread(s)
Cache descriptor Level 2, U, 256 KB, 2 thread(s)
Cache descriptor Level 3, U, 4 MB, 16 thread(s)

Chipset

Northbridge Intel Ivy Bridge rev. 09
Southbridge Intel QM77 rev. 04
Memory Type DDR3
Memory Size 16 GBytes
Channels Dual
Memory Frequency 797.3 MHz (1:6)
CAS# latency (CL) 11.0
RAS# to CAS# delay (tRCD) 11
RAS# Precharge (tRP) 11
Cycle Time (tRAS) 28
Command Rate (CR) 1T
Host Bridge 0x0154

MCHBAR I/O Base address 0x0FED10000
MCHBAR I/O Size 19456
MCHBAR registers

Memory SPD

DIMM # 1
SMBus address 0x50
Memory type DDR3
Module format SO-DIMM
Manufacturer (ID) Kingston (7F980000000000000000)
Size 8192 MBytes
Max bandwidth PC3-12800 (800 MHz)
Part number 9905428-422.A00LF
Serial number 0B36C2B8
Manufacturing date Week 18/Year 15
Number of banks 8
Nominal Voltage 1.50 Volts
EPP no
XMP no
AMP no
JEDEC timings table CL-tRCD-tRP-tRAS-tRC @ frequency
JEDEC #1 5.0-5-5-14-19 @ 380 MHz
JEDEC #2 6.0-6-6-16-22 @ 457 MHz
JEDEC #3 7.0-7-7-19-26 @ 533 MHz
JEDEC #4 8.0-8-8-22-30 @ 609 MHz
JEDEC #5 9.0-9-9-24-33 @ 685 MHz
JEDEC #6 10.0-10-10-27-37 @ 761 MHz
JEDEC #7 11.0-11-11-28-39 @ 800 MHz

DIMM # 2
SMBus address 0x52
Memory type DDR3
Module format SO-DIMM
Manufacturer (ID) Kingston (7F980000000000000000)
Size 8192 MBytes
Max bandwidth PC3-12800 (800 MHz)
Part number 9905428-417.A00LF
Serial number 593A5631
Manufacturing date Week 13/Year 15
Number of banks 8
Nominal Voltage 1.35 Volts
EPP no
XMP no
AMP no
JEDEC timings table CL-tRCD-tRP-tRAS-tRC @ frequency
JEDEC #1 5.0-5-5-14-19 @ 380 MHz
JEDEC #2 6.0-6-6-16-22 @ 457 MHz
JEDEC #3 7.0-7-7-19-26 @ 533 MHz
JEDEC #4 8.0-8-8-22-30 @ 609 MHz
JEDEC #5 9.0-9-9-24-33 @ 685 MHz
JEDEC #6 10.0-10-10-27-37 @ 761 MHz
JEDEC #7 11.0-11-11-28-39 @ 800 MHz

I have done some very basic CPU testing so far. From these results (they are averages) you will see the very basics of how to use the benchmark tool. I do intend to go much further with this - This is just some very basic stuff. More to follow.

According to the github - [link] you want
16 KB of L1 cache
256 KB of L2 cache
2MB of L3 cache per thread.

The basic output of the tool is like this:

This example is from a Dell Latitude E6230, i7-3450M - 2 core/4 threads @3.5gh boost, 16gb ddr3 [not 100% sure of the speed, heh]
L1 - 128KB
L2 - 512MB
L3 - 4MBNO
Using power usage as displayed in coretemp.

command:

benchmark --mine --init 4 --threads 2 --nonces 10000 --largePages --jit

This produces:

RandomX benchmark
 - full memory mode (2080 MiB)
 - JIT compiled mode
 - hardware AES mode
 - large pages mode
Initializing (4 threads) ...
Memory initialized in 8.70408 s
Initializing 2 virtual machine(s) ...
Running benchmark (10000 nonces) ...
Calculated result: c3f95625df8cfebe179a46dc640b52885c660d56e71cd19ac70f947a2fd401db
Performance: 998.182 hashes per second
  • line 1 is because we have the --mine flag
  • line 2 is because we have the --jit flag [This is essential to test an x86 cpu]
  • line 3 is default because the cpu supports hardware AES
  • line 4 is large pages as apposed to small pages. This makes a big difference. - see below how to enable large pages in windows.
  • line 5 is the amount of threads specified by --init. More detail on this to come.
  • line 6 is the time taken to create the memory scratch pad (i think thats what it is called) - This is directly related to core speed and the --init value.
  • line 7 is the number of mining VMā€™s created, this is the --threads parameter.
  • line 8 is it showing it is doing something, and how many, this does not update in realtime.
  • line 9 is the resulting hash. For --seed 0 and --nonces 10000 everybody should get this exact hash regardless of hardware or settings.
  • line 10 - speaks for itsself. This number fluctuates by 5% but this is probably more to do with my monitoring software.

How to enable large pages in windows: [vega monero miners already do this]

Enabling largePages
  • Press start and type gpedit, this should bring up the Local Group Policy Editor
  • Windows settings ā†’ security settings ā†’ local policies ā†’ user rights assignment
  • Now scroll down to Lock Pages In Memory
  • Double click it
  • Add the user which will be doing the testing. I normally just add administrotor
  • Click check name, to make sure it is the correct name - if you sign in with an @example.com then you need to add that.
  • Reboot.
  • Dont forget if you only added LOCAL-PC/Administator you will need to run the command prompt as admin :slight_smile:

Basic overview of how to configure your test setup.

You want the --init parameter to be as close to your total cpu thread count. - This reduces the time to initialise the memory. I am still not 100% on how often this needs to be redone.
You want to fiddle with the --threads parameter. A basic guide is 1 per 2mb of L3 but there are some variances I have yet to work out.

A simple yet effective method to test this in windows is to have up the performance monitor and set the cpu graph to be Overall Utilization:
When the Memory is initializing you want it to show 100% usage. (See table 1 for time examples, v usage.)

Table 1

Note: this is only over 1000 nonces so the hashrate will fluctuate a bit. A key take away is > 4 makes no difference.
init 1 - 30% cpu @ 15 watts
init 2 - 60% cpu @ 19 watts
init 3 - 90% cpu @22 watts
init 4 - 100% cpu ??

This only impacts the Initializing time. It seems no impact on hashrate or threads (VM cpu) usage

  • benchmark --mine --init 1 --threads 2 --nonces 1000 --largePages --jit

Initializing (1 thread) ā€¦
Memory initialized in 21.187 s
Performance: 943.445 hashes per second

  • benchmark --mine --init 2 --threads 2 --nonces 1000 --largePages --jit

Initializing (2 threads) ā€¦
Memory initialized in 11.595 s
Initializing 2 virtual machine(s) ā€¦
Performance: 920.051 hashes per second

  • benchmark --mine --init 3 --threads 2 --nonces 1000 --largePages --jit

Initializing (3 threads) ā€¦
Memory initialized in 9.68857 s
Performance: 958.648 hashes per second

  • benchmark --mine --init 4 --threads 2 --nonces 1000 --largePages --jit

Initializing (4 threads) ā€¦
Memory initialized in 8.6624 s
Performance: 980.156 hashes per second
Note the Init speed. even if you increase the init value this number doesnt change.

  • benchmark --mine --init 5 --threads 2 --nonces 1000 --largePages --jit

Initializing (5 threads) ā€¦
Memory initialized in 8.69043 s
Performance: 963.246 hashes per second
Note: Perf seems a little high, but we are only checking 1000 nonces.

  • benchmark --mine --init 6 --threads 2 --nonces 1000 --largePages --jit

Initializing (6 threads) ā€¦
Memory initialized in 8.67927 s
Performance: 932.245 hashes per second
Note: Perf stil seems a little high, but we are only checking 1000 nonces.

  • benchmark --mine --init 7 --threads 2 --nonces 10000 --largePages --jit

Initializing (7 threads) ā€¦
Memory initialized in 8.68968 s
Performance: 948.815 hashes per second

benchmark --mine --init 8 --threads 2 --nonces 10000 --largePages --jit
Initializing (8 threads) ā€¦
Memory initialized in 8.73109 s
Performance: 995.622 hashes per second

Threads work differently.

Summary:

You get 30% increase in cpu usage with each extra thread (remember this is tested on the above i7) and an increase in hashrate.

2 seems to be the sweet spot now. gives somewhere between 950 - 1000 hashes. Where as 3 seems to give 900 - 950 but at an extra 30% cpu. This is tested over 100000 nonces. 4 thermal throttles down to 3.0 ghz a couple of times. I would try with additional cooling like I was going to before. But since the patches it seems unnecessary.

Table two contains info for threads 1,2,3 and 4.

Table 2
  • benchmark --mine --init 4 --threads 1 --nonces 100000 --largePages --jit

Initializing 1 virtual machine(s) ā€¦
Running benchmark (100000 nonces) ā€¦
Calculated result: 9b22794882187000d62c6d2b228fab5e585767aaaa5eb74905b0c7c00fcbdad8
Performance: 606.123 hashes per second

  • benchmark --mine --init 4 --threads 2 --nonces 100000 --largePages --jit

Initializing 2 virtual machine(s) ā€¦
Running benchmark (100000 nonces) ā€¦
Calculated result: 9b22794882187000d62c6d2b228fab5e585767aaaa5eb74905b0c7c00fcbdad8
Performance: 964.728 hashes per second

  • benchmark --mine --init 4 --threads 3 --nonces 100000 --largePages --jit

Initializing 3 virtual machine(s) ā€¦
Running benchmark (100000 nonces) ā€¦
Calculated result: 9b22794882187000d62c6d2b228fab5e585767aaaa5eb74905b0c7c00fcbdad8
Performance: 945.195 hashes per second

  • benchmark --mine --init 4 --threads 4 --nonces 100000 --largePages --jit

Initializing 4 virtual machine(s) ā€¦
Running benchmark (100000 nonces) ā€¦
Calculated result: 9b22794882187000d62c6d2b228fab5e585767aaaa5eb74905b0c7c00fcbdad8
Performance: 869.339 hashes per second
Note: This thermal throttled to 3.0ghz from 3.5 a number of times.

I have been doing much more testing on my ryzen 2600 and from that I can make some basic inferences. I have not tested these thoroughly yet though

  • Core speed is relevant. but not that relevant.
  • DDR4 Memory frequency matters a lot! (I can get 4400+ hashes)
  • Memory timings do matter, but I am not sure as to what extent, but I think more than core frequency.
  • I have lots more testing to do.
  • I have had random lockups when running this tool on ryzen, as in total system freeze - no data dumps, nothing - had to reset the bios to even get into it. I think this was due to my memory timings being really really tight.

Hope this helps someone.

Steve

Here is some info from and incorrect configured machine. This information is outdated, but kept to highlight the differences.

probably not relevant anymore

Please see this GitHub issues regarding the bug I encountered. I closed it as ā€œcannot reproduceā€ - I will leave this waring up though. Running more than one instance on a consumer grade CPU (non NUMA, is pointless and results in no benefits. - upgrading all the windows patches does though)

If you have accidentally run two instances and get the blue screen memory management issue, these steps completely resolved the issue for me.

How I managed to recover to a normal state

I had a number of dotnet files corrupted. specifically MSCORMMC.DLL which makes sense.
This might have happened because I was missing two updates for recent dotnet. or it might just be because something else was trying to use the mmc at the same time. I donā€™t know.

In order to get these update I needed to install dotnet 4.8. - This also appears to gives a hash rate increase. donā€™t know why.

An additional bonus of having all this up to date is that you get significant hashrate increase. Version numbers to come. Window 1903 spring 2019 update gives me the best performance.

Details of running two instances were quite surprising. Now they are irrelevant. Donā€™t bother doing it. Just update to the latest versions of everything via windows update and run one optimised instance. I have left the stuff below to show how bad hashrate can be caused by missing windows updates. and how running two instances with full updates is the same as running one instance.

For those who donā€™t or cannot mess with their windows patch management I suggest following the ubuntu guide linked above.

Two concurrent benchmarking instances - not worth it. left in anyway.

Notice the combined hashrate is the same as just one instance. It ran over 100000 nonces. I fell asleep whilst it was running and didnā€™t record the cpu usage. - Iā€™m guessing 100%, if it was then more cooling might give more hashes. Or the cpu might have just correctly allocated half of the resources to each instance so I was only using the normal amount of CPU and gained nothing.

I will re run this on ryzen, where I have better cooling and a lot more control over the config.

I also did not fire off both instances at the same time I waited for the first instance to finish initialising (11 seconds. Not 100% why it was longer than normal, maybe something to do with unrelated background tasks.)

FWIW - im pretty sure that the actual bug was a kernel exploit. When I go through my patching I will try to find the CVE for the bug. It may be an intel only bug, or a windows bug, or something entirely different. - It seems a windows dotnet bug to me at this point though.

Old benchmarks.

Old benchmarks with an non up to date windows 
benchmark --mine --init 4 --threads 2 --nonces 100000 --largePages --jit
RandomX benchmark
 - full memory mode (2080 MiB)
 - JIT compiled mode
 - hardware AES mode
 - large pages mode
Initializing (4 threads) ...
Memory initialized in 12.5623 s
Initializing 2 virtual machine(s) ...
Running benchmark (100000 nonces) ...
Calculated result: 9b22794882187000d62c6d2b228fab5e585767aaaa5eb74905b0c7c00fcbdad8
Performance: 500.141 hashes per second

benchmark --mine --init 4 --threads 2 --nonces 100000 --largePages --jit
RandomX benchmark
 - full memory mode (2080 MiB)
 - JIT compiled mode
 - hardware AES mode
 - large pages mode
Initializing (4 threads) ...
Memory initialized in 11.1539 s
Initializing 2 virtual machine(s) ...
Running benchmark (100000 nonces) ...
Calculated result: 9b22794882187000d62c6d2b228fab5e585767aaaa5eb74905b0c7c00fcbdad8
Performance: 478.394 hashes per second

So follow the new instructions. :slight_smile:

4 Likes
2

@Sacsayhuaman

Id love to help :slight_smile:

I have copied this from the ASIC thread to here, I think this is a better place to discuss this stuff.

When you say you are mining at the moment, what are you mining? I am pretty new to RandomX myself though.

If you can provide some more info on:

  • CPU Make/Model
  • Ram Frequency
  • Ram type (ddr3/4)
  • Ram Config (dual channel, etc)
  • Ram timings.
  • Ram Size
  • Bios version and MB version
  • CPU Microcode version.

With that info I can make a guess, and I can also give you some good parameters to get a rough idea with the benchmarking tool.

A lot of this in fact all of it (bar the microcode, that is a strange one to get depending on the cpu/mb) you can get from CPU-Z

If you open up CPU-Z, go to about, click on save as txt file.
Open the text file, then search for these headers

  • Processors Information
  • Thread dumps
  • Chipset
  • Memory SPD

You do not need to put all of the info from each section into your post. I have show the relevant data below.

If you use [details] brackets for the text it becomes expandable.

Here is an example of the report from the laptop above I have done the testing with. If you cannot get this report donā€™t worry too much but try to answer the first set of questions.

Would you mind running a few tests?

Test i7 Laptop

CPU-Z TXT Report

Processors Information

Processor 1 ID = 0
Number of cores 2 (max 2)
Number of threads 4 (max 4)
Name Intel Core i7 3540M
Codename Ivy Bridge
Specification Intel(R) Coreā„¢ i7-3540M CPU @ 3.00GHz
Package (platform ID) Socket 1023 FCBGA (0x4)
CPUID 6.A.9
Extended CPUID 6.3A
Core Stepping E1/L1
Technology 22 nm
TDP Limit 35.0 Watts
Tjmax 105.0 Ā°C
Core Speed 3487.9 MHz
Multiplier x Bus Speed 35.0 x 99.7 MHz
Stock frequency 3000 MHz
Instructions sets MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, EM64T, VT-x, AES, AVX
L1 Data cache 2 x 32 KBytes, 8-way set associative, 64-byte line size
L1 Instruction cache 2 x 32 KBytes, 8-way set associative, 64-byte line size
L2 cache 2 x 256 KBytes, 8-way set associative, 64-byte line size
L3 cache 4 MBytes, 16-way set associative, 64-byte line size
FID/VID Control yes

Thread dumps

CPU Thread 0
APIC ID 0
Topology Processor ID 0, Core ID 0, Thread ID 0
Type 01020101h
Max CPUID level 0000000Dh
Max CPUID ext. level 80000008h
Cache descriptor Level 1, D, 32 KB, 2 thread(s)
Cache descriptor Level 1, I, 32 KB, 2 thread(s)
Cache descriptor Level 2, U, 256 KB, 2 thread(s)
Cache descriptor Level 3, U, 4 MB, 16 thread(s)

Chipset

Northbridge Intel Ivy Bridge rev. 09
Southbridge Intel QM77 rev. 04
Memory Type DDR3
Memory Size 16 GBytes
Channels Dual
Memory Frequency 797.3 MHz (1:6)
CAS# latency (CL) 11.0
RAS# to CAS# delay (tRCD) 11
RAS# Precharge (tRP) 11
Cycle Time (tRAS) 28
Command Rate (CR) 1T
Host Bridge 0x0154

MCHBAR I/O Base address 0x0FED10000
MCHBAR I/O Size 19456
MCHBAR registers

Memory SPD

DIMM # 1
SMBus address 0x50
Memory type DDR3
Module format SO-DIMM
Manufacturer (ID) Kingston (7F980000000000000000)
Size 8192 MBytes
Max bandwidth PC3-12800 (800 MHz)
Part number 9905428-422.A00LF
Serial number 0B36C2B8
Manufacturing date Week 18/Year 15
Number of banks 8
Nominal Voltage 1.50 Volts
EPP no
XMP no
AMP no
JEDEC timings table CL-tRCD-tRP-tRAS-tRC @ frequency
JEDEC #1 5.0-5-5-14-19 @ 380 MHz
JEDEC #2 6.0-6-6-16-22 @ 457 MHz
JEDEC #3 7.0-7-7-19-26 @ 533 MHz
JEDEC #4 8.0-8-8-22-30 @ 609 MHz
JEDEC #5 9.0-9-9-24-33 @ 685 MHz
JEDEC #6 10.0-10-10-27-37 @ 761 MHz
JEDEC #7 11.0-11-11-28-39 @ 800 MHz

DIMM # 2
SMBus address 0x52
Memory type DDR3
Module format SO-DIMM
Manufacturer (ID) Kingston (7F980000000000000000)
Size 8192 MBytes
Max bandwidth PC3-12800 (800 MHz)
Part number 9905428-417.A00LF
Serial number 593A5631
Manufacturing date Week 13/Year 15
Number of banks 8
Nominal Voltage 1.35 Volts
EPP no
XMP no
AMP no
JEDEC timings table CL-tRCD-tRP-tRAS-tRC @ frequency
JEDEC #1 5.0-5-5-14-19 @ 380 MHz
JEDEC #2 6.0-6-6-16-22 @ 457 MHz
JEDEC #3 7.0-7-7-19-26 @ 533 MHz
JEDEC #4 8.0-8-8-22-30 @ 609 MHz
JEDEC #5 9.0-9-9-24-33 @ 685 MHz
JEDEC #6 10.0-10-10-27-37 @ 761 MHz
JEDEC #7 11.0-11-11-28-39 @ 800 MHz

I do see lots of potential avenues for hardware optimisation, along with hardsoftware (microcode - the stuff that defines what your cpu does, even L1/L2/L3 latencies) One currently very busy (not on this unfortunately) has a lot of experience with writing microcode and L1/L2 cache optimisation & design.

He is a long link on why microcode could make a massive difference for RandomX

Anyone serious about optimisation of RandomX mining hardware needs to read that. I will spare the link about Reverse Engineering it. (but that is linked in that article.)

Cheers.

4 Likes
3

A few people have been expressing an interest in helping me test.

I really appreciate it and welcome everyone.

TL:DR
  • Thank you!
  • Write test methodology so we can all do the same tests and understand the results (1 maybe 2 days)
  • Do testing (1-2days maybe?)
  • I still like the details collapsible

Still need to finalise and post ram timings + cpu overclocking then I will delete this post. yay. see the edit history if you want to see what I have done.

I will then be running through a full test methodology (test plan, test cases, formatting of test results, collating and analysis of the results.) for my Ryzen system - I will be posting this too so you can follow and see what is optimum for your setup based of the results you get from the tests. It would be great if you could follow my reporting templates.

Whilst doing the Ryzen testing I am sure I will think of more test cases to add. I am going to create a comprehensive list as I go and people can do them or not. I will not publish a test I have not done myself.

feel free to prod me if I havenā€™t updated in a while. It might be life, it might be an tech issue, or most likely it is taking longer than I thought.

Thanks for all the interest, it really helps motivate me.

2 Likes
6

Vosk Talks about RandomX Mining News! Monero RandomX | Ethereum ProgPoW 2019 Update | Grin Embraces ASIC miners | Zel Zelhash - YouTube

2 Likes
7

Ive never really followed his channel, I watched the randomx bit then stopped.

I think a key point he misses, is that the idea is not that you cannot build an ASIC or FPGA, it is you cannot build a single chip version without that chip more or less resembling a cpu. Then you have to develop your own branch predication or just not take that random branch that might happen.

The weakness if there is one will be in the verification/light mode. That looks very doable, even on cheap hardware - are the trade offs worth it? idk. Thatā€™s why I am looking into it.

The issue with getting this on an FPGA is l3 cache. - you have to either buy something large and expensive (making a cpu the cheaper more efficient option) or work out some way of dropping ā€˜off chip latencyā€™ from >200ns to <40ns. This is way beyond my ability, but not that of MiStFGPA. but it is like herding cats at the moment. everyone is so busy with ā€˜realā€™ jobs.

That is just one of the mechanisms behind the anti fgpa side of RandomX there are others. (floating point being another)

Thanks for the link.

8

How long until RandomX activates on Monero? Will be interesting to see how the activation goes. Last fork I think it took a few hours before blocks starting propagating again?

Hopefully everyone will be able to figure out how to run RandomX to keep the chain secure until the dust settles.

9

Erm, sometime October if all goes to plan, iirc. [code freeze is this month at some point]

Kinda the point of this thread :slight_smile: - will let people know they can process transactions with rubbish 3rd world hardware and still be useful. I know I keep saying this, but I will update the test environment today. and the ryzen stuff. (im just so absorbed in the server side of stuff, so much more interesting)

The desktop UMA (not NUMA) setup for win and Linux with my benchmarks and how to reproduce them yourselves.

To be fair tho I doubt it will make much difference. but if I can get all those old zec miners to dust off their cpuā€™s for RandomX and GPUā€™s for ProgPow Id be happy. I did what I could. (including the fpga L3 cache latency solution should it prove economically viable to produce one [a solution has been proposed, I need to mock up the idea - anyone who has worked in this type of stuff knows that datasheets and technical specs may all agree that you can do something but 9/10 in reality you can never get those ideal conditions])

3 Likes
10

If you have come here from the RandomX GitHub please post questions and issues in this thread not the GitHub - I am more than willing to help.

If you are new here and found this place via RandomX, welcome to zcash. We too are a privacy centred coin. Take a look around and I hope you enjoy your stay.

This assumes you are running from windows environment and want to build a clean(ish) Ubuntu setup on a bootable USB stick to test RandomX. (usb 2.0 is fine, just a bit slow. does not impact the benchmark at all.)

A lot of this info is taken from different posts and the readme on the RandomX github
This post will be specifically dealing with desktop hardware. Light hardware, GPU, Server and FPGA to follow. (in that order probably)

The main point is to get a standard test environment set up and run some basic tests for desktops. There will be further detail in the ryzen post.

First we need to create a bootable, ubuntu install with persistence. This lets you play with overclocking and other stuff. It will keep files across reboots.

Download ubuntu desktop 18.04 from:

(19.04 will work too.)

Download Yumi 2.0.6.7

  • Grab a USB drive (minimum 8gb) usb 3 highly recommended but not required. It runs fine from usb 2.0
  • Format to NTFS
  • Launch YUMI
  • MAKE SURE YOU ARE WRITING TO THE CORRECT DRIVE

Configure like in the image - note set the persistent to be 8 - 16gb.

click to see image

yumi2

Hit Create.
Wait quite a bit. (creating the persistence file can take a little bit of time.)
Now reboot to the usb drive.

Note I have had to manually add ā€œpersistentā€ when booting from UEFI but never when booting from the BIOS. YMMV - follow the instructions below.

Booting via the bios method is the recommended method. UEFI and persistence may not work on some motherboards.

How to boot via the bios

booting from the bios

You can press the key to interrupt the boot and let you select a boot device (normally F11 or F12)

Alternatively if you do not get time to see that screen due to fast boot then:
Press the windows key then type

change advanced startup options

Select restart now.
This will bring up an options screen, select boot from the first listed usb device on the left hand side. NOT usb UEFI on the right hand side.

Which boot options to pick. It will timeout on the default hdd if one is connected after 30 seconds.

Boot splash screens and options

Select the bottom option on this screen, Linux Distributions.

IMG_20190727_213950
IMG_20190727_2139502851Ɨ2138 2.8 MB

Make sure you select Ubuntu-18.0.4.2-desktop from the next screen.

IMG_20190727_214003
IMG_20190727_2140032851Ɨ2138 2.71 MB

Then press enter on the first choice of the next screen.

ubuntu should now boot fine and have more than enough space for testing.

How to boot from UEFI

Boot to USB from UEFI

If you are using UEFI you will probably have to use the windows reboot feature.
Press the windows key then type

change advanced startup options

Select restart now.
This will bring up an options screen, select boot from the new Ubuntu usb install.
If this doesnā€™t work follow the bios instructions above.
[/code]

Once you have launched the persistent USB install, we need to get everything up to date otherwise all sorts of strangeness happens. it is relatively easy. and takes 10 - 15 minutes with a decent network connection.

You get a much greater hashrate with the latest updates, and they are needed for RandomX to function properly.
Because this is the desktop version there is a lot of stuff that gets updated that we dont need. but might as well do it.

bring up a terminal prompt

ctrl+alt+t

Apply some updates and a few tools.

sudo apt-get update
sudo apt-get upgrade
sudo apt-get install cmake git build-essential

Now we have a working ubuntu install we need to get RandomX and its dependices setup.

This next bit is taken straight from the github. is taken straight from the github readme. you do not need to be familiar with compiling code for this to work. it works as is.

This is also slightly easier and less reliant on someone else making binaries for you. Binaries are available on the release page. I am going to deal with compiling from source. (it really is easier)

git clone https://github.com/tevador/RandomX.git
cd RandomX
mkdir build && cd build
cmake -DARCH=native ..
make

This will produce a bunch of output. (cut from post, due to length) You should not get any error messages. If you do post a message below.

We should move the complied benchmarking tool somewhere else for easier testing.

mkdir ~/rdx
mv ./randomx-benchmark ~/rdx/

Might as well run the tests while we are here and then clean up the build process.(If you move the usb stick to a new pc, with different hardware, you might as well compile it again.)

./randomx-tests
make clean

If any of those tests from running ./randomx-tests fail then please post the output below.

Now back to testing, and make sure everything is working.

cd ~/rdx/ and a quick check that the miner is working. This will be slow, and this will not be representative of your actual hashrate, there are a few more tweaks to do after.

./randomx-benchmark --mine --jit

This will just run 1 thread and 1 core so it will take a while. We are not using largePages either, we will set that in a bit.

results of basic test 
RandomX benchmark v1.0.4
 - full memory mode (2080 MiB)
 - JIT compiled mode
 - hardware AES mode
 - small pages mode
Initializing (1 thread) ...
Memory initialized in 24.825 s
Initializing 1 virtual machine(s) ...
Running benchmark (1000 nonces) ...
Calculated result: 38d47ea494480bff8d621189e8e92747288bb1da6c75dc401f2ab4b6807b6010
Reference result:  38d47ea494480bff8d621189e8e92747288bb1da6c75dc401f2ab4b6807b6010
Performance: 395.119 hashes per second

Post the error message below if you get one.

Check that the result it says you should get matches what you do get, if it doesnt something is very wrong. reduce overclock. post below.

Nice, now it is time to configure it. The requirements are:

per mining thread.

to get this info, as well as rough guesses for the --init and --threads value we can use dmidecode - this will produce a page or two of output. the real relevant parts I have posted below. you can scroll up through the terminal window to check all the values.

sudo dmidecode -t processor
The most relevant bits are: 
# dmidecode 3.1
Getting SMBIOS data from sysfs.
SMBIOS 2.7 present.

Handle 0x0053, DMI type 4, 42 bytes
Processor Information
	Socket Designation: SOCKET 0
	Signature: Type 0, Family 6, Model 58, Stepping 9
	Version: Intel(R) Core(TM) i7-3540M CPU @ 3.00GHz

	Core Count: 2
	Core Enabled: 2
	Thread Count: 4

Now we look for the amount of L1,2 and 3 the CPU supports.

sudo dmidecode -t cache
cache values 
Socket Designation: CPU Internal L2
	Configuration: Enabled, Not Socketed, Level 2
	Operational Mode: Write Through
	Location: Internal
	Installed Size: 512 kB
	Maximum Size: 512 kB


Socket Designation: CPU Internal L1
	Configuration: Enabled, Not Socketed, Level 1
	Operational Mode: Write Through
	Location: Internal
	Installed Size: 128 kB
	Maximum Size: 128 kB

Socket Designation: CPU Internal L3
	Configuration: Enabled, Not Socketed, Level 3
	Operational Mode: Write Back
	Location: Internal
	Installed Size: 4096 kB
	Maximum Size: 4096 kB

So, this cpu has

  • 2 Cores (probably maximum threads)
  • 4 Threads (quicker init time)
  • 128kb L1 (no limit)
  • 512kb L2 (limits to two mining threads)
  • 4MB L3 (limits to two mining threads)

So it should fit perfectly with

ā€“threads 2 --init 4

Lets try.

First enable largePages

sudo sysctl -w vm.nr_hugepages=1250

Now try the benchmark (note 50000 nonces takes roughly 1 minute on this cpu, it will be different on yours, adjust so the benchmark takes 1 minute.)

./randomx-benchmark --mine --jit --largePages --threads 2 --init 4 --nonces 50000

So there isnt much point doing ram testing on this hardware, this is cpu limited.

There is not much point in doing overclocking on this laptop, but we should give it a go, This post is long enough so that will be tomorrow.

Now there is a consistent stable test environment I will do the Ryzen testing in this format, but with more ram timings and overclocking. To try to confirm the speculation in the first post.

I have a template already, but im tired. I will continue this later.

I will also re organise this thread to make it easier to read.

1 Like
11

Okay, so I have been slow on updates. I have been working with a dev and we (they) have,

  • Forked monero
  • Integrated RandomX with the Monero parameters
  • Have a working pool
  • Have working solo mining
  • Have a cli and gui wallet.
  • Has a custom version of XMRIG to work with default randomx.

I will be updating this post later with my ryzen results and how to connect and soak test your hardware (Real world conditions are much better than the benchmarking tool)

Whilst I am working on that, and some testing of the GUI, the developer is working on something I am really excited for. but you will just have to wait until it is ready until I tell people.

@Shawn do you see a problem with this? I am technically promoting another coin on this forum (although it is a coin with no ico, no premine, no dev fund, on no exchanges, we are not soliciting exchanges, etc) It is a very good use for zcashers to test out their old hardware - I will ensure posts are kept in this thread and do not disrupt the rest of the forum.

I see it as a grey area. I will go with your decision. I can always put the info on mistfpga.net (but this forum seems to be getting new eyes on it from the randomx GitHub) it always feels nice to be the first mining stuff.

It is not a blockchain fork. only a codebase fork.

Full disclosure I am part of the two person team actively involved in this coin/testcoin.

If I can use this coin as a usage example with my mining guide then I will be giving away free coins to people who start mining so we can do more testing and playing. I have quite a lot and want to distribute them amongst people. (these coins have no monetary value)

2 Likes
14

If you have come here from the RandomX GitHub please post questions and issues in this thread not the GitHub - I am more than willing to help with the config and setup.

If you are new here and found this place via RandomX, welcome to zcash. We too are a privacy centred coin. Take a look around and I hope you enjoy your stay.

Hi,

[Full disclosure I help out with TXChangeCoin. We have similar goals and they have saved me a ton of work - we have something even more exciting coming up - so I have no financial interest but I am on the team as it were.]

So now we have a working ubuntu usb, we have done some testing of the benchmark tool, and we can get a rough estimate of whats going on. What we really need is a real world example to test our hardware against.[update 28/07 - windows binaries are being worked on.]

There are a few projects that have already integrated randomx (loki and wownero) both of these have their own custom parameters for RandomX and are supported by the latest XMRIG.

I am going to concentrate on TXChangeCoin, the third coin I know of that had integrated RandomX, but uses one uses the default parameters - the same as the benchmarking tool, and most likley what Monero will be using in the October network update.

First a brief word about TXChangeCoin. - GitHub - txchangecoin-project/txchangecoin: Txchangecoin (TXX) is a cryptocurrency which focuses on being untraceable and private.

  • Their was no ICO/Premine,
  • there is no dev donation,
  • They do not court exchanges.
  • It is still under test so expect bugs, but everything does function.
  • We (the dev and I) are both enjoying playing with technology rather than chasing profits.
  • It is a great soak test for power consumption, noise, etc.
  • I have been running 3 servers on it for a bit. when you start mining let me know your address and I will send you some coins.
  • We are both doing this for free, so a thank you goes a long way.

I am going to do my ryzen testing via real mining on this pool. the basics are in here. full breakdown of ryzen mining to come.

So after setting up a test environment as outlined in the previous post, lets go from there. NOTE THE SETUP HAS CHANGED DUE TO A MISTAKE BY ME. PLESE USE YUMI TO CREATE YOUR PERSISTENCE

  • one advantage of linux that I have noticed, is it ignores the boost profile of the cpu and rather than boosting just 3 of my 6 cores it defaults to boosting them all to 3.7ghz

Here are the system specs for my ryzen 2600 build. We will quickly run through its stats, then the benchmarking tool, then a real mining pool.

dmidecode -t processor
CPU info for ryzen 2600 
Processor Information
        Socket Designation: AM4
        Type: Central Processor
        Family: Zen
        Manufacturer: Advanced Micro Devices, Inc.
        ID: 82 0F 80 00 FF FB 8B 17
        Signature: Family 23, Model 8, Stepping 2
        Version: AMD Ryzen 5 2600 Six-Core Processor
        Voltage: 1.1 V
        External Clock: 100 MHz
        Max Speed: 3900 MHz
        Current Speed: 3400 MHz
        Status: Populated, Enabled
        Upgrade: Socket AM4
        Core Count: 6
        Core Enabled: 6
        Thread Count: 12

So the important bits to take are, 12 threads, and 6 true cores. so initial parameters of --init 12 --threads 6 looks good. lets check the cache

dmidecode -t cache
dmidecode -t cache

[code]
Handle 0x0010, DMI type 7, 19 bytes
Cache Information
Socket Designation: L1 - Cache
Installed Size: 576 kB
Maximum Size: 576 kB
Speed: 1 ns

Handle 0x0011, DMI type 7, 19 bytes
Cache Information
Socket Designation: L2 - Cache
Installed Size: 3072 kB
Maximum Size: 3072 kB
Speed: 1 ns

Handle 0x0012, DMI type 7, 19 bytes
Cache Information
Socket Designation: L3 - Cache
Installed Size: 16384 kB
Maximum Size: 16384 kB
Speed: 1 ns
/details-]

In summary, according to the info and the spec:

567kb of L1 cache (spec requires 16kb per thread)
3mb of L2 cache (spec requires 256kb per thread)
12mb of L3 - (spec requires 2mb per thread)

so

  • We have More L1 than needed,
  • More L2 than needed
  • it looks like L3 will limit us.

I have 3000mhz CL15 ram. when running under XMP. (I think it is 2133 rated, just high binned)
XMP is enabled for this first set of tests because I believe this will be the most common scenario, further testing and timing to follow in later posts.

XMP, is an overclocking profile set by the manufacture. It is a very good baseline for your ram. Manual overclocking will yield better results. (just checked and I think XMP was off but memory overclock was auto.)

lets check those threads and init parameters quickly in the benchmarking tool.

dont forget to enable large pages

sudo sysctl -w vm.nr_hugepages=1250
cd ~/rdx
./randomx-benchmark --mine --jit --largePages --init 12 --threads 6 --nonces 50000
output from benchmark

That is about expected. however 6,7,8 threads all over 100000 nonces (about a minute) all gave roughly the same hash. To test this further we need to
try real mining over a period of time. and their is a lot of room for improvement.

Thankfully the wonderful people at TXChangeCoin have already done this!

Compiling TXChainCoin from source, takes slightly longer but recommended because it is the easiest way on ubuntu. This runs fine off a usb stick. and it auto grabs the latest versions of randomx, etc.

The main project page is here - GitHub - txchangecoin-project/txchangecoin: Txchangecoin (TXX) is a cryptocurrency which focuses on being untraceable and private.

There is a windows GUI version that seems to have the daemon and wallet-cli functionality, but I have not had a chance to download this or even test it. We will be sticking with ubuntu. for the moment. I will get around to testing the GUI soon. lets get some coins mined and some transactions happening. :slight_smile:

You should do all this via a terminal.

Compile from Source

Now to double check have all the dependencies installed and in the right place. (a lot of these are already installed so will be auto skipped when trying to install again)
Note, we are installing screen. This will be used later.

We need to add the universe repository to get some of these.

sudo apt-add-repository universe
sudo apt update
sudo apt install build-essential cmake pkg-config libboost-all-dev libssl-dev libzmq3-dev libunbound-dev libsodium-dev libunwind8-dev liblzma-dev libreadline6-dev libldns-dev libexpat1-dev doxygen graphviz libboost-chrono1.65.1 screen

On Ubuntu you have to build the binaries for libgtest yourself, for some reason they do not come made, just as source.

sudo apt-get install libgtest-dev && cd /usr/src/gtest && sudo cmake . && sudo make && sudo mv libg* /usr/lib/

Okay now we should have everything we need to compile the project

cd ~/
git clone --recursive https://github.com/txchangecoin-project/txchangecoin
cd ~/txchangecoin
git checkout master
make

Because we are testing lets move the important bits to a new folder.

mkdir ~/txbin
cp ~/txchangecoin/build/Linux/master/release/bin/txchangecoind ~/txbin/
cp ~/txchangecoin/build/Linux/master/release/bin/txchangecoin-wallet-cli ~/txbin/
cd ~/txbin

Now you need to generate a wallet and address so let use screen to create a session in the background for the daemon to sync

screen -S TXD
./txchangecoind

Now if all this goes to plan, you should see a load of test scroll past and the daemon to start syncing. Ignore the DNS records warnings.

What Initialisation of the daemon and syncing should look like

I advise typing help and seeing what you can do. Dont worry about mining for the moment, we will do that in the next step.

So we are now synced we are read to solo mine. We need to detach from the daemon (it will keep running because it is running in a screen session)

press CTRL+A+D to leave the screen session but keep the daemon running in the background (you dont need to use screen you could use two different terminal sessions.

This should return you to a normal prompt.

now run

sudo ./txchangecoin-wallet-cli

Type a name for your wallet and give it a password. After you pick a language you will be given an address and a backup phrase.

Generated new wallet: TXCHQEpCKzy7TYEG4d9hnrWF9LYduLg7uP8Cdqej3v4oPkQia6Z9tQ1AWNoRqfVEDcHz2MSrNcBR45RWoVWfetgG56K1Nau9nK

This is your wallet address, I am not sure if the new address generation bug has been fixed or not yet, so just use the original address assigned when you first initialise the wallet. (obviously not this one)

(rest of output snipped, it is pretty self explanatory. just copy this address.)

Now you can start solo mining!
For my CPU which seemed to do best with 6 cores I would use a command like this
( start_mining [<number_of_threads>] [bg_mining] [ignore_battery] )

start_mining 6 false yes
solo mining hashrate and commands 
Mining started in daemon
[wallet TXCHQE]: exit
ubuntu@ubuntu:~/txbin$ screen -R

2019-07-27 22:34:26.764 I Miner thread was started [0]
2019-07-27 22:34:26.764 I Miner thread was started [2]
2019-07-27 22:34:27.038 I Miner thread was started [1]
2019-07-27 22:34:27.039 I Miner thread was started [3]
2019-07-27 22:34:27.039 I Miner thread was started [4]
2019-07-27 22:34:27.039 I Miner thread was started [5]
hasrate ramp up

(without large pages i get 2k hashes)
show_hr
Hash rate logging is on
hashrate: 2856.0000
hashrate: 2953.1111
hashrate: 3031.1001
hashrate: 3095.0000
hashrate: 3148.5000
hashrate: 3193.9231
hashrate: 3232.8572
hashrate: 3266.1333
hashrate: 3295.7500
hashrate: 3321.4119
hashrate: 3344.2778
hashrate: 3365.0000
hashrate: 3539.1052
hashrate: 3659.2632
hashrate: 3736.0000
hashrate: 3735.6843
hashrate: 3735.4211
hashrate: 3735.4736
hashrate: 3735.2632
hashrate: 3735.9473
hashrate: 3736.4736
hashrate: 3736.8948
hashrate: 3736.3684
hashrate: 3736.1580
hashrate: 3735.7368
hashrate: 3735.1052
hashrate: 3734.6316
hashrate: 3733.8420
hashrate: 3733.0000
hashrate: 3732.2104
hide_hr
Note this takes time to stabilise, about a minute. notice how similar these are to the benchmark results.

Now, The problem is with solo mining you only get rewards if you find blocks. So there is a pool tool.

to connect to the pool you can just use the latest release of xmrig. For the moment we are just supporting the default RandomX paramteters. so use -a rx/test - as outlined in the initial post.

Now you can run the miner from a command line, and it will try to work out what is best. This is pretty good for most situations. and certainly a good initial test to make sure everything is running okay.

It picks 8 cores for my 6 core cpu though. but the hashrate is fine, it matches solo mining.

./xmrig -a rx/test -o stratum+tcp://blocks.txxcoin.tech:4444 -u <YOUR_MINING_ADDRESS> -p YOUR_WORKER_NAME -k

this command line is better, and allows you to adjust the threads parameter to play with different settings for your cpu I suggest using this until the config file issue is resolved.

./xmrig -a rx/test -o stratum+tcp://blocks.txxcoin.tech:4444 --user=<YOUR_MINING_ADDRESS> -pass=<YOUR_WORKER_NAME> -k -r 5 --asm=AUTO --donate-level=1  --print-time=60 --threads=<THREADS>

Adjust the --threads= parameter for your cpu.

The pool will automatically adjust its share target for you. to fix this target (say you have very high, or very low end equipment) change <YOUR_MINING_ADDRESS> to be <YOUR_MINING_ADDRESS.fixed_diff_number>

I recommend letting the pool sort it out though.

In the interactive xmrig shell you can see the number of threads and check you hashrates with the h command. Over time compare this with the pools hashrate for your miner.

It displays 1hr./12hr/24hr it is really useful in testing what you actual hashrate over a period of time would be.

Here is the hashrate graph for my Ryzen 2600 as set up in this tutorial running for 24 hours.

pool
pool1366Ɨ728 101 KB

Happy mining.

edit: forgot to include a basic config file, make sure you change the number of threads and add your mining address.

edit: This config wont work with those versions of the miner. it seems to work with my version (pre- 2.99). I will be looking into it and either generating new configs or a patch to the current mining software.
edit: 19/8 - over the next couple of days I will over haul this thread for the 3.10 xmrig release.

save as config.json in the same folder as the xmrig binary. 
{
 "algo": "rx/test",
 "av": 0,                       // algorithm variation, 0 auto select
 "background": false,          // true to run the miner in the background
 "colors": true,              // false to disable colored output 
 "cpu-affinity": null,       // set process affinity to CPU core(s), mask "0x3" for cores 0 and 1
 "cpu-priority": 2,      // set process priority (0 idle, 2 normal to 5 highest)
 "donate-level": 1,        // donate level, minimum 1%
 "log-file": null,        // log all output to a file, example: "c:/some/path/xmrig.log"
 "max-cpu-usage": 75,    // maximum CPU usage for automatic mode, usually limiting factor is CPU cache not this option. 
 "print-time": 60,      // print hashrate report every N seconds
 "retries": 5,         // number of times to retry before switch to backup server
 "retry-pause": 5,    // time to pause between retries
 "safe": false,      // true to safe adjust threads and av settings for current CPU
 "threads": 1,   // number of miner threads
 "pools": [
 {
 "url": "blocks.txxcoin.tech:4444",      // URL of mining server
 "user": "YOUR_MINING_ADDRESS",               // username for mining server
 "pass": "test",                        // password for mining server
 "keepalive": true,                 // send keepalived for prevent timeout (need pool support)
 "nicehash": false,                // enable nicehash/xmrig-proxy support
 "variant": -1                   // algorithm PoW variant
 }
 ]
}
15

If you have come here from the RandomX GitHub please post questions and issues in this thread not the GitHub - I am more than willing to help with the config and setup.

If you are new here and found this place via RandomX, welcome to zcash. We too are a privacy centred coin. Take a look around and I hope you enjoy your stay.

This guide is for working with windows binaries. for TXChangeCoin - which is a fork of the monero codebase with the default RandomX parameters.

Compiling from source is so much easier under ubuntu and the usb install is a better method for testing imho, because of less background tasks and a standardised building environment.

A lot of people have Windows based desktops so here is a guide:
Also windows has much better overclocking software. This is for desktop hardware not server hardware.

This should be run on a test machine. Not your normal daily windows pc - mainly due to background tasks and possible security concerns. see below.

Make sure you are up to date with all windows patches. (this is for stability and hashrate improvement reasons)

This tutorial is based off:

I have done a very brief review of the code and the binaries and I see nothing nefarious, but still dont trust anyone when it comes to crypto.
because I am involved in this I feel the need to put this info in:

basic crypto computer safety info - please read
  • If you are not using a dedicated testing rig please consider:
  • the risks of installing any 3rd party software on a machine with access you your wallet files. (dont do it, just make an ubuntu USB version)
  • Do not install 3rd party software on machines which you intend to use to send transactions.
  • Use virus total, it is quick and easy. VirusTotal and tests against 64 different virus scanners for you.

results:

VirusTotal results for wallet.exe and xmrig.exe

**1 false positive for wallet.exe by Antiy-AVL the threat is flagged as - Kaspersky Threats ā€” Blocker **

We will find out why the false positive and remove it. It is probably something to do with wallet encryption (we will not remove wallet encryption!)

The xmrig results are to be expected. it is flagged as mining software, not a virus.

Right with that out of the way:

First grab the windows release binaries for the TXChangeCoin GUI and Wallet software for windows from here:

click to expand, quite a few pics tho.

Photo walkthrough Installation.

Double clicking on txchangecoin-gui.exe brings up a admin prompt, click okay.
You should now get this screen.
1%20Install_1

Click Nextā€¦ and you get this screenā€¦

2%20Install_2

Erm, okay. the text is a bit buggy. I will get around to sorting that. Probably donā€™t need this screen at all. anyway click Next and you get this.

3%20lol_licence

BEST LICENCE EVER! I hope everyone can agree to that. so click the radio button and then click Next.

This screen has a bug, Light yellow text on a white background.

4%20install_dir1
5%20install_dir2

But if you highlight the text it shows you the path. just click Next. Or change the folder then click Next.

6%20about_to_start

If you changed the installation directory in the last step it gets presented in a readable form here. Double check it, and click Start

7%20yay_done

Wow that was a lot of steps. but finally done, hurm, it says next. okay Click next.

8%20now_really_done

Not really too sure what this is about but at least the button says finish! click finish. The installer needs some work. but it does do its job. As you can see, we are trying to get the tech right then the polish.

Now we need to run the wallet and create a new address for us to mine to. It is all pretty self explanatory but yep, you guessed it. more pictures.

Initialising a wallet and syncing the blockchain

Double clicking on the desktop shortcut will bring up this screen:
So far I have only tested creating a new wallet so do that. Click CREATE

Main_Menu

It will ask you for a password, so set one.

Now you get the important information

wallet_redacted
wallet_redacted812Ɨ592 16.1 KB

I have hidden the view key, the mining address and mnemonic. You should type the seed words on a bit of paper or click the copy button and paste into a text editor so you can restore your wallet if the need should arise.

Click open wallet

Wallet_opened
Wallet_opened812Ɨ632 13 KB

You can see the orange bar at the bottom indicating that it is syncing. Standard stuff in here. Will go into more detail later. To get the primary mining address click Receive then you can click the copy icon and it will copy your address to the clipboard - paste this into notepad for later.

synced
synced812Ɨ632 12 KB

once syned the bar goes green.

Great, we are ready

Now we have an address we can start mining on the pool and getting some coins and testing different setups of your hardware, and get real world stats. see my previous post for the 24hr mining average using the ubuntu install - as seen by the pool.

lets grab the newly compiled windows version of xmrig with support for RX/TEST (this is based off xmr v2.99 I have yet to get around to making config files for this so we will create a batchfile and set the parameters via the command line.

Download the binary [1]

  • https://github.com/txchangecoin-project/xmrig/releases/download/v2.99.1/window-xmrig-64.zip
  • Unzip it somewhere.
  • Navigate to that folder with windows explorer.
  • Open notepad
  • add this two lines filling out your details. marked with <> tags. notice the --threads= option at the end. Experiment with this. The threads parameter is the one discussed in previous posts. This is the actual mining threads. so for my ryzen it would be ~6 see the ubuntu post for more details.
xmrig.exe -a rx/test -o stratum+tcp://pools.txchange.online:4444 --user=<YOUR_MINING_ADDRESS> -pass=<YOUR_WORKER_NAME> -k -r 5 --asm=AUTO --donate-level=1  --print-time=60 --threads=<THREADS>
pause

Save this file as mine.bat. then you should have a screen similar to this.

image

mine_folder
mine_folder1310Ɨ469 28.5 KB

donā€™t forget to enable largepages!

Enabling largePages
  • Press start and type gpedit, this should bring up the Local Group Policy Editor
  • Windows settings ā†’ security settings ā†’ local policies ā†’ user rights assignment
  • Now scroll down to Lock Pages In Memory
  • Double click it
  • Add the user which will be doing the testing. I normally just add administrotor
  • Click check name, to make sure it is the correct name - if you sign in with an @example.com then you need to add that.
  • Reboot.
  • Dont forget if you only added LOCAL-PC/Administator you will need to run the command prompt as admin

phew. all done, reboot and we are ready to go!

Navigate back to the folder with xmrig and mine.bat

Now double click mine.bat and you should get this (this is my 2600 under exactly the same hardware config as the ubuntu usb install. I will update with pool side stats for my 24hr period tomorrow.

Mining!

mining_6t
mining_6t1472Ɨ931 61.3 KB

Or you can launch straight from the terminal by navigating to the folder containing the xmrig you just downloaded and run

xmrig.exe -a rx/test -o stratum+tcp://pools.txchange.online:4444 --user=<YOUR_MINING_ADDRESS> -pass=<YOUR_WORKER_NAME> -k -r 5 --asm=AUTO --donate-level=1  --print-time=60 --threads=<THREADS>

Now you can get a baseline and start playing with threads, ram timings and all the other stuff that is easy to do in windows with software, but much harder in Linux unless you can do it via the bios.

check you stats for the pool here

[1] The sourcecode is available in the same folder. - https://github.com/txchangecoin-project/xmrig/releases/download/v2.99.1/

16

Massive reorg of OP, put laptop results at the top.
Added 24hr Ryzen graph to the ubuntu post.
Added mining with windows binaries tutorial.

Please ask any questions here. If you have problems with the instructions it is probably my fault or a bug. I will be looking at changing the installer. and most of the text. However the wallet testing is what I want to do more.

So get an address either via the ubuntu way or the windows binaries. and I will send you some coins.

This is just the start.

I know this is a zcash forum and we expect to have a pretty bloody cool announcement this week. we just need to get the code working first. - realistically this is a dev team of 1 + me. lol. nice one @txchangecoin-project and welcome to the forums! we are very pleased to have you.

They are a person of few words, so I do most of the talking. - but they are behind 99% of all the code adaptations, etc.

maybe if @ChileBob gets time he could set up a pool for this too. so there is a choice. that would be amazing.

17

Update to XMRIG.

[NUMA does not apply to desktops only server hardware]

For those wanting to check out the latest bleeding edge releases of xmrig, you can use the beta versions and as the algo rather than use rx/txx you can use rx/0 (that is a zero not capital O)

UPDATE: if using xmrig-2.99.5-beta use rx/test if using a previous beta stick to rx/0 - changed link to be just the beta releases page rather than a specific version.

I think this came in around the same time as rx/wow. but idk. I assume the developer did Linux releases to keep everything in one place and maintain backward compatibility. Or maybe legal stuff.

I have only checked this in 2.99.1 and 2.99.3. YMMV with any other version. From 2.99.5 onwards use rx/test

Anyway if you want to use the v2.99.5-beta

Which does have NUMA support, so therefore server support. Although the numa is pretty crappy in its base form, it has potential and certainly means most people wont have to worry about it. (only tested on one type of amd cpu on Linux)

So if you have some old server hardware laying about you can use a command like

xmrig.exe -a rx/test -o stratum+tcp://pools.txchange.online:4444 --user=<YOUR_MINING_ADDRESS> -pass=<YOUR_WORKER_NAME> -k -r 5 --asm=AUTO --donate-level=1  --print-time=60 --threads=<THREADS>

I get exactly the same hashrates from holding one dataset in quad channel with 32 cores accessing it as I do to holding 4 sets of the 2.5gb dataset. I really donā€™t know what to make of it. I have done a lot of NUMA stuff in the past 3 weeks. It seems that 90% of the info out there is misunderstood and the 10% that is right is written so oddly it doesnā€™t mean what you think it would mean.

I am currently writing a proper numa allocator. but I donā€™t want to go into too much detail.
Here is some essential reading for those who care about optimisation and potential asic/fpga development.

Start there, then we can move on to different cache layouts, and how microcode works. you can use microcode to ā€œoverclockā€ you cache, or redefine instructions (within limits, you cant change silicon with software)

Anyway I am getting off topic. Just wanted to let people know you donā€™t have to trust the binaries release by myself or TXChangeCoin. You can use the xmrig GitHub beta versions (I am not sure when this feature came in, but im guessing it is when TX stopped making builds for it, so maybe 2 weeks ago.)

Go mine some coins! try the new beta version released by xmrig on your NUMA aware server hardware.

In Linux you need to add 1250 largepages per numa node. so if you have 4 nodes it would be

sudo sysctl -w vm.nr_hugepages=5000

Enjoy.

1 Like
18

The new version is way more friendly to my vps, like ~+50%. The technicals are still a bit above me, but you both seem super dedicated. Interesting, nice work! :slight_smile:

image
image748Ɨ395 43.4 KB

1 Like
19

Here is the official TXChangeCoin position on beta release
If you would like to checkout the beta releases, they will work see below:

beta releases working with default RandomX parameters

Download the release you want to try out from XMRIGā€™s GitHub (the beta I recommend is v2.99.3+ for its NUMA support) and follow these instructions.

In order to use the beta release you need to just change one parameter
from

./xmrig -a rx/txx <rest of stuff>

for 2.99.5-beta and onwards

./xmrig -a rx/test <rest of stuff>

or pre 2.99.5-beta (2.99.3/4)

./xmrig -a rx/0 <rest of stuff>

If you ever get this error

It means you are using the wrong algo with the wrong miner switch from rx/0 to rx/txx or vice versa.

Thanks. It is really fun to do. sure it isnā€™t polished but it is fun. Glad you are liking it too.

(the main hashrate increase was due to xmrig people. implementing numa. before to get hashrates like that you would have had to used a line like)

numactl --cpunodebind=x,x,x,x --membind=x,x ./xmrig ā€¦. on Linux. not sure about windows.

To solo mine with NUMA awareness.

Only the daemon needs to be launched with NUMA awareness. There is a lot more to this topic, but this should work for everyone and give as good if not better results that XMRIG.

It also only requires 1250 large pages, rather than 1200 per node as XMRIG and the RandomX git hub suggest. (clue for those inclined numa nodes are not channels, you have to work that bit out yourself and depends heavily on server topology, the OS might give you channels but it is more likely to give you banks, from my testing on my hardware anyway.)

numactl --cpunodebind=all --membind=all ./txchangecoind

Then mine from the wallet-cli or daemon.

Just so you know, because of the difficulty and your hashrate when you see

99% certainty you found that block :smiley: so you got like 6 blocks in that screenshot.

2 Likes
20

And here we goā€¦

http://xmr.noctism.com/

Okay, last call for any help with configuration of server or consumer hardware.

I am pretty familiar with AMD and Intel (desktop and server) ram requirements, etc. There are a number of small things you can do to specific processors/ram configs to help gain those extra hashes or drop those watts.

DDR3 can significantly be improved with custom XMP profiles. (your normal SPD JDEC profiles are locked, but most SPD XMP profiles for DDR3 are blank so can be written to)

You if you old server bios doesnā€™t support XMP you can normally find a tool and write your own SPD memory timings then use the AMD Overdrive tool, or the Intel thingy, (I cant find it, it is installed here somewhere) but both AMD and Intel offer a tool to enable memory XMP timings/frequencies from within windows.

SPD changes are only for advanced users who understand what the timings do and what needs to be set as what.

For Linux this is a more advanced process, but again can be done from within the OS.

1 Like
21

so, whatā€™s the verdict on randomX, @mistfpga? decent amount of time has passed since deployment. looks like randomX is holding up fairly well.

image
image750Ɨ418 129 KB

2 Likes
22

Yeah, seems to work. Is there anything specific you wanted to ask?
Some general observations.

There are some future issues they may face. I dont think it is the answer unfortunately. I dont think the spread of CPU capabilities is reasonable, with high end server equipment performing significantly faster with a better w/h ratio too. So whilst it might have achieved ASIC resistance, has it achieved decentralisation? which is one of the main goals of asic resistance.

I think is not having the desired effect of allowing ā€œsmall minersā€ to compete - for example my vegas on eth make more per watt than my 3700xā€™s on xmr. There are some good advancement in single board computing this year hopefully it still gets released, which, depending on price point might change the game a bit.

So the main issue I can see is density, it just simply isnt feasible to get the required density for me in my own Epyc server hardware - and server hardware doesnā€™t hold resale. I would liken it to ā€œWorkstation GPUā€™sā€ having an advantage to mining over ā€œGaming cardsā€. That mixed with intel having to do ā€œsomethingā€ means we could end up with another AMD shortage/dependence, which is a concern to me if intels ā€œsomethingā€ doesnt work out. (it doenst look like it is going too)

That being said, it did seem it was turning around, but I havenā€™t looked at any of the updates since Jan, I think. I can recheck this info and see if it is still accurate. there are new chips out from AMD, new boards, chipsets, etc.

Let me know if there is anything else I can help you with :slight_smile:

1 Like
23

Iā€™m more than sure that a limited number of people have ASICs for Monero.

2 Likes
24

Do you or anyone else have any evidence to support this claim? I see you liked this, @zooko.

I reached out to artkor (@RuZcash) on Twitter and they said they have no evidence, but Iā€™d like to address this on forum as well.

Iā€™m a supporter of both Zcash and Monero, and I hold both. Itā€™s ironic that unsubstantiated FUD is being spread about Monero in a thread about addressing the FUD around Zcash.