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
Sub-160ms RTT between Hong Kong and Europe (the western part, I guess) is not possible with typical tier 1s. You strictly need RETN/those Russian ISPs to carry your packets in both direction, i.e., either your Hong Kong end or your European end has to be buying transit from one of them, not just peering.
I heard China mainland carriers also have direct terrestrial routes to Europe, but that won't be cheap.
Your best bet would be to get a jump host in Russia, you can easily find a host with RETN upstream there.
Yeah, I checked some pricing, easy 30$/m +
That's what I already have at hand, multiple, servers that can make use of the RETN TransKZ. Just waiting for the StarryDNS HK to be deployed and then maybe add another one.
I don't know in how far you are willing to make a trade-off but I am seeing ping times around the 170ms mark with G-Core Labs to several of my VPS in Europe.
Yea, I got a bunch of gcore vps's, I get about 120ms, however still need to forward the traffic from there anyway so latency is higher.
Issue is rather, finding a cheap server in the region of China with RETN Transit.
@Dwayne where did you measure the 170ms from?
Something like
https://www.lowendtalk.com/discussion/172060/hosthatch-sydney-ipv6-broken-for-two-weeks-and-counting#latest
An excellent attempt to stir up some drama - but no. This is a valid issue that we have in Sydney, that we are doing our best to get resolved. NTT was down in Sydney yesterday - along with the whole Psychz network there, so it's not just isolated to us.
Now compare that with someone posting on LET about an issue a number of times before opening a ticket, only opening a ticket after being asked several times on LET, then getting it resolved in a short time frame and coming back to LET to lie and say it never got resolved.
There's a huge difference between those two situations, and it has been discussed a number of times before why the OP was politely told to find another provider
No one ever got kicked for complaining about us publicly (there are multiple users on that thread that you posted yourself that have been long-time customers of ours).
I don't think there is a reason to stir this up again. I wish the best to OP to find what he's looking for.
So you in for this again?
Stop telling lies to people, several people confirmed the issues with M247.
I did posted smokeping graphs yes, according to you this is forbidden.
The Ticket was open before you as you claim "you asked me several times".
The lie you put on the table again, that I claimed publicly you didn't fix it.
Your last response on this Ticket was:
"We are aware that M247 has congestion in multiple areas of their network. We have ETAs for a full resolution but in the meantime, we are able to avoid the affected routes. So while you might see the issues with the M247 global network in general, we can fix this for our network by simply avoiding the congested links."
Which I said you implemented a work around but no fix.
And you call this a lie?
We can do this 100 times if you wish.
I am not sure what pleasure you derive from bringing this up again and again.
We don’t want to do business with you. I understand it is hard for you to deal with this but please stop spreading lies. There are at least 3 of them again there.
Lie #1.
Or please feel free to point to where exactly we said this is forbidden.
Lie #2. You posted at least 3 times and were asked at least 2 times before you opened a ticket. Pretty sure it was more times than these too.
No you didn’t. You simply said the issue was not fixed. So that’s lie #3. Prove me wrong please, show us all where you said this.
And as several people pointed out to you the last time you went on this crusade - re-routing traffic is a standard network practice and not a “work around”.
So yes, that was lie #3.
Telling people that you got kicked because you “complained publicly” is far from the truth.
We run 14 global locations - of course we have isolated network issues from time to time. If we started kicking customers for complaining about it, we wouldn’t have a lot of customers left. The false logic in your argument is apparent to everyone who read the story earlier and will do now.
I currently get 185-190ms from Hong Kong (Equinix) to Munich (Level3/Lumen or Equinix DC with Telia, Level3, NTT.. 20ms higher with Cogent or HE, @Neoon from what location in Europe are you testing for the 160ms?
What specific EU IP are you testing from?
https://greencloudvps.com/hong-kong-ssd-kvm-vps.php
Test IP: 103.232.84.1
I didn't, people asked why, and I replied.
You kicked me out, simple, I can say that publicly.
You can decide who you do business with for sure, however if you would stop spreading lies, this issue would have been solved long ago.
You imply it by what you say.
Last time you said, you asked me 3 times, to open a ticket.
Now its 2 times, what is it?
I know what I said, if I find the post I add it.
You can prove me wrong of course by proving a link.
I told people, that your network is/was bad, this was the main point, why you refused services with me aka kicked me out, whatever you wanna call it.
At this time, other users reported the same, so isolated network issues don't apply.
Austria, London at the same time where affected, when I recall it correctly.
Testing from Warsaw and Frankfurt, about 150-170ms.
Moscow is about 130ms.
About 120ms to HK IX.
Yekatarinburg was 111ms.
146.185.218.1, not EU but has RETN Transit.
Yep, as expected, zero actual facts or proof
I think everyone can make their own conclusions from your last response. See you again when you decide to do this again in a few months
The last 2 times, I asked you for proof, you never provided anything.
Its funny that you say that right now.
I am to lazy for that now, but I make sure I find that post, where I said that.
And I make sure it lands on the front page.
I mean you started it, again, not me.
All I said was you kicked me out and you came in like a drama queen.
Serverhub Frankfurt via Virmach: rtt min/avg/max/mdev = 171.069/171.093/171.163/0.524 ms
hosthatch.com London: rtt min/avg/max/mdev = 173.373/173.663/174.687/0.633 ms
vserver.site Duesseldorf: rtt min/avg/max/mdev = 174.810/175.152/175.973/0.626 ms
store-host.com Switzerland: rtt min/avg/max/mdev = 176.855/176.920/177.050/0.074 ms
webhosting24.com Munich: rtt min/avg/max/mdev = 177.327/177.389/177.448/0.041 ms
How did you manage to not get moved to Amsterdam?
Maybe Its a good idea to get Gcore HK and StarryDNS, I guess.
No idea. I am on GERKVM6 which I believe is one of their German nodes without any issues.
Just to avoid confusion: The ones I listed above are only those VPS in Europe with sub-180ms latency to G-Core HK. The others have significantly higher latency, sometimes exceeding 300ms.
OK, 170ms from Frankfurt is probably the best you can achieve with "normal" tier-1 carriers.
Maybe a China Telecom route from HK to Frankfurt could be an alternative to RETN on land, but you will be paying quite a premium for shaving off max. 10% of latency (10-15ms) going from 170ms to 160ms or sligthly below.
arubacloud.com Italy: rtt min/avg/max/mdev = 168.250/168.603/168.969/0.347 ms
Yea Frankfurt is pretty close, using TRANSKZ I should be pretty much at the limit what is possible. I was looking to getting some Provider in the Ukraine or Russia close to Kazakhstan that has RETN Transit, but so far no found anything.
So I would skip Moscow, to save about another 10ms.
10.0.6.1 : xmt/rcv/%loss = 5/5/0%, min/avg/max = 170/172/179 #SG
10.0.34.1 : xmt/rcv/%loss = 5/5/0%, min/avg/max = 169/170/172 #Tokyo
10.0.35.1 : xmt/rcv/%loss = 5/5/0%, min/avg/max = 169/172/175 #Hong Kong
Looks good now, a bit higher due to different routes, usually its a bit lower.
Tanks all.
Do you mean this? :-)
From the looks of it, yes.
So a funny guy