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
Yeah I guess this is what they are trying to do these days.
It's the warm and fuzzy feeling of reading less shit here.
So your point is since miners do not care being attacked, it's better to attack to the providers.
It's not that hard to post 4-5 posts on a forum, how much time does this take you by the way?
Surprisingly my €1 vps is pretty consistent in performance.
Yawn... strange hobby you got there.
I kind of wonder though, you aren't by any chance the personal account of someone directly involved? It's kind of hard to imagine someone would be that invested randomly but oh well... people are strange sometimes.
“ We have made improvements in the meantime, so the problem should no longer exist. If you still need support, we are happy to help you.”
Ticket replied. And now my wp-benchmark score increased from 4.5 to 7.9.
The problem with mining is that it isn't always uniform in that sense, and for a lot of it (keeping it to CPU-based) would mimic AI/LLM/rendering very closely. An extremely common use-case we receive is Bella Render. Over a long enough time-frame you could likely decipher between Bella and XMR/Quilibrium/the next one but unfortunately that amount of time would be too long to wait while users are impacted. This is where @totally_not_banned is right imo: it's on the providers to decide who they are and what they want to do/serve. I like that use-case, and I've enjoyed interacting with clients that run that kind of software (two in particular have been extremely helpful and open with tons of details/benchmarks). I'd hate to false-positive suspend them in the middle of a 36-hour render. From the limited stats we see, it would be very difficult to differentiate those use cases from mining in less than ~96 hours with a high accuracy rate.
At the same time, @itsdeadjim is also right. There will always be some new mining algo/piece of software that skirts the limitations of a virtualized environment (VPS, VDS, etc) leading to providers having to now add blanket statements to their AUP's, figure out why their node is on it's knees but stats aren't showing any load that would be doing this (recent true story while helping someone else troubleshoot their environment) because of some new shitcoin that is now monetizing your RAM bandwidth, etc.
Of course, as someone who provides a VDS that doesn't do any sort of black magic AI core balancing and just gives you your core + threads I did dislike having the constant uphill battle when asked to price-match stuff that (as a provider) I blatantly knew wasn't the same dedicated setup. But that's my job/problem to solve. Some customers were probably mislead, most customers "didn't need" the dedicated resources so probably never noticed and were/are happy.
At the end of the day just basic good old fashioned detective work and talking to people works the best so far at identifying problems. I really don't want to give too much away, but legitimate users are always extremely easy to differentiate. If any miners are reading this: just tell your host what you're wanting to do. If the host can't properly support you, it's a lose-lose to try and sneak under their skirt. If the host is willing, then they'll quote you out appropriately for your use-case (i.e. a dedicated chassis with proper cooling) and you'll both be happy. You might even end up getting a better price because the host knows you're mining which is highly speculative month-to-month so they're not going to wait for that perfect Supermicro H12 board with all the expansion options available just in case your business grows, and instead can toss you on something existing or repurposed with minimal-to-no work and make it a win-win.
Is it even possible/feasible to limit memory bandwidth on a per VM basis? What is to stop someone from writing random data at max throughput to their allocated portion of RAM and stress out the MMU?
At that point...
At least in general i wouldn't be surprised (from my understanding VT-x/AMD-V do quite a bit) even if it probably isn't some kind of knob labeled throttle RAM but rather something that need to be taken care of around the MMU emulation. If/how far/where such a thing could be actually exposed is totally different topic though but in end it would probably be sufficient to merely detect it. Even if one can't directly influence the throughput simply dropping the clockrate once a condition is triggered. It's probably kinda hard to max the RAM when you don't get cycles. Not exactly elegant but if it's the difference between a DoS situation and smooth sailing...
Time to invent new shitcoin that mines memory bandwidth.
I just need to order exactly 453 VDS from Mr. @crunchbits
Sorry only 452 in stock, I would point you to @Advin
Yeah you'd run into other logical/natural bottlenecks probably but realistically there are many ways to abuse a hypervisor if that is your intention. Kind of an inefficient DoS, but possible.
Just run a LLM on a "dedicated cpu" VPS and surely it will burn through the memory bandwidth like there is no tomorraw.
These are shared cores, no shitfest magnet, sorry.
Unfortunately we only have 451.75 in stock, I would point you back to @crunchbits
Another funky idea would be having Qemu send alerts on specific instruction patterns being written to executable memory regions. Kind of like an anti virus but for known resource hogs. All it needs is some bored guy keeping the database up to date
Only 452 available? My research shows I need exactly 453 to ensure the maximum amount of LET drama is generated
Though I won't be surprised if the next shitcoin happens to kill hypervisor based hosts as a side effect
Seriously though, you've been out of stock for a while and I sadly missed your Genoa deals
Probably would force a full AVX2 or AVX512 workload to force a all core downclock in combo with flooding the MMU with page writes and then a curl script in the background running creating LET drama threads using custom AI LLM model trained from LET comments
I still see some stock! https://advinservers.com/cloud
Just not the yearly deals
I did wonder if something similar to what is used on shared hosting environments might find it's way into Qemu based hypervisors. When are you going to write it?
Funny enough, i've just spent 10 minutes chilling on the throne brainstorming. On 5th thought the idea doesn't even seem to be all that silly. Some kind of hardened Qemu with the ability to detect/mitigate DoS situations or generally detect disallowed applications being run.
Sorry , could not resist mathematical trivia about number 453 …. It is the sum first 30 numbers
Did you know that 453 and 7237 ( @online7237 ) are coprimes of one another? This cannot be merely a coincidence
You just made a business plan. Time to code it, then swim in cash.
yabs score now
&
Have a look at Intel RDT https://www.intel.com/content/www/us/en/architecture-and-technology/resource-director-technology.html
and AMD has QoS Extentions which seem to be extended further with newer EPYCs: https://www.phoronix.com/news/AMD-QoS-L3SBE-BMEC
never played with these, but it seems a good starting point.
Yeah, this could make a nice (well, at least as far as working with Qemu's codebase can be considered nice) winter project. The swimming in cash part could be a little problematic due to Qemu's GPL status though. From my perspective building upon GPL'd code is usually mostly advantageous for in-house use (no release, no obligations...) but who knows, maybe i'll run out of commercially questionable projects at some point
@itsdeadjim There being room for improvement can be pretty much taken for granted. The Qemu project doesn't really care that much beyond the basic premise of virtualization and there's quite a bit of options. Doesn't even have to be something overly complex. Just scanning memory around RIP for questionable code (by patterns, heuristics or even AI) and countering it by depriving the VM of cycles (admittedly likely resulting in a lot of side effects) would probably already ruin the fun of people trying anything clever. Another approach could be playing with the memory protection on the host side using the generated signals to slow down or at least monitor access.
I also wouldn't discount network traffic as a pattern all that easily. Even if it's all encrypted on fully randomized ports that in itself can already be a pattern. Take the chance of there being any kind of non-standard approaches that lead to observable anomalies and the whole encryption part becomes pointless as far as detection is concerned.
There is nothing preventing you from selling GPL code, you just have to give the source to the people you sold it to, afaik.
Yeah is not completely alien idea, assuming that this will be done on a sample basis, otherwise performance hit will be worse than running the miner.
I dont remember if qemu can have access to the executed instructions when vmx are used, but maybe it's better this way, as you could monitor kvm process itself and stay out from qemu GPL codebase, if you are seriously thinking about it.
If you open the door to something like that, nothing stops you to scan memory in general and access unencrypted network traffic, too. But then again all this opens many questions about privacy.
I guess the problem with selling GPL code is that you can sell it only once