so it distributed the hashrate?

there's no reason to assume a single team attacked all of the supercomputers

but sure, maybe they distributed their hashrate to make it less noticeable

that would have been the smart thing to do

huh. were different exploits used? i thought i read the article... perhaps ill read again

"evidence like similar malware file names and network indicators suggests this might be the same threat actor."

this wasn't a professional botnet operator. it sounds more like some friend-of-a-friend copied down passwords to shared ssh accounts

and they probably knew they would be detected soon

wonder if we saw any reorgs during this period

to the noncesesnece lab

heh

UpMem spells the death of memory-hard algorithms upmem.com/technology

they just emailed me, with their 2020 product brochure

8GB DIMM with 128 embedded CPU cores @ 500MHz each

would this also be interesting for randomx?

only 32bit CPUs, not great for number crunching, but will eat up data-intensive algos

I think RandomX could be ported to it, as an experiment. no idea what to expect.

what even is this?

each CPU can only address 64MB of memory, so we would have to subdivide the argon2 cache even further

C programmable fpga?

lol

custom CPU cores co-resident with RAM

I think it's more applicable to database/search workloads

e.g. my day job ;)

so you would put one of those into a server

but it would probably eat ProgPow ...

yeah they have a few sample system configs in the PDF

intel server with 20 of these modules installed

would have 2.56TB/s bandwidth for their processing algos

moving your computes out to where RAM lives is an excellent approach

for things that parallelize well, like GPU-friendly algos, this will devour them

would be interesting to see hashrate comparions for randomx and progpow and other GPU algos

but yea probably more interesting for non mining applications

<hyc> only 32bit CPUs, not great for number crunching, but will eat up data-intensive algos >>> sure, now. Surely as time progresses they'll get to 64bit and increase the 64 MB memory access etc

yeah, I'd expect so

right, so its only a matter of time ... well, does this pose the same kind of threat as ASICs?

but if thats the future of compute, then everyone will be doing it

yeah it doesn't seem to have the exclusivity problem

but it seems these will only drop-in to server DIMM slots (it's compatible with RDIMMs)

Hello, im the op of xmrpow.de. I found out that other pools like supportxmr etc are having some small advantage concerning getting new blocks. For example: supportxmr is able to send jobs to its miners 2 sec earlier than xmrpow.de does. Although im closer to my own server when i tested that. I have seen worse but it's still improvable. Therefore I asked what supportxmr admin does to achieve that. He told me that he is operatin

f nodes and these nodes do have a special messaging queue which they use to communicate with each other. Because we are a small pool we can not afford to host monerod in all regions of the world. Do you have some idea how I could solve the problem? Are there some special monerod optimizations?

xmrpow if you can't afford nodes around the world with custom protocols for block propagation, did you at least try to have more peers connected to your node?

@sech1 do you know the auto value for in and out peers or is it dynamic?

it's 8 in 8 out by default

you can ramp up these numbers via command line

But it cant be done during operation right? Might have to restart for that...

in_peers is unlimited by default

out_peers 8

I think in is not limited by default.

Ok but if in is unlimited it cant be my problem

It can be done from the monerod console (out_peers/in_peers)

But i can t set in out peers after launching monerod?

Or is there some interactive mode?

< moneromooo> It can be done from the monerod console (out_peers/in_peers)

yes, in_peers command works, and is unlimited by default

so that's probably not an issue here

maybe you could examine your current peerlist, ping each of them to tally up roundtrip latency, and disconnect from the slowest ones

A bit sucky for those people though.

why?

just do it for the outbound conns, then your monerod wil ltry to find new peers

If people start disconnecting people with low ping, people with shitty connections will end up being unable to get onto the network.

Ah, that might work yes.

if the connection is that slow, it's probably geographically distant. chances are good there's a closer node to talk to

Yes, but OTOH doing this means txes will be even slower to propagate overall.

(since they'll go through more hops to reach everywhere)

(that's a conjecture)

@hyc im trying it

I guess. each hop will be faster, but the number of added hops will probably cancel that

Has to, since there's downtime (as sech1 said, at least the PoW check delay)

yeah, true

@moneromoo can you pipe the output of print_pl_stats into a file?

sry print_pl

Why ?

Oh, you're asking whether it's possible. Not without copy/paste.

It'll be in the log file, bit with timestamp prefixes.

(which can be sedded out)

Hmm. Actually might not be in the log, I think it's a direct console write...

@moneromoo i want to examine my peer list

and copy paste does not work that well in my ssh session

is it normal that status does show 0 in?

utils/python-rpc/console.py 18081

Does that mean unlimited?

L = daemon.get_peer_list()

Yes.

ok

Wait

0 in means noone can connect to your daemon.

0 in the in_peers command means unlimited.

Or is that -1 ? I forget.

i mean when i call status

Sorry. Looks like 0 means 0. -1 means unlimited. For status, 0 means 0.

So your router is not set up right or similar issue.

oh shit. there is something rly ry wrong...

im in a datacenter

@moneromoo can p2p bind ip bind to localhost?

dont tell me that it cant :)

Yes. 127.0.0.1.

thought it might be the problem for no incoming connection

are you sure?

Fairly sure.

The default is to 0.0.0.0 though, so unless you specifically set it, it won't be the reason.

i set it 127.0.0.1. Maybe i should try default?

Yes :D

:)

Keep the RPC one to 127.0.0.1 though (which is the default).

LOL

gosh, how come nobody on localhost is connecting to my node ...

sry, i know it s dumb but shit happens ;)

FWIW, setting binding to 127.0.0.1 when first trying something is usually prudent :)

And, we, wrong channel, I'm just seeing. That's really #monero stuff.