New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
Hello, here is the YABS i took. Specs are just a 1c/1gb/20GB NVMe/2.5Gbps @ 5 TiB + Ping n routing test
Overall, the bandwidth and speeds are very good. other then that. It's alright
For that type of image, I would do:
Size is now under 200 KiB. As for the other images, they have high-frequency components so I'd recommend just using optipng or converting to lossless WebP instead. Or even AVIF. Pretty much everything supports AVIF now.
Actually, the other images like chess-piece.png look like they went through lossy compression before being converted to PNG. Perhaps regenerate them. Anyway, I think we're supposed to message him via tickets, but there's nothing wrong with posting here as well to give others ideas!
Thank you for further optimization up to 97.6% . However, webp/avif aren't supported on older browser.
Anyway, have you diagnose the TLS e.g cipher selection, key exchange, etc?
It uses Cloudflare to handle TLS. No idea what the backend uses (ideally it should be using mlkem768x25519).
Try looking into this
~~{backups,fbi,hv,hv-agent,metal,nsa}.crunchbits.com~~ ~~agent-{cda,dfw,lblk,sof,vfo}.crunchbits.com~~ ~~lg-{tek,spk}.crunchbits.com~~Oops, old domain
lg-{spo,sof,dfw,vfo}.synteq.comGood questions. I’m also curious about the blockchain node policy. Let's see what the provider says
Overall I found the portal very responsive and easy to navigate. The layout feels clean, and I didn't run into any major issues during normal use.
A few things I noticed as a first-time user:
Registration
It took me a moment to realize the illustration was actually my profile picture and that I could click it to choose or upload an avatar. A small label or hint might make that a bit more obvious for first-time users.
Webhook
The "payloads" link has an external link icon, so I expected it to open in a new tab. It opened in the current tab instead, which caught me a little by surprise.
BGP
This one caught me off guard. Every other item in the sidebar takes me to a page, so I expected BGP to do the same. Instead, it opened a modal. It made sense after the first click, but initially I assumed sidebar items were only used for navigation.
Overall, I like the UI. These are just a few small things that stood out during my first use.
He replied here:
Thanks definitely not ChatGPT
you're welcome definitely beanman109
the PP cake is a lie
We guess we are good with our hands:
If we get one push-up for each bug entered, Eric would be on the floor now.
Damn you did a lot better than me lol
Noice. Been testing the backend
its very nice but some minor issues or features missing. You pushed a big update so I'll spend some time on it tomorrow.
Overall, looks good but not 100% production ready. Updates may have fixed, the CLI looks awesome.
Upped the rate limits just for you
Hmm, 30% CPU steal when benchmarking 12 dedicated vCPUs?
Is this still going? Count me in as well!
DM’d the email yesterday but haven’t received the invite yet. .
This seems to be caused by a bug in the VM resizing code. I originally got an 8 dedicated core VDS and later resized it to 12 dedicated cores, however I never managed to exceed 800% core performance, and CPU steal would go up to ~30%.
From some testing, it looks like the 4 new cores are not being given their own dedicated core, so when I upgraded to 12 vCPUs, it's still only 8 physical cores handling them, which explains the CPU steal. The extra 4 are "fake".
Can someone else test this for me as well? If anyone has purchased a VDS or a VPS with dedicated cores, try resizing the VM and adding one or more extra cores, then attempt to benchmark them all while monitoring CPU steal and total CPU usage of the benchmarking process. E.g. if you start with 4 cores and benchmark shows 400% usage and 0% steal, upgrade from 4 to 8 cores and benchmark all 8 and see if it shows 800% usage and 0% steal as it should, or if it still shows 400% usage across all 8 cores and 50% steal (which would indicate all 8 vCPU threads are pinned to your original 4 cores).
I reported a bug where /var/logs got wiped and cloud-init generated a new fingerprint after the resize. Did you see that behavior or has it already been fixed?
Did you resize the storage, and if so did you grow or shrink it? I only resized memory and cores and didn't experience what you describe. The logs disappearing and a new fingerprint being generated would indicate to me that the VM was reinstalled, which might make sense if you shrunk the storage (it's easier to grow than to shrink a live filesystem).
Just changed from shared to dedicated and increased ram and cores. I haven't tested again since the update, so I'm assuming it was fixed.
Imagine the drama "Resizing wiped my disk Synteq". "93.8 steal after changing the core count"
Can you try running
stress -c $num_coresand then check if there's any steal withtop?I'm wondering if this bug only occurs when increasing the number of dedicated cores or if it occurs when when increasing if you're also switching from shared to dedicated.
I am not sure, however, I would consider CPU Steal not as a bug during this testing period. I belive, Eric said that this is a small test deployment. Which would probably suggest that this is not the final deployment that users will get in terms of actual node placements/cpu-pinning/performance/etc. - I assume the idea of this thread is to test the software platform and not the exact hardware performance. Hardware is hardware, no much to test on it - it's server grade, went through burn-ins and etc. Software testing is prob what matters to them.
I could be wrong, of course.
The issue isn't that there is steal, the issue is that increasing the number of dedicated cores does not actually increase the number of dedicated cores, just the number of logical vCPU threads. That's a bug in the new panel, not a hardware limitation.
In other words, when you purchase a VDS with n cores and start it up, n threads are spawned and pinned to n cores. When you upgrade an extra core, it should spawn n + 1 threads and pin it to n + 1 cores, but instead it only pins it to n cores.
Late but would love to test!
My apologies, I have misread the initial comment on what the meaning was exactly. I see now!
It is a final deployment for production in-so-much as what customers would see for basic VPS. Definitely need all the edge cases looked into. What I don't care about is the single/multi-core vCPU speed on a 1core VPS, or other common-sense kind of support items. They've been doing the Lord's work so far, though.
All excellent feedback. Watching them iterate/re-check/etc been fantastic.