06:28:33 <mechanic41turk[m> The pool hashrate seems to have dropped. And p2pool is now rank 6.
06:28:44 <mechanic41turk[m> Any speculations as to why this drop in hashrate of the pool?
06:29:00 <mechanic41turk[m> Kazakh XMR miners unable to reach the internet? /s
07:25:48 <inge> .network
10:33:09 <pauliouk> one of the perks of p2pool is, you couldn't really shut it down or block someone from it - there's almost always a way around any blocks
10:34:00 <pauliouk> Hmm now is the pool hashrate calculated the same way as individual hashrate? eg, the number of blocks found compared to the global hashrate?
10:40:51 <inge> hyc: if I had a machine with say .. 256GB of RAM, would lmbd keep the entire blockchain in memory?
10:42:11 <sech1> I run pruned node on a server with 64 GB RAM and it's lmdb uses only 19 GB RAM
10:42:51 <inge> wondering if it would be better to let monerod manage it, or better to move the blockchain to a ram device
10:48:05 <moneromooo> monerod maps the file, the OS decides what to keep in RAM.
10:49:01 <moneromooo> Moving the chain to a RAM device means it won't be persistent.
10:49:52 <moneromooo> You could mdb_copy regularly to disk without having to stop monerod though I guess.
11:32:17 <garth> 3.5 GH
13:16:26 <inge> moneromooo: just musing about it - could be nice as a high-performance node allowing many clients (but as you said, persistence could be an issue)
13:19:36 <hyc> always better to let the OS manage it
13:20:21 <hyc> if RAM use is less than DB size that just means nobody has requested data from the other parts of the file yet
13:20:34 <hyc> (assuming there is still free RAM in the system)
13:21:18 <hyc> you can force the entire file to get cached of course. just read it. `cp data.mdb /dev/null` will do the trick
13:21:41 <hyc> as long as nothing else wants the RAM, the DB will be 100% cached
14:01:07 <nioc> <inge> https://nitter.net/mozilla/status/1479143340159422468