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
Anyone got the Beta Ryzens ?
You are asking more than 1 month earlier.
LOL
FREE BETA ORDER
Order ID: 1167980
You likely can't transfer credit, but a work around would be to find out what someone wanted and use the credit to buy that service and then transfer.
I think you missed the deadline for the free ram.
Also, is the beta and preferred location voting still going on? Just wondering because the coupons expired and I've been thinking about paying for one.
Just to be clear, our current CPU usage limits are much more lenient than as published in our AUP and if the server has unused CPU, it will basically not even contact you unless you are absolutely maxing out the CPU for hours. And the BF specials do not really have any stricter CPU usage guidelines just because they are specials. We use the same system, same as the customers paying $5 a month for a 1GB service on a non-special SSD1G. I believe the only potential caveat is that if you ordered a special advertised as 2.2GHz or just "shared" vCore and not specifically "3.4GHz" then if you end up on a server that's 3.4GHz, we might count a core as a portion of a core but you still at the very minimum (usually even 1.5x these amounts) still be protected by the numbers published on our AUP, which is the bare minimum we will ever take action on it.
As for Ryzen's CPU usage unless there is a large shift over to customers now using, let's say, 70% of an E5 2.2GHz core to using 70% of a Ryzen core, I believe the published CPU provided will essentially be "dedicated" in a sense that as long as usage levels on "average" continue to be similar, those people currently using maxed CPU will actually be able to always used maxed CPU without even receiving a notice.
Conservatively speaking, we are going from servers with servers that have a 37 Geekbench score per 1GB RAM to servers with something like 107 Geekbench score per 1GB RAM (so something like Dual E5-2690v2 with 256GB RAM to Ryzen 9 3950X with 128GB.) And then non-conservatively speaking, we are potentially going as far as 57 Passmark score per 1GB RAM to 306 Passmark score per 1GB RAM (Dual E5-2620v2 with 192GB RAM versus Ryzen 9 3950X with 128GB RAM.) This means that RAM and disk space will most likely end up being bottlenecks, and most servers should be running with plenty of CPU to spare. There's only so much CPU most use-cases can normally take advantage of before they run out of memory. Now, if someone is ordering the 2GB package with 2 cores, and they're planning on using 200/200% CPU over a week, plus CPU being used to run the KVM guest on top of that, and CPU being used because of high I/O usage, and they're trying to run some program that needs 4GB RAM and 4 CPU cores, with a swap file, I'm pretty sure no matter what, cases like that will end up being caught by some kind of anti-abuse system, not even necessarily the CPU system.
TLDR: We are planning to be even less strict or lift CPU limits completely.
Sorry for the extra wait over the weekend. These have been processed. Please don't forget to reboot for it to take effect.
Hi, I was able to catch this one even though you did not use the requested formatting. This has also been processed.
There will always be cases where a customer is part of a major outage and will, based on their anecdotal "evidence" believe that one host is better than the other regarding uptime. I believe what goes on in the background is more important, and how the host handles it and credits you. In this case, we definitely could have provided better updates. Our updates for outages have been lackluster lately but we do definitely work on bringing up the server as soon as possible.
ATLKVM15, a node facing hardware failure that got progressively worse this week, still has an uptime of about 87% for the week and specifically 96.866% so far this month. It is definitely not fair to state "long outages" and "one almost full day." Obviously, in most cases where customers are extremely upset there is a degree of an exaggeration. It's better to state "14 hours." Yes, this was relatively a long outage, but you are rounding up 14 hours to nearly 24 hours accompanied by "frequent outages," "continuous outages" and "extremely unreliable" while leaving out any of the details.
There was an outage on the 20th, 22nd, and 23rd.
I do not understand how an outage on the 20th, a Wednesday, can be considered two outages, and then the two outages on the 22nd (an hour or so) can be melded into the 23rd, a Saturday, as one big "almost entire day" outage, with a 2 day gap being considered a week. Perhaps you are in a country where the start of a "week" is on a Sunday and the timezone difference caused this to be on a Sunday but then it would be like a customer who ordered a VPS in December writing about having waited "a year without delivery" on January 1st, 2021.
By the way the "2 times long outages" were from 5:56AM to 2:07PM (eight hours) and 10:53PM to 11:47PM (about an hour.) This is to clarify for anyone interested in the actual details.
Okay, so back to this, as @ben47955 stated every provider will have their issues at some point. Every computer party will eventually die in some way. Some customers will always expect 100% uptime. We do guarantee it, and provide SLA credit if requested. But some customers confuse this as us stating that their service will in fact always be online, and that it's impossible for it to go down.
These were outages of 8 hours and 10 minutes, 53 minutes, and 14 hours and 14 minutes. Total, 23 hours over all three outages. Total, 23 and 17 minutes. Uptime over the month, again, is 96.866% for this month and it will result in the node having a 99.733% uptime throughout the year, assuming it doesn't continue to face issues. This is the first time this particular node has faced issues, so before this issue, this node actually had 100% uptime all of 2020. If we take this server, from the day it was set up, November 16th, 2019, until today, January 25th, 2021, then it is 99.77% uptime.
So not only would it be wrong to call the service as a whole "extremely unreliable" even if you take this one particular node, it'd still be a far stretch from reality. I suppose if you set specific boundaries in terms of days then you can make anything look excessively bad.
You can still vote, yes. I'll also still process the additional RAM for a few more days. > @imok said:
We should hopefully beat the deadline, at least for some.
Missed that, My Bad. It should have been formatted in Bold.
move on mate. no need to redeem yourself again. bold or not bold. you alrdy admitted ur mistake. jk 😝
Ha ha of course 😷🤣
...
FYI, I did the bitcoin method to avoid burning credit (worked great) and now I'm getting billing notices about the unpaid invoice (in my case, Invoice: 1163968). I'm fine with ignoring these notices, but I wanted to mention it just in case they get automatically cancelled in a week or something.
They should get auto-cancelled. If it gets cancelled as long as you posted here and we have the order ID we'll put it in the correct state.
ADDITIONAL RAM
Order ID: 6630051780
Invoice ID: 1163821
If you try to use it -> suspend!
You're late:
What about you had weak password and your vps got compromised?
@VirMach code KVMSPEC2021 has expired
@VirMach Hi, please help resolve the ticket 530561 and 927095. Anything is wrong with your technical support?
I believe this was meant to expire.
Everyone else, I have a question if you're still around:
Would anyone be interested in services that offer both NVMe SSD, and then additional HDD storage space? I'm not sure how we'll keep track of it at this point, we'll have to do it some way that doesn't further complicate these pre-orders but I'd like to start recording names somehow for who's interested or just have a general list/gauge interest.
So it could be something like 1GB RAM, 25GB NVMe disk space, 1 vCore, 2500GB bandwidth, 1Gbps port, 1x IPv4, 1x IPv6, and then on top of that ... something like 250GB* of RAID 10 HDD.
Or what NVMe SSD to HDD ratio would you be interested in?
Alternatively, what about daily backups?
@VirMach NVMe + optional HDD feels a good idea.
Is this gonna happen before Christmas?
NVMe+HDD @VirMach
NVME+HDD is great idea. I'm already using nvme+hdd with letbox and i like this combination
Very bad experience with this provider's support.
After over 1 month of waiting i still have no answer to my ticket.
I've a 125gb ssd KVM VPS (moved by Virmach last year from an old OpenVZ BF offer to the new KVM lite), stuck at 10gb disk memory, without options to expand disk.
I gladly like to have an answer from @VirMach to know if i have to keep this service active or move my machines to another provider.
Paying for a 125gb ssd disk and being able to use only 10gb isn't really fair.
Virmach is typing...
.
..
....
Haiz... @VirMach
Hope you will resolve my ticket soon! Thanks!
So you have this VM for more than two years and was using less than 5GB and now you need the 125GB ? You are right that you should be able to use these space, but you where aware of this limitation.
Concerning ticket respond, unlike you spamming ticket system, this should not be that delayed. I believe they caught up from their last sale by now.
FREE BETA ORDER
Order ID: 578901
Invoice ID: 1179562
Where do i say i need all the 125gb now?
I'm saying i can't use the system properly because of full disk and no option to expand it.
I'm 100% ok with the fair disk usage on idled or light used vps (i've another older machine at Virmach with the said option).
So yes, i used only the smallest part of the server mainly for testing purpose in the last 2 years (lemme guess, like 99.9% of people here).
Now not being able to do anything, with no answer at all seems unfair to me, if you're ok with their policy it i respect your opinion, but i think you can see what i'm concerned for.