<t​rustchaindev:matrix.org> Hi everyone, I've developed a Rust-based monitoring TUI (Sentinel Lite) for the upcoming FCMP++ Stressnet on May 6th. I have a CCS proposal drafted and ready to go. Could a maintainer help me get a GitLab account at repo.getmonero.org to submit it? Here is a demo of the tool in action: vimeo.com/1186644452

<s​yntheticbird:monero.social> video is a tui that tries to determine the amount of time it took for each blocks to be verified by the node... with rpc.

<s​yntheticbird:monero.social> plowsof i beg you give me the perm

<s​yntheticbird:monero.social> forgot to say its says simulated and mock rpc, so no real measure and the simulated measures are throwin bullshit numbers. Like somehow block 3000001 being verified in 20ms and 2 second later 3000002 being verified in 84 ms. make sense

<s​yntheticbird:monero.social> I CANNOT STAND IT BAN THIS CLANKER RIGHT NOW

.merge+ 10012

Added

<t​rustchaindev:matrix.org> Hey SyntheticBird, you're 100% correct the demo is running on a mock RPC and simulated logs. Although with this being a Dev group I assumed this would be understood. Eagle eyes, though nice catch. Better to feed it junk data now to ensure the telemetry holds up when the actual Stressnet hits on May 6th. I could mirror real feedback, but the point stands in that 3000ms spikes are n<clipped message>

<t​rustchaindev:matrix.org> ot just possible, they are expected. This is exactly what we what we are looking for in a stress-test scenario. The demo just shows you that reality in 60 seconds instead of waiting for a bad block event. Thanks for the feedback though, but I dont think this constitutes a ban.

<t​rustchaindev:matrix.org> Hey SyntheticBird, you're 100% correct the demo is running on a mock RPC and simulated logs. Although with this being a Dev group I assumed this would be understood. Eagle eyes, though nice catch. Better to feed it junk data now to ensure the telemetry holds up when the actual Stressnet hits on May 6th. I could mirror real feedback, but the point stands in that 3000ms spikes are n<clipped message>

<t​rustchaindev:matrix.org> ot just possible, they are expected. This is exactly what we what we are looking for in a stress-test scenario. The demo just shows you that reality in 60 seconds instead of waiting for a bad block event. Thanks for the feedback though, but I dont think this constitutes a ban.

<t​rustchaindev:matrix.org> I also tried to make that as clear as possible by showing both terminals from the start.

<r​brunner7:monero.social> "Although with this being a Dev group I assumed this would be understood." Such assumptions are always risky. Better to be crystal clear from the outset, to avoid any misunderstandings.

<r​brunner7:monero.social> "I also tried to make that as clear as possible by showing both terminals from the start." Well, even when watching the video full screen, text was hard to read for me, because of the unfortunately low contrast of blue on black.

.merge+ 10465

Added

<j​pk68:matrix.org> For some reason, I keep getting segfaults when running `ctest` in `build/debug/tests/unit_tests`

<j​pk68:matrix.org> Meanwhile, it works perfectly fine on the CI with the same branch (well, some tests don't pass, but it doesn't segfault)

<j​pk68:matrix.org> paste.debian.net/hidden/3335f89f

<j​pk68:matrix.org> The errors seem to come from `boosted_tcp_server` which my changes have nothing to do with

jpk68: if you compile master branch, do you get the same error?

<j​pk68:matrix.org> Will attempt, thanks

<j​pk68:matrix.org> Unrelated: I think issue #8562 can be closed

<j​pk68:matrix.org> selsta: Yes, it also segfaults on master

ok, one last test could you also checkout v0.18.4.6 tag, and run tests there? just to make sure there is no regression here

<o​frnxmr:xmr.mx> Does it segfault w/o your changes?

<j​pk68:matrix.org> Yes, I tested on master ^

<j​pk68:matrix.org> The issue is unrelated to my changes

<j​pk68:matrix.org> s​elsta: It also fails on v0.18.4.6, but with an exception instead of segfault

<j​pk68:matrix.org> Okay, I eventually got the tests working just by deleting the problematic ones... does look like a regression happened, though