pull down to refresh
I synced on an odroid m1 with debian 13 and it was much faster, at expected speed for that hardware...not a huge difference from a rpi4, it's a quad core 2.0ghz arm board.
Yeah my rk3588 is an Odroid M2 - the difference seems to be the crypto extensions.
very sad the m2 has lower nvme speed than the m1...I really like those arm boards with native nvme support, do you use orangepi also?
I don't own one of these right now, because I'm roaming. I have 4 boards on me and customs fucks with me every time, no matter what country I enter. They all end up thinking I'm just some virgin nerd tho so it's fine. lol
lol, I was thinking about buying one of those: http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/details/Orange-Pi-5-plus-32GB.html
But the debian support seems to lack
dayummm [😂]
The M2 seems to be positioned a bit odd on the board versus odroid ones, other than that, looks fine. For chipset, RK3588 is very well supported in ARM firmware [😭]
You may need to bake your own image. Basically take an ubuntu ARM, shift it 512MB to the right, then inject uboot and the firmware and fuck a bit with fdisk, to describe it correctly.
I can build an image building script for the world but I cannot test it rn. Would have to get rid of one of the boards to replace it with this, let me be pensive for a week on that.
I literally had to use archive dot org for that link! What's happening to net neutrality? Or is it net neuterality now, haha? ↩
In fact I was a bit grumpy that they focused on this versus RK3328 - which is perfect if you don't need fast storage for things that you can just run from 4GB memory. ↩
That seems a bit exhausting, if it had tow-boot support things would be easier:
https://tow-boot.org/devices/index.html
Ok, I'll wait for more concrete results before sharing anything. That Github issue is closed anyway so unlikely to get any real attention.
The block I gave as an example above contains mostly consolidation of p2sh utxo. So in this case, we're actually seeing bad performance on utxoset unbloat.
Interesting. But we wouldn't need to do this much validation if the UTXO set wasn't so bloated to begin with, right? So I think it's fair to chalk it up to the sphere of problems caused by UTXO bloat?
Feel free to share it with anyone, though note that it's right now only a confirmation that it can be reproduced. Next steps for me:
BenchConnectBlockacross different ARM hardware. [arm]I aim to do 2 and 3 in parallel to the IBD whenever I find time.
It is for my test, so I'd say "yes". It's also what I expected.
I don't expect that, because txin verification doesn't depend on network - it's all done between disk, cache and cpu.
The block I gave as an example above contains mostly consolidation of
p2shutxo. So in this case, we're actually seeing bad performance on utxoset unbloat.because for example the IBD I did on an RK3588 earlier this year went much faster. There are some cpu feature differences between that and a Pi4. This would also suggest that a Pi5 would perform much better because it has some more CPU features built in. ↩