11:06:50 <gingeropolous_> so is 9135 (reduce disk writes) best tested on a running daemon or a bootstrapping daemon
11:07:03 <gingeropolous_> well, a fresh-sync daemon
15:01:28 <m-relay> <system> file mosqueedit.mp4 too big to download (6249952 > allowed size: 1000000)
15:01:30 <m-relay> <m​osqueshooter:matrix.org> mosqueedit.mp4
18:47:40 <flandre> ive sucessfully natively build monero-wallet-cli + monerod for s390x (IBM Z10 cpu arch)
18:48:02 <flandre> cross compilation i couldn't get working because of protobuf n frens
18:48:07 <flandre> but it natively compiles
18:48:20 <m-relay> <r​brunner7:monero.social> Oh wow, cool.
18:49:11 <moneromooo> 390, that'd be big endian ?
18:49:27 <m-relay> <r​brunner7:monero.social> Is there already Rust for those IBM architectures, will your compilation survive the introduction of FCMP++ that needs part of the code in Rust?
18:49:31 <flandre> m-relay: s390x
18:50:07 <flandre> m-relay: i added s390x support to nixos and I can build rust (rustc cargo) natively as well as cross compile it
18:50:20 <flandre> the rust project does provide a bootstrap package
18:50:34 <m-relay> <r​brunner7:monero.social> ("m-relay" is the name of the Matrix-to-IRC bridge, my username is 'rbrunner7'.)
18:50:36 <flandre> 1.79.0 which i use to bootstrap build 1.80.0
18:50:51 <flandre> sorry was a reflex
18:50:55 <flandre> <TAB>
18:51:46 <flandre> https://github.com/bolives-hax/nixos-IBM-Z10-mainframe/releases/tag/dbg-lxc-2 (since i don't assume anyone has a mainframe you can use qemu-system-s390x just note that it will be very slow in your case)
18:51:50 <flandre> this contains monerod
18:51:56 <flandre> as well as monero-wallet-cli
18:52:14 <flandre> if someone wants to test a specific thing
18:52:21 <m-relay> <r​brunner7:monero.social> That's reassuring to hear. I do hope we won't lose any current and future platforms because of the use of Rust
18:52:41 <flandre> the issue is that LLVM can't deal with the lay opcode/instruction 
18:52:53 <flandre> this means its actually not s390x but Z10 i have to set via gcc.arch
18:53:01 <flandre> like -march=z10
18:53:39 <flandre> otherwise it won't compile, this is not just an issue for rust but also the s390x bootloader zipl which i have tried to make IBM aware off but they did tell me to buy a new mainframe
18:53:51 <flandre> https://github.com/ibm-s390-linux/s390-tools/issues/171
18:54:21 <flandre> so yes technically seen it runs on Z10 not s390x meaning no pre 2008 mainframes
18:55:12 <flandre> its sort of like x86 optimisations . setting march to sth using avx512 ofc won't run on your i5 4th gen or sth
18:55:22 <moneromooo> Does it sync the chain ?
18:56:06 <flandre> deamon claims to at least have figure out its behind
18:56:06 <m-relay> <r​brunner7:monero.social> Yeah, and in a way I would forgive them to cut the horizon at 2008. Microsoft with Windows 11 wants to cut where, CPUs not older than 2020 or what?
18:56:16 <flandre> 2024-09-12 18:56:04.870 I [103.168.43.4:18080 OUT] Sync data returned a new top block candidate: 36884 -> 3236039 [Your node is 3199155 blocks (10.3 years) behind] 
18:57:51 <flandre> they never explicitly cut it its just that they bought redhat and assume that the bootloader is build under conditions given by fedora (march=z13) so much more recent than z10 <2008> but i can get things build for z10 still but not one gen before
18:58:03 <flandre> same seems to be the case for rust
18:58:59 <m-relay> <r​brunner7:monero.social> Interesting proof of concept in any case. For those 10 mainframes in total scattered over the world :)
18:59:23 <flandre> i will try sending something to it
19:00:25 <sech1> It's good that big endian gets tested
19:00:47 <flandre> at least s390x isn't 31 bit anymore
19:00:51 <flandre> (yes 31 not 32)
19:01:03 <flandre> s390 used to be at least some models
19:01:30 <m-relay> <r​brunner7:monero.social> Maybe try to sync and use testnet first? Much, much smaller blockchain, free coins to play, and you won't annoy too much if something goes wrong.
19:02:07 <flandre> good idea
19:33:51 <flandre> daemon claims to have received a little over 800 blocks on testnet so far
19:33:56 <flandre> as in monerod --testnet
19:35:26 <flandre> im running this on KVM on IBM's infrastructure they "donated" to me because this server also does releases
19:35:47 <flandre> it seems to have issues finding peers
19:36:15 <flandre> it found some just not a lot, maybe the virtio network emulation plus IBM's restrictive firewall cause issues
19:37:27 <flandre> i will crank up the debug output and try to disable the firewall
19:40:11 <flandre> after some tweaks it now seems faster but still rather slow
19:40:23 <flandre> 6200 blocks now
19:43:50 <flandre> https://pst.moe/paste/eyylxd 
19:53:26 <flandre> https://pst.moe/paste/omiebh (here is my firewall config along with the settings i provided to the daemon) 
19:56:50 <flandre> any clue how big the testnet is? If its too big i may have to run this on the Z10 instead of the remote one IBM sponsored me but IBM's has better uplink while mine has better disk io but id have to go there and boot the iso over the support element console (builtin mainframe laptop) so id prefer to run this on ibms stuff but there the disk is small
20:09:17 <rbrunner> Testnet is not so big, I would estimate a few dozen of nodes only, maybe take that into account when judging the number of peers you reach
20:09:59 <geonic> anyone know which github issue/feature this is referring to? https://x.com/xenumonero/status/1833638305226752183
20:10:06 <flandre> rbrunner: i set out_peers to 200
20:10:30 <flandre> seems like it wont go over 13 nodes though 
20:11:13 <rbrunner> That sounds about right for a node that is not yet running for a long time, in my experience. I don't think it's something to worry. I doubt the network has 200 nodes, at all.
20:12:00 <rbrunner> Monero testnet is a pretty small corner in the vast cryptocurrency universe :)
20:13:32 <m-relay> <j​effro256:monero.social> geonic: https://github.com/monero-project/monero/pull/8996
20:14:07 <m-relay> <j​babb:cypherstack.com> geonic, maybe [vtnerd's 8996](https://github.com/monero-project/monero/pull/8996)?
20:14:35 <m-relay> <j​babb:cypherstack.com> ah, thanks jeffro.
20:15:07 <flandre> how much benefit would there be to running this in a ramfs?
20:15:08 <geonic> tx!
20:19:14 <m-relay> <3​21bob321:monero.social> I assume this is mtls?
20:20:02 <m-relay> <j​effro256:monero.social> mtls? no metals here, just code
20:20:31 <flandre> well seems like i can't get this much faster now => i will have to see tomorrow its 23:17 and i have to sleep.   If someone wants to play faucet for the testnet 9ynLJPENp7UWm3UuySaShSYyAnXXTKviCQWbDqzJb7Lpd2fbw9TndAHM9J2nfoFxcaLKYAWGFtt4RDeQGYncvLtGH6cCRwP would be cool
20:21:16 <flandre> https://community.xmr.to/faucet/testnet/ doesn't seem to work 
20:21:27 <m-relay> <j​effro256:monero.social> LMDB under good conditions and an SSD shouldn't be *that* much slower than a RamFS, theoretically
20:22:31 <m-relay> <j​effro256:monero.social> LMDB is memory mapped so if your OS does a good job caching pages with plenty of space for the buffer, and you're not doing safe sync mode, then flushes shouldn't be synchronous and reads should mostly be cache hits
20:23:24 <m-relay> <j​effro256:monero.social> There's technically lots of random reads, but they tend to be concentrated towards the front of the chain due to the decoy selection algorithm
20:24:18 <m-relay> <j​effro256:monero.social> In other words, you'll likely have more luck adding RAM and letting the OS do its thing than putting a bunch of work into making LMDB run on ramfs
20:24:57 <m-relay> <3​21bob321:monero.social> https://www.cloudflare.com/learning/access-management/what-is-mutual-tls/
20:24:59 <m-relay> <p​lowsof:matrix.org> flandre you can mine some testnet coins relatively quickly with 1 core.  sent you 1txmr though https://community.rino.io/faucet/testnet/
20:25:51 <flandre> the rhino one somehow bugged for me when i moved the daemon outside kvm and restarted it rino claimmed i was banned eventhough i only made one request
20:27:39 <m-relay> <j​effro256:monero.social> I don't know how well LMDB performs on KVM though
20:29:25 <m-relay> <j​effro256:monero.social> No the PR doesn't use a mTLS-like system since there is no root trusted certificate, it's more like TOFU IIRC. https://en.wikipedia.org/wiki/Trust_on_first_use
20:30:30 <m-relay> <j​effro256:monero.social> mTLS is useful in distributed systems applications where all participants are operated by one entity but connect over an untrusted layer, but not in p2p systems where anyone can join
20:31:57 <flandre> jeffro256 what may also play a role is that its not using a s390x specific disk addressing scheme developped by ibm
20:31:59 <flandre> https://en.wikipedia.org/wiki/Direct-access_storage_device
20:36:26 <flandre> this is being passed trough one layer of KVM which isn't under my control  and is being operated by the Marist College , i do not know how well and with what overhead that passtrough of a portion of the original storage device happens
20:41:37 <flandre> 10% now I will go to bed im pretty sure things will work as expected since if something would go wrong i assume it would have already happened in regards to the endianess but i only know tomorrow pretty much