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.
- Pool and site have moved here
- Pool site https://blocks.txxcoin.tech/
- Explorer https://explorer.txxcoin.tech/
- Site not up, but an api is⦠idk. the api seems a bit flaky https://apix.txxcoin.tech/
- Please note they are self signed certs so meh. We will get around to it. I am looking at setting up some EU hosting for my projects, which will have proper certs.
- to mine you can use the latest xmrig 3.1.0 from Releases Ā· xmrig/xmrig Ā· GitHub
- use
./xmrig -a rx/text <rest of stuff>
UPDATE 11/August
- updated the command for running default RandomX parameters on XMRIG v 2.99.5-beta
UPDATE 1/August
- added clarity about BETA miner support to this update and the last posts.
- added solo mining with numa awareness to this post:
- An Introdction to RandomX, Benchmarking tool and pool/solo mining - #19 by mistfpga
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
- Windows Binaries and how to use them to pool mine.
An Introdction to RandomX, Benchmarking tool and pool/solo mining - #15 by mistfpga - Ryzen 2600 24hr poolside hashrate image added to the ubuntu post
- moved i7 RandomX benchmarking results to top of this post.
UPDATE 28/July
- POOL and SOLO guide here with Ryzen 2600 basic results.- An Introdction to RandomX, Benchmarking tool and pool/solo mining - #14 by mistfpga
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
- testing environment and Linux USB install benchmarking.
See here - An Introdction to RandomX, Benchmarking tool and pool/solo mining - #10 by mistfpga
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
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.
- run system file checker ( sfc /scannow ) This will fix the massive cpu usage.
- reboot to apply the file fixes
- http://go.microsoft.com/fwlink/?LinkId=2085155
- then go through windows updates for a while.
- should be fixed.
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.