07:08:17 looks like 100 Mh/s unknown 07:09:40 i wonder if, for network health reasons, nodes could broadcast their solo mining status. 07:09:59 like, a node just sends along with its peer info "mining at 2200 h/s" 07:10:27 i guess it could be gamed, unless the message itself was signed with PoW 07:17:58 nevermind about that 100 mh/s unknown comment 08:07:37 We can forget about MoneroV yet again: https://twitter.com/monerovofficial/status/1209509550501482496 08:07:45 XMRig will remove support :D 08:20:28 yet another example of why specialized hardware is still a shitshow: http://www.cointainer.life/2019/12/25/is-xilinx-the-new-bad-boy-in-crypto/ 08:20:51 "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 08:20:51 s based on Xilinx‘s actions." 09:05:25 sech1: officially they say RandomV (lol) is too botnet-friendly 15:12:39 maybe xilinx will kill off the remaining PoW altcoins 15:19:38 with algos different from randomx? 15:40:23 these new FPGAs with 8 GB HBM memory can mine almost everything. 15:41:34 probably except X22/X25 and similar stuff which doesn't fit on the chip 15:46:15 and of course RandomX/ProgPoW 16:38:44 I wonder what protocol they're using to talk to the card, it says non-PCIe compliant 16:41:29 I suppose if you take shortcuts with the protocol, you could put a bunch of CPUs on a PCIe card too 19:04:24 Fingers crossed, it looks like I've found a proper solution for first gen Ryzens with opcache bug. 19:04:38 Mining on my faulty Ryzen with opcache on now. 19:05:10 Hashrate is a bit higher and power is 2-3 watts less than with opcache off. 19:13:50 hyc, Why don't you have auto reconnect on that irc client http://highlandsun.com/hyc/monero-pow.txt? 19:15:51 This link works https://monerologs.net/monero-pow/20191225/raw if somebody needed. 19:44:16 sech1: is it some special sequence of instructions that doesn't crash? 19:45:11 I still don't know what crashes exactly, but I found how to recover from the crash 19:45:37 What's interesting, each mining thread crashes only once and becomes rock stable after that 19:45:53 so I have 8 threads -> 8 random crashes, 1 in each thread -> stable 19:46:52 all crashes usually happen within first minute 19:47:32 Weird, but it works now 19:56:15 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. 20:04:20 Is it huge population of miners with 1st gen Ryzen? 20:08:11 ( broken_question.delete() ) 20:21:33 A lot 20:23:26 did AMD publish any details about the crash? 20:23:31 I couldn't find anything 20:23:52 sech1, thanks for reply 20:25:10 There's a lot of issues in xmrig github related to this crash 20:25:22 tevador I couldn't find any hw errata from AMD 20:30:23 whether memory timings configurations should be done before OS by UEFI/BIOS or can be configured after too? 20:31:41 memory timings? AFAIK they're configured by BIOS during memory controller initialization 20:35:02 sech1: does it crash when jmping across a page boundary? 20:35:55 there must be something special about the places where it crashes 20:39:11 it crashes after CBRANCH triggers 20:39:15 sometimes 20:40:17 Zen triggers between opcache and L1 code cache at branch target (i.e. after some jump instruction triggers) 20:40:29 so it crashes on a backward jump, that's strange 20:40:41 should be already in the uop cache 20:40:47 the branch target 20:40:51 "should be" 20:40:58 maybe it's not or it's some garbage there 20:42:18 "The op cache is modal and the machine can only transition between instruction cache mode (IC 20:42:18 mode) and op cache mode (OC mode) at certain points. The machine can only transition from IC 20:42:18 mode to OC mode at a branch target. Once in OC mode, the machine will generally remain in this 20:42:19 mode until there is a fetch address for which there is no corresponding OC entry (a miss)." 20:42:36 so any jump/call instruction can trigger it 20:43:14 so it must be opposite, it crashes when transitioning IC -> OC 20:43:34 yes 20:44:05 maybe some combination of instructions at the branch target triggers it, but it's random 20:44:22 benchmark crashes in different places 20:45:40 but it's strange that it seems to crash only once 20:45:55 some bit somewhere flips and it's fixed 20:46:36 so you fixed it with an exception handler? 20:46:58 almost 20:47:07 exception handling doesn't work with RandomX JIT 20:47:10 for whatever reason 20:47:17 I had to do a bunch of workarounds 20:47:50 maybe it fixes after the first crash because JIT uses the same place in memory every time 20:48:38 At least try...catch and even __try...__except doesn't work in Visual Studio 20:49:12 their exception handling logic works only with known code locations, it can't see JIT code 23:30:19 chocho: the client auto-reconnects, but it creates a new logfile every time. so I have to rename it into place each time 23:32:49 anyway, since the file is there, not much is lost. just whatever happened while it got disconnected