so is 9135 (reduce disk writes) best tested on a running daemon or a bootstrapping daemon

well, a fresh-sync daemon

<system> file mosqueedit.mp4 too big to download (6249952 > allowed size: 1000000)

<m​osqueshooter:matrix.org> mosqueedit.mp4

ive sucessfully natively build monero-wallet-cli + monerod for s390x (IBM Z10 cpu arch)

cross compilation i couldn't get working because of protobuf n frens

but it natively compiles

<r​brunner7:monero.social> Oh wow, cool.

390, that'd be big endian ?

<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?

m-relay: s390x

m-relay: i added s390x support to nixos and I can build rust (rustc cargo) natively as well as cross compile it

the rust project does provide a bootstrap package

<r​brunner7:monero.social> ("m-relay" is the name of the Matrix-to-IRC bridge, my username is 'rbrunner7'.)

1.79.0 which i use to bootstrap build 1.80.0

sorry was a reflex

<TAB>

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)

this contains monerod

as well as monero-wallet-cli

if someone wants to test a specific thing

<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

the issue is that LLVM can't deal with the lay opcode/instruction

this means its actually not s390x but Z10 i have to set via gcc.arch

like -march=z10

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

so yes technically seen it runs on Z10 not s390x meaning no pre 2008 mainframes

its sort of like x86 optimisations . setting march to sth using avx512 ofc won't run on your i5 4th gen or sth

Does it sync the chain ?

deamon claims to at least have figure out its behind

<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?

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]

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

same seems to be the case for rust

<r​brunner7:monero.social> Interesting proof of concept in any case. For those 10 mainframes in total scattered over the world :)

i will try sending something to it

It's good that big endian gets tested

at least s390x isn't 31 bit anymore

(yes 31 not 32)

s390 used to be at least some models

<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.

good idea

daemon claims to have received a little over 800 blocks on testnet so far

as in monerod --testnet

im running this on KVM on IBM's infrastructure they "donated" to me because this server also does releases

it seems to have issues finding peers

it found some just not a lot, maybe the virtio network emulation plus IBM's restrictive firewall cause issues

i will crank up the debug output and try to disable the firewall

after some tweaks it now seems faster but still rather slow

6200 blocks now

pst.moe/paste/eyylxd

pst.moe/paste/omiebh (here is my firewall config along with the settings i provided to the daemon)

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

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

anyone know which github issue/feature this is referring to? x.com/xenumonero/status/1833638305226752183

rbrunner: i set out_peers to 200

seems like it wont go over 13 nodes though

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.

Monero testnet is a pretty small corner in the vast cryptocurrency universe :)

<j​effro256:monero.social> geonic: monero-project/monero #8996

<j​babb:cypherstack.com> geonic, maybe [vtnerd's 8996](monero-project/monero #8996)?

<j​babb:cypherstack.com> ah, thanks jeffro.

how much benefit would there be to running this in a ramfs?

tx!

<3​21bob321:monero.social> I assume this is mtls?

<j​effro256:monero.social> mtls? no metals here, just code

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

community.xmr.to/faucet/testnet doesn't seem to work

<j​effro256:monero.social> LMDB under good conditions and an SSD shouldn't be *that* much slower than a RamFS, theoretically

<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

<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

<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

<3​21bob321:monero.social> cloudflare.com/learning/access-management/what-is-mutual-tls

<p​lowsof:matrix.org> flandre you can mine some testnet coins relatively quickly with 1 core. sent you 1txmr though community.rino.io/faucet/testnet

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

<j​effro256:monero.social> I don't know how well LMDB performs on KVM though

<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. en.wikipedia.org/wiki/Trust_on_first_use

<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

jeffro256 what may also play a role is that its not using a s390x specific disk addressing scheme developped by ibm

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

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