looks like 100 Mh/s unknown

i wonder if, for network health reasons, nodes could broadcast their solo mining status.

like, a node just sends along with its peer info "mining at 2200 h/s"

i guess it could be gamed, unless the message itself was signed with PoW

nevermind about that 100 mh/s unknown comment

We can forget about MoneroV yet again: twitter.com/monerovofficial/status/1209509550501482496

XMRig will remove support :D

yet another example of why specialized hardware is still a shitshow: cointainer.life/2019/12/25/is-xilinx-the-new-bad-boy-in-crypto

"Rumor mill has it that the bare cards were to be sold at the $1,000 price point and around the $1,200 price point with a thermal solution equipped. However, don’t expect these cards to be available to the public. No sir. If you want to be able to buy these cards, your MOQ is in the thousands. This is IP theft that has then been rebundled only for whales while all of us who have already bought product from SQRL can go fuq ourselve

s based on Xilinx‘s actions."

sech1: officially they say RandomV (lol) is too botnet-friendly

maybe xilinx will kill off the remaining PoW altcoins

with algos different from randomx?

these new FPGAs with 8 GB HBM memory can mine almost everything.

probably except X22/X25 and similar stuff which doesn't fit on the chip

and of course RandomX/ProgPoW

I wonder what protocol they're using to talk to the card, it says non-PCIe compliant

I suppose if you take shortcuts with the protocol, you could put a bunch of CPUs on a PCIe card too

Fingers crossed, it looks like I've found a proper solution for first gen Ryzens with opcache bug.

Mining on my faulty Ryzen with opcache on now.

Hashrate is a bit higher and power is 2-3 watts less than with opcache off.

hyc, Why don't you have auto reconnect on that irc client highlandsun.com/hyc/monero-pow.txt?

This link works monerologs.net/monero-pow/20191225/raw if somebody needed.

sech1: is it some special sequence of instructions that doesn't crash?

I still don't know what crashes exactly, but I found how to recover from the crash

What's interesting, each mining thread crashes only once and becomes rock stable after that

so I have 8 threads -> 8 random crashes, 1 in each thread -> stable

all crashes usually happen within first minute

Weird, but it works now

Oh right, forgot to tell that I could get up to 5420 h/s on R7 1700 running at 3.6 GHz, that's a record. Memory is running at 2666 MHz 14-16-16-35, but it's 4 dual-rank modules (4x16 GB), so many independent memory ranks really help.

Is it huge population of miners with 1st gen Ryzen?

( broken_question.delete() )

A lot

did AMD publish any details about the crash?

I couldn't find anything

sech1, thanks for reply

There's a lot of issues in xmrig github related to this crash

tevador I couldn't find any hw errata from AMD

whether memory timings configurations should be done before OS by UEFI/BIOS or can be configured after too?

memory timings? AFAIK they're configured by BIOS during memory controller initialization

sech1: does it crash when jmping across a page boundary?

there must be something special about the places where it crashes

it crashes after CBRANCH triggers

sometimes

Zen triggers between opcache and L1 code cache at branch target (i.e. after some jump instruction triggers)

so it crashes on a backward jump, that's strange

should be already in the uop cache

the branch target

"should be"

maybe it's not or it's some garbage there

"The op cache is modal and the machine can only transition between instruction cache mode (IC

mode) and op cache mode (OC mode) at certain points. The machine can only transition from IC

mode to OC mode at a branch target. Once in OC mode, the machine will generally remain in this

mode until there is a fetch address for which there is no corresponding OC entry (a miss)."

so any jump/call instruction can trigger it

so it must be opposite, it crashes when transitioning IC -> OC

yes

maybe some combination of instructions at the branch target triggers it, but it's random

benchmark crashes in different places

but it's strange that it seems to crash only once

some bit somewhere flips and it's fixed

so you fixed it with an exception handler?

almost

exception handling doesn't work with RandomX JIT

for whatever reason

I had to do a bunch of workarounds

maybe it fixes after the first crash because JIT uses the same place in memory every time

At least try...catch and even __try...__except doesn't work in Visual Studio

their exception handling logic works only with known code locations, it can't see JIT code

chocho: the client auto-reconnects, but it creates a new logfile every time. so I have to rename it into place each time

anyway, since the file is there, not much is lost. just whatever happened while it got disconnected