which mrmsr for opteron?

I see servethehome already has some randomx discussion forums.servethehome.com/index.php?t…o-changed-to-the-randomx-algo.26589

gingeropolous: who knows if the opteron even had an aggressive prefetcher to disable in the first place

AMD tended to lag behind on that compared to Intel

in either case the prefetchers are designed to recognize repetitive access patterns. a simple orefetcher may only recognize purely sequential accesses.

if it doesn't recognize the access pattern, it goes inactive

for a highly random access pattern like randomX, it ought to deactivate itself

I guess Bulldozer generation was improved realworldtech.com/bulldozer/9

oh here you go amd.com/en/support/tech-docs

Volume 2: System Programming, Appendix A

has listing of all MSRs

well, not all. nothing about prefetchers

Maybe you'll find it in the BIOS and Kernel Dev's GUide for your processor family

this bios is useless.

i'll be happy with 2.5 kh/s per 10 year old processor

total miners 28316

oh look. MoneroV lives! In a Frankenstein-meets-living-dead sort of way. And guess what, they are moving to RandomV - 'a derivative' of RandomX - monerov.online/MoneroV-Swap.pdf

RandomV = RandomX, I checked their changes

They only changed ArgonSalt parameter

That would be my assumption. You get a notification when it gets forked on github?

No, I found them in twitter when I looked for RandomX hashtag

Lol

I'm still waiting for them to blow me away with their mimblewimble implementation

Hmm, people are reporting both increased hashrate _and_ lower power after MSR mode, nice!

I wonder if Arweave will work your optimizations in

<wowario> lol, it is seb heading up MoneroV Reloaded

who is seb?

Antony is the most active TG user in their group

<wowario> a shady multi-shitcoin pool operator

I'm torn. I kind of feel pity for people having put money into XMV, but on the other hand it is such an obvious scam that I also kind of don't ...

ugh. how do we do that power calculation for nethash

850 million hashes per second * 50 watts per hash per second / 60 minutes = MWh?

50W per hash is insanely bad

my 3700x is around 100h/w

7700h/s @ 77W total package draw

stock Ryzen is 50 H/J, I would't say insanely bad

please read again.

50W per hash, not 50 hash per W

yeah, gingeropolous now you know the problem with your formula

fort3hlulz: package power is a useless metric

What's a more useful metric? W at the wall?

Haven't captured that yet

yes

I've just been looking at tuning CPU/RAM variables to up efficiency (but haven't implemented any changes yet)

So just using package power as a guide to efficiency of the CPU itself

ok, so 850e6 hashes/second * 1 joule / 50 hashes = 17 mega joule/sec = 17 MW

yes, sounds about right

was thinking earlier today, if we wrap randomx-benchmark with perf counter monitoring, it would be quite an excellent CPU+memory benchmark

e.g. a simple wrapper script that runs a couple times while monitoring cache hit rates, branch rates, etc.

should be simple with linux `perf`

and send shares to the dev fund? :P

heh

17.9 kh/s on 3950X reddit.com/r/MoneroMining/comments/…or_ryzen_on_windows_9100_hs/fao4fyb

So it's almost 9000 h/s per memory channel

no mention of memory timings?

from his earlier posts

Ryzen 3950x @4GHz with 32GB memory @ 3600MHz timings 15-14-14-14-32-2T (as tight as I could get)

and he was at 15.45 kh/s when he posted it 12 days ago

4.4GHz CPU sheesh

y'think he could sustain that for over 24 hours?

+15.8% on his system (same 4 GHz clock)

no, he runs at 4 GHz now

ah ok

and the most important thing: power?

it shouldn't be a lot at 4 GHz

he posted imgur.com/a/9nHQDkO yesterday - it shows PPT "61% of 200W", so package power 122W

but it was 3.875 GHz

hello, I have been lurking the channel using monerologs.net but I'm the guy who posted to reddit with a nickname of mmrdx

have you got measurements of power at the wall?

my memory timings have been improved from the previous post to 14-14-14-14-28, the single rank b-die 3200 fast preset using dram calculator but applied to dual rank 3600

hello mortti

dual rank 3600 @ 14-14-14-28? This is insane

very nice memory timings indeed

yeah, it took 1.45v to get it stable

Next thing is to lurk SuperPi benchers' forums and get an idea how they run 4000 @ 12-12-12-... :D

4000 @ 12 now *that* sounds insane

I have lot of stuff drawing power on this workstation but at 3.85GHz I measured 270W at the socket

puts it close to around 60H/W. sacrificed a lot of efficiency for that rate

there is two radeon vegas, 8 fans, water cooling pump, etc. attached to this rig

but I agree, efficiency is best at 3.6GHz or so

hyc techpowerup.com/forums/threads/shar…rk-here.186338/page-25#post-3515562

3750 MHz 12-11-11-28 1.8V

I was also able squeeze 5200H/s from sandy bridge xeon 1680v2 @4GHz with ddr3 :)

total miners 28601

15 kh/s at < 200W: bitcointalk.org/index.php?topic=5203616.msg53337979#msg53337979

What is the source of these numbers in RandomX/README.md: "* DDR4 memory is limited to about 4000-6000 H/s per channel"? How can i reproduce it?

These are old numbers. It's over 9000 h/s per channel now.

The question is about the source and how to reproduce them?

I suppose it wasn't just measurement in real life experiments.

I saw it somewhere. Finally, found it in RandomX/doc/design.md.

