anyone getting one of these RISCV miners?

They "sold out"(tm) in a few seconds

you mean in bitmains website?

sigh 3,299.87

They don't say how loud it is :D

Also needs 220v service

200-240v

<h​bs:matrix.org> I am surprised by the weight

plowsof so GPU scalpers jumped on this too?

iBet these "resellers" just bought the whole batch

that'd be most likely

hell they may have been preordered, which is why it "sold out in seconds"

so Bitmain's price has never been the real price

When are they shipping? Would be interesting if someone could post some pics of the board without heatsinks.

word wish I could get one just to tear it apart :P

tevador, mineshop.eu says "In stock shipping in 7-10 days"

"Available Sept 10 – 30th sept 2023"

but god knows they might be taking pre orders to then order or smth

"naked board without heatsinks" lol, sounds like porn

someone will eventually publish the pictures, with all part numbers

It's probably something based on XuanTie C910.

probably, but it has to be heavily customized for RandomX

XuanTie C910 doesn't have crypto instructions (?)

I don't think it would be worth it to design a custom chip just for Monero. It's most likely a stock C910 with 4 cores/8 MB of cache per cluster.

At most they could have added a coprocessor for the scratchpad expansion, but most likely they just dedicated a few cores for that.

They probably have multiple chips on the board. My nonce analysis showed 52 mining threads in each of the 10 horizontal lines, so around 520 mining cores per device

so probably 16x4 core chips, but only 13 are active

These chips are TSMC 12nm by the way

12nm? how do you know? I think even my car radio's ARM chip is on 8nm

It's on the last page img.102.alibaba.com/1627958419409/4…9652c9412c41cb6f39b36fed1244e6e.pdf

cool thanks

<x​fedex:matrix.org> 12 nm is really a lot. I guess that if RISC-V CPUs are underdeveloped.

configs up to 8MB L2 cache. that'd be what they'd need for 4 cores

any idea what the XIE instruction extensions do?

there is also a C920 64-core chip, same instruction features

C910 is open source: github.com/T-head-Semi/openc910

yes, I already saw that T-head-Semi/openc910 #17

while looking for the XIE docs.

but doesn't seem like XIE has anything to help crypto

If they really use it "as is", the only way to nerf it is to have moooore AES :D

but AES is already like 5-8% of hash time on Ryzen

AES is too ASIC friendly

AFAIK there are no chips that support the crypto extension yet

It's possible to squeeze some AES in step 11 in github.com/tevador/RandomX/blob/mas…ter/doc/specs.md#462-loop-execution

because next come steps 1-2 with 30-50 clock cycles wait for read from L3

which is not used by anything yet

C series instruction manual:

for example, registers f0-f3 could go through a few AES round before writing them back to scratchpad

just generating ideas now

30-50 clock cycles window means we could have 8 AES rounds done on 4 registers (32 instructions in total) on each loop iteration

Assuming AES latency is 4 cycles

hyc yep, I don't see any crypto instructions

32 AES instructions per loop => 524288 additional AES instructions per hash

Right now one RandomX hash does 262144 AES instructions

so it's 3x increase on AES side, almost for free

I like it

We'd have to benchmark the impact on light mode perf.

Why light mode? Step 11 is the same in light mode

"The values of registers f0-f3 are written to the Scratchpad (L3) at address spAddr0 (64-byte aligned)."

This is where I suggest to add AES

and the L3 read delay in steps 1-2 will also be the same

AES will interleave with this L3 read delay

If it fits in L3 cache delay, it's probably fine.

also, it will improve scratchpad entropy

because f0-f3 are not totally random when we store them

The only complication is the soft AES mode, which would probably need to call a subroutine there. Currently we don't have any AES in VM code.

yes, but this subroutine would be just a bunch of AES calls, easy to write

soft AES becomes less and less relevant (for x64 and ARM)

newer RISC-V CPUs will also have it

For example, Raspberry Pi 4 doesn't have AES, so it would be impacted. But if the verification time doesn't increase by more than a few percent, it's probably fine.

IIRC soft AES mode spends around 30% of time calculating AES

so we could add 4 AES rounds per loop (16 instructions), doubling the total AES instruction count

which would mean ~50% of time for AES in soft AES mode

or 30% slowdown for CPUs without AES, if my math is right

"CPUs without AES" = "Bitmain professional miners without AES"

Raspberry Pi, I hate them. They cheaped out on crypto extensions. Literally all other SBCs have them.

also, RPi4 was released in 2019, and we're discussing tweaks for future CPUs, tweaks that will go live in 2024 (RPi4 will be 5 years old by then).

they left it out for cost reasons tbh, not everybody gets to use free instruction sets :P

Yes, but RPi4 is more like an exception, not a rule

I like this AES tweak also because it improves scratchpad entropy

What is relevant is the impact on light mode verification time for low end hardware that might be running a Monero node. We don't want to increase the hardware requirements for running a node.

I have RPi 3b+ for testing

It already takes almost a second to verify a hash (light mode + soft AES mode)

It doesn't have enough RAM to run full dataset mode

Or my memory betrays me

I remember it could do something around 20 h/s when mining

so 5 h/s per core, or 200 ms to verify a hash

so with this AES tweak, it would be 30% more - 260 ms

18:06:10 <@sech1> Yes, but RPi4 is more like an exception, not a rule => yeah ofc. i got all generations of rpis i can test with, rpi4 is my home node. can test it and report

welp we don't have aarch xmrig handy, got it and testing now

> miner speed 10s/60s/15m 102.5 n/a n/a H/s max 103.0 H/s

qu.ax/bDmY.png well now it's worse than that, i think i should shutdown monerod

yeah barely 90h/s qu.ax/Dko.png

You need to enable huge pages

tried with sudo, let me check other options

i think this needs a kernel recompile

it should be more than 100 h/s with huge pages

so riscv CPUs are unwanted in the monero mining ecosystem?