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.
★ VirMach ★ RYZEN ★ NVMe ★★ $8.88/YR- 384MB ★★ $21.85/YR- 2.5GB ★ Instant ★ Japan Pre-order ★ & More
This discussion has been closed.
Comments
Yes,I know the boss already working on it,I was just thinking about the huge difference compared to your latency .
Please stop participation in spreading rumors.We have never discriminated against MJJ or Chinese customers.
Please think about why you are the only one with a problem and no one else has a problem.
When the ping was good the first few times, the latency gradually became worse.
I am looking forward to your good news.
ours is even March 12, and its not yet activated. 😬you need a lot of patience my friend. like really a lot. bigtime.
来自 176.119.148.1 的回复: 字节=32 时间=88ms TTL=44
请求超时。
来自 176.119.148.1回复: 字节=32 时间=60ms TTL=44
来自 176.119.148.1 的回复: 字节=32 时间=35ms TTL=44
来自 176.119.148.1 的回复: 字节=32 时间=38ms TTL=44
来自 176.119.148.1 的回复: 字节=32 时间=231ms TTL=44
来自 176.119.148.1 的回复: 字节=32 时间=285ms TTL=44
来自 176.119.148.1 的回复: 字节=32 时间=683ms TTL=44
来自 176.119.148.1的回复: 字节=32 时间=158ms TTL=44
来自 176.119.148. 1的回复: 字节=32 时间=76ms TTL=44
来自 176.119.148.1 的回复: 字节=32 时间=157ms TTL=44
来自 176.119.148.1 的回复: 字节=32 时间=110ms TTL=44
来自 176.119.148.1 的回复: 字节=32 时间=35ms TTL=44
来自 176.119.148.1 的回复: 字节=32 时间=36ms TTL=44
来自 176.119.148.1 的回复: 字节=32 时间=37ms TTL=44
来自 176.119.148.1的回复: 字节=32 时间=35ms TTL=44
请求超时。
来自 176.119.148.1的回复: 字节=32 时间=183ms TTL=44
来自 176.119.148.1 的回复: 字节=32 时间=399ms TTL=44
来自 176.119.148.1 的回复: 字节=32 时间=391ms TTL=44
This is my ping value fluctuation
@VirMach I am afraid you are wrong ,that activate the server should do depend on the order time instead of on proportions , so what you do now which is unfair is the reason so many people complain and sad
Please stop participation in spreading rumors.We have never discriminated against MJJ or Chinese customers.
Please think about why you are the only one with a problem and no one else has a problem.
It's not stable, some times getting very large (just as you), some times around 40ms
In these politically correct days, it's not very nice, calling out someone for being obese!
Oh my God: 400ms!! Holy shit the World is gonna collapse around us. Anyone for a dial-up modem? I'll let it go cheap - it's just lying in a box somewhere in the attic.
Is it a kernel incompatibility problem, when I upgrade the kernel from 4.9 to 5.3, the ping value becomes very high
I'm logging everything as these spikes happen and taking notes. Those periods of low time are when I take action, and then periods of it being bad again is everything breaking, as in a bunch of VMs crashing. I've controlled it to a good level now but I need to finish keeping track of these and mass contact the people with issues.
TYOC040 Update
Still not perfect and it took way too long and was super annoying to do and I don't even want to explain any of it right now but... whenever the VMs are not crashing it looks something like this to Vultr Tokyo, so it's definitely this and once it's resolved we'll have full port speed for everyone.
I'd do a YABS but it's impossible to time it right. Well it's possible but I'd have to sit around for half an hour between VMs crashing and other people running tests.
Overall the network graph looks much better than before.
Keep in mind it's still as easy to get a 1MB/s result as it is getting a 100MB/s result.
It's just random at this time.
Whenever a VM is rebooting and crashing, it's slow. Whenever it's clear, it's fast. And I've got the duration of it being slow to go down, and duration of it being fast to go up but there's still more work to be done.
And here's a little network graph screenshot for you guys, you can tell the difference by looking at it. All those spikes up to 2Gbps isn't actually 2Gbps, it's just how the monitoring software shows spikes over a long duration (which are most likely people testing the network.)
Before around 3:30 is before the reboots and fixes.
Here's another screenshot side by side load versus network. Notice how those large spikes mostly went away after some of the fixes. Those large spikes are when VMs would mass kernel panic and crash. Notice if you overlay them together, the period with these spikes was when networking was worse.
Edit -- this is what I mean
@VirMach , i miss those all location update 1 paragraph summery.
maybe if you create a page in the virmach web to check weekly the status for example would be just great.
Thanks for any consideration.
I'm beginning to suspend people booting into kernel panic on TYOC040. Suspension reason will be: "OS is causing overloading. Contact Priority Support."
Just make a ticket if you're one of these people, in the priority department, and I'll try to get it sorted with you ASAP.
It clearly shows you did not even read first few pages on this thread or read some of Virmach's earlier comments before posting this.
Seriously, this has happened too many times before during this preorder promo and I was even banned for several days straight. After Virmach strengthened their anti-something system it no longer happened to me and most people though.
So in your case, either you logged in way too many times, or there's something wrong with your browser that forces you to visit login page everytime you refreshed the webpage.
P.S. Why would you change several IPs to login? That isn't normal for most people and normally won't happen unless someone want to do something horrible...
Edit:
I went back in pages and noticed I am the first user to report that (on page 8)... https://lowendtalk.com/discussion/comment/3390364/#Comment_3390364
As Virmach explained on page 9, this system is in place to prevent bruteforcing. I haven't seen any ban after he said he improved the system and I'm rather a quite inpatient person, so I think it's adjusted to a reasonable level.
https://lowendtalk.com/discussion/comment/3392054/#Comment_3392054
Please check ticket #685653, i have make .Thanks
@VirMach When will the next batch be turned on? Will the 2.5GB RAM ordered on March 12th be scheduled to be turned on before April 15th?
May I ask when you will handle the Offline VMs on TYOC033 & TYOC035? thank you.
Because virmach does not send emails after booting, it can only log in regularly to view
I'll see what I can do, no promises as usual and be prepared to be disappointed.
Unsuspended but please re-install your OS if you can or check the logs inside to see what's causing the problem. I noticed a lot of these are Debian 10 and 11. If possible try another OS. If not, try installing from ISO. If that doesn't work either, try Debian 11 instead of Debian 10 at least, that seems to be less problematic.
I need to do the following first:
I'm going to be away for 1 or 2 hours right now, preparing some shipments. So I'd say realistically in 4 to 6 hours maybe more creations will resume again. Sorry for the continued delay.
In a few hours I'll look at these next.
I kept service page open on my browser and refresh periodically (sometimes I do see Cloudflare challenges) but it never redirected me back to login page in the past 48 hours.
If you have a login page (in any tabs) open on Chrome or any other browser that tries to save memory, it will constantly refresh the page in the background.
I first installed C7, out of the question modified D10, I go to install a D11
I'll try to test these operating systems as well to see why they're still having problems. We're using the official SolusVM templates that are supposed to be up to date and working on Alma Linux host so I'm not sure why they're broken. I haven't had time but it's on my priority list.
OK