Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


★ WebHorizon - AMD Ryzen 3600/5950x VPS, Free Backups, NVMe, 100% Moneyback guarantee ★ - Page 3
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.

★ WebHorizon - AMD Ryzen 3600/5950x VPS, Free Backups, NVMe, 100% Moneyback guarantee ★

13»

Comments

  • Hk2 has been offline for a long time, how long can you repair it

  • AbdAbd Member, Patron Provider
    edited September 2022

    @1337mg said:

    @1337mg said:
    @Abd #4369921 - Please issue a refund

    LE Sunday Special ought to be hosted at Poland as advertised but due to some reason it was provisioned in the Germany DC which gives me +100ms latency compared to Poland. Ticket was raised 2 weeks ago, with no resolution in sight. Disappointed and advise everyone to be cautious until the provider fixes his terrible ticketing system. Will update if my ticket is resolved.

    I can confirm this is in Poland as advertised - we don't do KVMs in Germany.
    and awaiting a reply from TATA if they can fix the latency to your ISP. It is something caused on the ISP / transit's end & they are already on it.

    I'm glad to issue refunds when things don't work out for my clients, but cannot issue refunds in 'cash' ; and this was the reason for not accepting cash payment in first place, but provided it on your 'request'. lesson learnt well.

  • @Abd said:

    @1337mg said:

    @1337mg said:
    @Abd #4369921 - Please issue a refund

    LE Sunday Special ought to be hosted at Poland as advertised but due to some reason it was provisioned in the Germany DC which gives me +100ms latency compared to Poland. Ticket was raised 2 weeks ago, with no resolution in sight. Disappointed and advise everyone to be cautious until the provider fixes his terrible ticketing system. Will update if my ticket is resolved.

    I can confirm this is in Poland as advertised - we don't do KVMs in Germany.
    and awaiting a reply from TATA if they can fix the latency to your ISP. It is something caused on the ISP / transit's end & they are already on it.

    I'm glad to issue refunds when things don't work out for my clients, but cannot issue refunds in 'cash' ; and this was the reason for not accepting cash payment in first place, but provided it on your 'request'. lesson learnt well.

    I'm not so much for an actual refund as I was for catching your attention because it really felt like no progress was being made. It's one thing having technical issues in the middle of the service and completely different when it's immediate and persistent for 2 weeks after the payment. Leaves a bad taste in the mouth. Feels like "lesson learnt well" for taking risks on bang-for-the-buck deals on the internet.

    Also, a dissatisfied customer expressing frustration over an actual lapse in the quality of service provided shouldn't be thrown shade over the mode of payment they had made. I get it. The reason for my dissatisfaction could be temporary and resolved soon, and nothing may be in your hands as well in regard to its resolution. But it makes no sense to make the customer feel attacked that their request was some kind of learning lesson for you when it has no real connection to the issue at hand.

  • When will HKG2 resume

  • AbdAbd Member, Patron Provider
    edited September 2022

    @g121 said:
    When will HKG2 resume

    HKG2 & HKG3 were fixed some days ago :)
    If offline, try start the vps from panel,

    Thanked by 1g121
  • MumblyMumbly Member
    edited September 2022

    @1337mg said: ought to be hosted at Poland as advertised but due to some reason it was provisioned in the Germany DC which gives me +100ms latency compared to Poland.

    That's a funny one :)
    I mean it's explained already that it's transit issue, but what I wanted to say is that Germany and Poland basically border to each other and the difference would be something between 5 - 15ms max if you would appear in the wrong country.
    And if you're not exactly from Poland there's bigger chance that you get less latency from Germany than from Poland as in many cases international traffict from Poland would be routed through Germany anyway.

    100ms latency is between cental EU and US east coast (two continents) as example.
    Anyway, I hope your issue gets solved.

  • @Abd said:

    @g121 said:
    When will HKG2 resume

    HKG2 & HKG3 were fixed some days ago :)
    If offline, try start the vps from panel,

    It is odd that HKG2 still cannot obtain IPv6 address

  • The control panel for one of my Japan NAT VPSs doesn't load. Ticket sent in August but no response. Could you help look into it, please?

  • AXYZEAXYZE Member
    edited September 2022

    @Mumbly said:

    @1337mg said: ought to be hosted at Poland as advertised but due to some reason it was provisioned in the Germany DC which gives me +100ms latency compared to Poland.

    That's a funny one :)
    I mean it's explained already that it's transit issue, but what I wanted to say is that Germany and Poland basically border to each other and the difference would be something between 5 - 15ms max if you would appear in the wrong country.

    Ok, so what does that mean? Most of polish connections I tested have better ping to Netherlands than to Germany, for example on my connection Oracle AMS is 21ms, whereas Hetzner Nur is 32ms. And I live near to German border too, I can drive to Nuremberg today if I want, its so close.
    "Germany and Poland basically border to each other", it changes nothing with his issues. And this 5-15ms figure is very interesting when difference between AMS and NUR is 11ms already XDD Would love to see where did you see 5ms, its impossible.

    "And if you're not exactly from Poland there's bigger chance that you get less latency from Germany than from Poland as in many cases international traffict from Poland would be routed through Germany anyway."
    Now THAT'S funny one.

  • @Abd said:

    @g121 said:
    When will HKG2 resume

    HKG2 & HKG3 were fixed some days ago :)
    If offline, try start the vps from panel,

    Hk2 domain forwarding is not working a few days ago when I tested, and I bet it's still under maintenance?

    How's the progress of HK1? :))

  • MumblyMumbly Member
    edited September 2022

    @AXYZE said:

    @Mumbly said:

    @1337mg said: ought to be hosted at Poland as advertised but due to some reason it was provisioned in the Germany DC which gives me +100ms latency compared to Poland.

    That's a funny one :)
    I mean it's explained already that it's transit issue, but what I wanted to say is that Germany and Poland basically border to each other and the difference would be something between 5 - 15ms max if you would appear in the wrong country.

    Ok, so what does that mean? Most of polish connections I tested have better ping to Netherlands than to Germany, for example on my connection Oracle AMS is 21ms, whereas Hetzner Nur is 32ms. And I live near to German border too, I can drive to Nuremberg today if I want, its so close.
    "Germany and Poland basically border to each other", it changes nothing with his issues. And this 5-15ms figure is very interesting when difference between AMS and NUR is 11ms already XDD Would love to see where did you see 5ms, its impossible.

    "And if you're not exactly from Poland there's bigger chance that you get less latency from Germany than from Poland as in many cases international traffict from Poland would be routed through Germany anyway."
    Now THAT'S funny one.

    "Most of Polish" you tested makes if a fact?
    I live in Slovenia and almost every connection to the Poland goes through the Germany. And that's a fact. And what now?

    Right now I own only two .pl VPSes, one from HappyBeeHost PL ovh and the other from Polish slaskdatacenter.com. I did some tests to the several German servers I own (Webhosting24, Virmach ...) and also several Netherlands servers I own (Greencloudvps, Hosthatch, Liteserver...) and result is so-so although in general I got around 5ms lower ping from those two Polish to my German VPSes.
    With 5ms (to 15ms) which served just as example I may overreacted as transit may not go directly (and yes, there is 5 - 10 ms between as example Slovenia, Ljubljana - Austria, Graz or Slovenia, Ljubljana - Croatia, Zagreb) but my point stay.
    There's no way, not even in theory to produce extra 100ms difference just because you're in Germany instead of Poland. Say around 15ms and I will take it, but anything more than that is a bullshit. 100ms is a difference between two continents (US/Europe), not two neighbour EU countries.

    That's (as example) latency between Virmach DE and HappyBeeHost PL:

    --- 51.77.xx.xxx ping statistics ---
    4 packets transmitted, 4 received, 0% packet loss, time 3006ms
    rtt min/avg/max/mdev = 15.689/15.758/15.823/0.053 ms
    

    and between Liteserver NL and HappyBeeHost PL:

    --- 51.77.xx.xxx ping statistics ---
    4 packets transmitted, 4 received, 0% packet loss, time 3006ms
    rtt min/avg/max/mdev = 23.633/23.645/23.664/0.011 ms
    

    ...but I don't even object that there's low latency also to the NL. You can easily replace DE with NL in my argument if you want so. It's just prove my point that there's no way to get 100ms difference here.

    Thanked by 1yoursunny
  • AXYZEAXYZE Member
    edited September 2022

    @Mumbly said:
    "Most of Polish" you tested makes if a fact?
    I live in Slovenia and almost every connection to the Poland goes through the Germany. And that's a fact. And what now?

    You wrote "Germany and Poland basically border to each other" as a argument that connection needs to be perfect and ping very low just because we are neighbors.

    I wrote that it doesn't matter that these countries border each other, because my test points (which cover 95%+ of residential connections, we do health checks for e-commerce so we have many small PoPs in Poland because of issues in the past) have usually lower ping to Amsterdam than anything in Germany. I think such coverage is big enough to make a point, but If you want 100% coverage I sadly cannot do it, too many small local providers and tons of MVNO.

    You can blame it on congestion, you can blame it on routing, but why do you even bright Slovenia into it? I'm purely speaking about Poland -> Germany connection which isn't great with VERY small exceptions in FRA (maincubes) just like person you're replying to.

    Location proximity doesn't guarantee low ping, something that you want to prove.
    If you want to get Slovenia into it then ok - how's routing between Shanghai and lowend HK VPSes? Its so close, ping will be 2ms right?
    Please, bordering with some country doesn't mean anything.

    And talking about this situation in specific - I purchased WebHorizon PL VPS one year ago and I got 30-130ms ping from various Polish connections. I messaged Abd about it, provided traceroutes and he worked with Mevspace (their PL datacenter) to fix it and I dont know how it went. I only know that they made additional agreement with Orange (biggest ISP in PL) in December 2021 to exchange data in Poland.

    130ms ping was with different, small, local provider, IDK if that was fixed. It was stupid idea to add random datacenter as test point anyways, nobody will use that and I will get only false alarms.

    Here's my message, one specific to 130ms ping

    So as you can see I had the same experience as person you're replying to with PL -> PL connection which was like 100km apart.

    He is mistaken about location of his server, but your argument that close proximity equals low ping with this 5-15ms figure is completly wrong. It doesn't work that way here, your ping from Slovakia to Polish datacenter is not an counter-argument.

    Germany has fucked up things (DTAG as a examle), Poland has fucked up things (example: Orange will not exchange in Poland in their Polish exchange TPIX unless you basically give them extra $$). When fucks from both countries merge, latency is higher than to New York lol.

  • @Mumbly said: It's just prove my point that there's no way to get 100ms difference here.

    https://lg.as6453.net/lg/

    Router: gin-cxr-tcore1
    Site: IN, Chennai, CXR
    Command: ping inet count 5 185.244.30.2
    
    PING 185.244.30.2 (185.244.30.2): 56 data bytes
    64 bytes from 185.244.30.2: icmp_seq=0 ttl=49 time=228.477 ms
    64 bytes from 185.244.30.2: icmp_seq=1 ttl=49 time=230.970 ms
    64 bytes from 185.244.30.2: icmp_seq=2 ttl=49 time=228.834 ms
    64 bytes from 185.244.30.2: icmp_seq=3 ttl=49 time=229.293 ms
    64 bytes from 185.244.30.2: icmp_seq=4 ttl=49 time=234.702 ms
    
    --- 185.244.30.2 ping statistics ---
    5 packets transmitted, 5 packets received, 0% packet loss
    round-trip min/avg/max/stddev = 228.477/230.455/234.702/2.289 ms
    
    Router: gin-cxr-tcore1
    Site: IN, Chennai, CXR
    Command: ping inet count 5 45.142.105.106
    
    PING 45.142.105.106 (45.142.105.106): 56 data bytes
    64 bytes from 45.142.105.106: icmp_seq=0 ttl=49 time=350.264 ms
    64 bytes from 45.142.105.106: icmp_seq=1 ttl=49 time=350.537 ms
    64 bytes from 45.142.105.106: icmp_seq=2 ttl=49 time=350.175 ms
    64 bytes from 45.142.105.106: icmp_seq=3 ttl=49 time=350.236 ms
    64 bytes from 45.142.105.106: icmp_seq=4 ttl=49 time=350.191 ms
    
    --- 45.142.105.106 ping statistics ---
    5 packets transmitted, 5 packets received, 0% packet loss
    round-trip min/avg/max/stddev = 350.175/350.281/350.537/0.132 ms
    
  • MumblyMumbly Member
    edited September 2022

    @1337mg it's explained already that it's transit issue (which will be fixed) not "wrong country" issue and I will repeat it again, there's no way to get 100ms difference just because you would appear in the Germany instead of nearby Poland.
    Under normal circumstances you would get minimal if any additional latency to the China if your server would be in Germany instead of Poland (geographically looking).
    But infact there's a bigger chance (and @AXYZE failed to understand) that you would have better latency to your location from Germany than Poland as a lot of international traffic in this part of the Europe goes through German (and/or Netherlands - if you need it to be said, axyze) PoPs anyway.

    Seems like you both with @AXYZE have problem with functional reading, to understand basic message someone's trying to explain.

    To China from PL (Ovh)

    PING 58.247.206.179 (58.247.206.179) 56(84) bytes of data.
    64 bytes from 58.247.206.179: icmp_seq=1 ttl=42 time=210 ms
    64 bytes from 58.247.206.179: icmp_seq=2 ttl=42 time=210 ms
    64 bytes from 58.247.206.179: icmp_seq=3 ttl=42 time=210 ms
    64 bytes from 58.247.206.179: icmp_seq=4 ttl=42 time=210 ms
    
    --- 58.247.206.179 ping statistics ---
    4 packets transmitted, 4 received, 0% packet loss, time 8ms
    rtt min/avg/max/mdev = 209.592/209.611/209.630/0.560 ms
    

    To China from PL (slaskdatacenter)

    PING 58.247.206.179 (58.247.206.179) 56(84) bytes of data.
    64 bytes from 58.247.206.179: icmp_seq=1 ttl=47 time=203 ms
    64 bytes from 58.247.206.179: icmp_seq=2 ttl=47 time=203 ms
    64 bytes from 58.247.206.179: icmp_seq=3 ttl=47 time=203 ms
    64 bytes from 58.247.206.179: icmp_seq=4 ttl=47 time=203 ms
    
    --- 58.247.206.179 ping statistics ---
    4 packets transmitted, 4 received, 0% packet loss, time 6ms
    rtt min/avg/max/mdev = 202.945/202.975/203.012/0.319 ms
    

    To China from DE (Virmach)

    PING 58.247.206.179 (58.247.206.179) 56(84) bytes of data.
    64 bytes from 58.247.206.179: icmp_seq=1 ttl=49 time=193 ms
    64 bytes from 58.247.206.179: icmp_seq=2 ttl=49 time=193 ms
    64 bytes from 58.247.206.179: icmp_seq=3 ttl=49 time=193 ms
    64 bytes from 58.247.206.179: icmp_seq=4 ttl=49 time=193 ms
    
    --- 58.247.206.179 ping statistics ---
    4 packets transmitted, 4 received, 0% packet loss, time 3004ms
    rtt min/avg/max/mdev = 192.603/192.693/192.792/0.068 ms
    

    To China from DE (Hetzner) -btw. that's WebHorizon NAT VPS

    PING 58.247.206.179 (58.247.206.179) 56(84) bytes of data.
    64 bytes from 58.247.206.179: icmp_seq=1 ttl=46 time=168 ms
    64 bytes from 58.247.206.179: icmp_seq=2 ttl=46 time=168 ms
    64 bytes from 58.247.206.179: icmp_seq=3 ttl=46 time=168 ms
    64 bytes from 58.247.206.179: icmp_seq=4 ttl=46 time=168 ms
    
    --- 58.247.206.179 ping statistics ---
    4 packets transmitted, 4 received, 0% packet loss, time 5ms
    rtt min/avg/max/mdev = 167.930/167.960/168.004/0.291 ms
    
  • MumblyMumbly Member
    edited September 2022

    And from the other side:

    From China to Poland (OVH)
    Router: gin-cxr-tcore1
    Site: IN, Chennai, CXR

    PING 51.77.xx.xxx (51.77.xx.xxx): 56 data bytes
    64 bytes from 51.77.xx.xxx: icmp_seq=0 ttl=45 time=241.392 ms
    64 bytes from 51.77.xx.xxx: icmp_seq=1 ttl=45 time=241.316 ms
    64 bytes from 51.77.xx.xxx: icmp_seq=2 ttl=45 time=242.353 ms
    64 bytes from 51.77.xx.xxx: icmp_seq=3 ttl=45 time=241.289 ms
    64 bytes from 51.77.xx.xxx: icmp_seq=4 ttl=45 time=242.067 ms
    
    --- 51.77.xx.xxx ping statistics ---
    5 packets transmitted, 5 packets received, 0% packet loss
    round-trip min/avg/max/stddev = 241.289/241.683/242.353/0.441 ms
    

    From China to Poland (slaskdatacenter)
    Router: gin-cxr-tcore1
    Site: IN, Chennai, CXR

    PING 185.24.xxx.xx (185.24.xxx.xx): 56 data bytes
    64 bytes from 185.24.xxx.xx: icmp_seq=0 ttl=57 time=150.301 ms
    64 bytes from 185.24.xxx.xx: icmp_seq=1 ttl=57 time=150.377 ms
    64 bytes from 185.24.xxx.xx: icmp_seq=2 ttl=57 time=151.109 ms
    64 bytes from 185.24.xxx.xx: icmp_seq=3 ttl=57 time=152.127 ms
    64 bytes from 185.24.xxx.xx: icmp_seq=4 ttl=57 time=151.472 ms
    
    --- 185.24.xxx.xx ping statistics ---
    5 packets transmitted, 5 packets received, 0% packet loss
    

    From China to DE (Virmach)
    Router: gin-cxr-tcore1
    Site: IN, Chennai, CXR

    PING 149.57.xxx.xxx (149.57.xxx.xxx): 56 data bytes
    64 bytes from 149.57.xxx.xxx: icmp_seq=0 ttl=58 time=139.851 ms
    64 bytes from 149.57.xxx.xxx: icmp_seq=1 ttl=58 time=141.231 ms
    64 bytes from 149.57.xxx.xxx: icmp_seq=2 ttl=58 time=140.032 ms
    64 bytes from 149.57.xxx.xxx: icmp_seq=3 ttl=58 time=139.903 ms
    64 bytes from 149.57.xxx.xxx: icmp_seq=4 ttl=58 time=140.413 ms
    
    --- 149.57.xxx.xxx ping statistics ---
    5 packets transmitted, 5 packets received, 0% packet loss
    round-trip min/avg/max/stddev = 139.851/140.286/141.231/0.512 ms
    

    From China to DE (Hetzner) -btw. that's WebHorizon NAT VPS
    Router: gin-cxr-tcore1
    Site: IN, Chennai, CXR

    PING 23.88.xx.xxx (23.88.xx.xxx): 56 data bytes
    64 bytes from 23.88.xx.xxx: icmp_seq=0 ttl=59 time=138.113 ms
    64 bytes from 23.88.xx.xxx: icmp_seq=1 ttl=59 time=138.017 ms
    64 bytes from 23.88.xx.xxx: icmp_seq=2 ttl=59 time=138.127 ms
    64 bytes from 23.88.xx.xxx: icmp_seq=3 ttl=59 time=137.659 ms
    64 bytes from 23.88.xx.xxx: icmp_seq=4 ttl=59 time=137.813 ms
    
    --- 23.88.xx.xxx ping statistics ---
    5 packets transmitted, 5 packets received, 0% packet loss
    round-trip min/avg/max/stddev = 137.659/137.946/138.127/0.182 ms
    

    As you see, VPS being located in Germany wouldn't add additional 100ms latency compared to Poland. If anything latency would be lower.

    And now @AXYZE go back and read my initial post you responded. I was actually wrong about one minor detail but not the way you wanted it to be wrong. My main point stay. There's no way to get additional 100ms just because you would appear in the wrong neighbour EU country. Infact in this specific case it's even lower.

  • I want a nat vps in Singapore, but I found that it is out of stock now, when will it be available?
    thanks! :D

    Thanked by 1postcd
  • AbdAbd Member, Patron Provider
    edited November 2022

    I have restocked the LE SUNDAY Special plan mentioned in OP for this weekend :)


    LE SUNDAY Special

    2 CPU AMD Ryzen 5
    4 GB RAM (Dedicated)
    100 GB NVMe/SSD Disk
    1 IPv4 + /64 IPv6
    15TB Premium Bandwidth per month
    DC Location - Poland

    Order Link - US$5 / month
    Order Link - US$38 / YEAR

  • @Abd said:
    I have restocked the LE SUNDAY Special plan mentioned in OP for this weekend :)


    LE SUNDAY Special

    2 CPU AMD Ryzen 5
    4 GB RAM (Dedicated)
    100 GB NVMe/SSD Disk
    1 IPv4 + /64 IPv6
    15TB Premium Bandwidth per month
    DC Location - Poland

    Order Link - US$5 / month
    Order Link - US$38 / YEAR

    AMD Ryzen 5950x we want stock

Sign In or Register to comment.