The formula is : 1 second / ( DRAM single bank read latency 40 nanosecond) / (16384 reads from dataset / 1 hash) * (banks in 1 raw module 8) = 1 / 40e-9 / 16384 * 8 ~= 12207 H/s

banks in 1 RAM module *

So it isn't 6000 even theoretically.

cohcho: you are wrong about 8 banks per module

Let me check doc about any real world ram again

it's bank GROUPS, not banks

DDR3 has only 1 bank group per channel

DDR4 has 2-4

it doesn't matter how many banks the group has because each group shares the same control circuitry, so there can be only 1 pending read per group

"The DDR4 architecture is an 8n prefetch with two or four selectable bank groups. This design will permit the DDR4 memory devices to have separate activation, read, write or refresh operations underway in each unique bank group."

I still need some proof that this fundamental access latency limit 50ns is unbreakable for real applications, rereading this paper : prof.icc.skku.ac.kr/~jaewlee/pubs/isca13_charm.pdf

as you can see, it's not a hard limit, it can be improved with tighter memory timings

but there IS a limit

Intel CPUs can have DRAM latency as low as 40 ns

One thing keeps me wondering... With MSR mod everyon get 5% or more speed increase AND power reduction of ~5 watts

So what's the actual power spent on calculations and what's the power spent on memory access/unrelated stuff?

Did you unset the "NSA_BACKGROUND_MONITORING" bit ? :)

maybe, all changed bits are undocumented for Ryzens :D

or was it just hardware prefetchers that worked all the time, consuming power to reduce hashrate :D

IIRC I measured something like 10+ watts just from memory accesses

you can benchmark it by removing dataset accesses

now the next thing is to find MSR to turn off branch prediction, right?

I'm sure they keep it hidden somewhere...

it's not necessary to disable it

it would make sense only if we had many 50/50 branches

anyways, hopefully the next gen CPUs will have a "RandomX" MSR

:P

Well, BIOS manufactures can add it to their "Performance bias" options list

They have it for Geekbench/Cinebench

and they have NDA docs to optimize it further

I can already see "mining BIOS" beta versions

Hmm. That'd be an idea. Ask them "what is the set of MSR values that maximizes hash/watt". They don't have to document stuff, and their CPUs look better. Though I suppose the values could be pretty exact-cpu-version dependent.

as far as I can see, AMD tries to keep their MSR internals consistent within the same CPU family

the description of the prefetchers says it looks tries to detect strided access patterns

the big change was between Bulldozer and Ryzen family

would assume when it detects no such pattern, it does nothing.

working prefetcher consumes power and trigger sometimes, doing unneeded memory requests

but if toggling the MSR affects it so much, that implies either that it's seeing false access patterns in RandomX's accesses, or it's prefetching all the time even when it doesn't know what to prefetch

so lower hashrate and higher power

seems like quite a high power cost.

for what is essentially just maintaining a list of addresses

address offsets.

I think the prefetchers are pretty dumb, they probably load at least one cache lines directly after the one read from the dataset

it's even called "stream prefetcher"

hm yeah that'd make more sense

that would have the effect of doubling the bandwidth usage and slightly increasing the latency, which could account for the 5% perf and 5W power diff

Overall it makes sense. I have the analagous setting in LMDB to disable OS prefetching when datasets are larger than RAM

by default, when the kernel is forced to read a page of data, it prefetches 16 pages at a time. if RAM is full, the extra pages may evict useful data from cache and bring in useless data.

so as a rule, prefetch is a good idea for sequential access patterns, and horrible otherwise.

Is it possible to write randomx dataset into filesystem file and open read only shared mmap with restriction 2GiB only?

for devices that don't have 2GiB + 80MiB of free RAM?

possible, yes. performance will suck.

I need exact numbers comparing to cache only

It should be better but how much

I don't know

you should be able to find a suitable device for testing on

page faults will take at least 30ms for a typical HDD

How to limit mmap size in linux?

you don't need to limit mmap size, you're going to mmap exactly the amount of RAM you would normally require.

the trick is to simply eat up the rest of RAM until you've shrunk free RAM down to the desired size.

I've asked since process being killed after the frist try to initialize dataset.

you can do this just by writing a program that mmaps the rest of RAM privately, and mlocks it all

do you have any swap space configured?

No

note that adding sufficient swap should give you the same performance as a read-only mmap'd file in this use case

With c++ based implementation of randomx It is hard to free ram for other things except dataset

I agree with you about not using c++

you don't need to alter the randomx code at all

anyway, I have tested on my ARM64 boxes with only 2GB of RAM, and swap enabled on a microSD card.

it is quite painfully slow.

There is no way to setup swap

yeah, you will get about 0.01 H/s

I think gingeropolous tested it before

it's much faster to use the 256 MB mode

Another implementation is required in order have hybrid dataset : partially in-memory, partially recomputed on the fly

But it requires some time to implement

Yeah I guess that could be worthwhile. for 50% of dataset, rest using 256MB cache.

for the accesses that land in the dataset memory, you win.

the benefit of this will be smaller than you think

50% dataset will be not even 2 times faster than the light mode

50% dataset still means a 4x slowdown

replace 50% with configurable parameter that should be set in runtime to free ram

It will be in practise close to 2GiB

not 50%

4x slowdown is still faster than light mode 6x slowdown

I've tested single core performance with MSR mod and got 1287 h/s, so 10296 h/s is possible without memory bottleneck

which means real-life 9670 h/s is still 6% slower than it can do in theory

I don't like the fact that these upper boundary limits is changing faster than I expect

why does it matter to you?

it's only a theoretical limit, I don't think everything will scale linearly to all cores