Howdy, Stranger!

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


Kimsufi FR crappy network - Page 2
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.

Kimsufi FR crappy network

2»

Comments

  • williewillie Member
    edited June 2017

    KS-2E, RBX4 - Rack: 50C1

    ...

    [ 5] 0.0-10.0 sec 104 MBytes 87.4 Mbits/sec

    ...

    [ 4] 0.0-10.2 sec 106 MBytes 87.8 Mbits/sec

    Thanked by 1teamacc
  • TheLinuxBugTheLinuxBug Member
    edited June 2017

    I don't really fully understand the point of this thread -- routing changes constantly, all the time, on all networks and just because the path you have currently may be able to provide full speed, it doesn't mean it will always be like that (it could change ANY TIME). Additionally, this may not even be a routing issue on OVHs side, it could actually be routing on the destination network or possibly even an over saturated link at the time you are testing (on either side).

    Also, I think some people in this thread were trying to make this point -- Kimisufi is a 'fair share' network and there is no where they promise you that you will get 100Mbit to 'everywhere' 'all the time' both because there is absolutely no way to promise that and also because the network is 'fair share' and most likely a single switch may be serving 20 (or more) servers off a single gigabit port.

    This is hugely different from OVH VPS where each hypervisor probably has dual gigabit NICs (or 10Gbit nics), the switch they use is uplinked to 10Gbit instead of 1 Gbit and the contention in the switch they connect to is probably about 15% of what you are seeing on the Kimsufi network. The reason support ignores you is because you have unrealistic expectations if you think that you are going to be able to get '100Mbit all the time' and be able to 'saturate it to locations which are ridiculously far away from their network' especially to networks where peering is more expensive (such as HK, China, SG, Australia, Middle east countries, etc) during peak hours.

    I believe the problem here is you have the wrong expectations for a server located on OVH's cheapest 'fair share network'. This issue could be as simple as you have 19 other people who think like you (expect to be able to use 100% of the line 24/7 and are doing so without consideration for the other users sharing the same uplink) and the poor switch you guys are attached to is over saturated and thus forced to do QOS to even provide network resources reasonably to your servers (resulting in overall slower transfer rates for everyone on that switch, most likely).

    Again, this is different when purchasing their higher tiers of servers because you pay to have a different level of network. I believe on the higher tiers with gigabit they actually do guarantee the ability to burst to 250Mbit (if the destination network will provide it) and this is likely because instead 20 servers sharing a single gigabit uplink now you probably have 20 gigabit server located on a switch with a 10Gbit uplink.. providing much more room for bursting and allows them to better guarantee availability of traffic as when it does start shaping (QOS) it just shapes you down to 250Mbit because its now able to allow higher throughput as there is less contention.

    TL:DR:

    Different tiers of OVH services have different networks and should have different expectations when it comes to throughput, especially to more expensively peered networks during peak hours. Expecting to be able to maintain full 100Mbit uploads 24/7 on a fair-share service is not utilizing the service correctly and is an incorrect expectation. The VPS service comes with completely different connectivity and is probably located on a completely different network with less contention and connected at higher speeds (Dual gigabit or 10Gbit NICs per hypervisor) as the service level provided by the product is much higher than what is promised on Kimsufi.

    Be upset all you want but I think you have the wrong expectations and I think as long as you continue to pursue this they will ignore you because they most likely wish for you to cancel the service than to continue to deal with the support load (and have to tell you you are likely being abusive) on a service which provides little to no guaranteed support and where each ticket you open probably costs them more than you are paying a month for the service.

    my 2 cents.

    Cheers!

  • @TheLinuxBug said:

    I can see where you're coming from, however, they've just upgraded my network on one of my servers to 1gbit instead of the 100mbit, and speeds in the bench.sh benchmark have truly improved, from 200kb/s from HK up to 3mbyte/s from that very same location.

    Furthermore, I had a third kimsufi server for a short while and the speeds on that one were comparable (although capped at 100mbit/s) to this "uncapped" network that I'm currently enjoying.

    I understand that I will never be able to get a full 100mbit to/from everywhere, however, getting the full 100mbit from their own canadian location with the connection never leaving their network should not be a problem, nor should uploading over 5mbyte/s to hetzner, or over 1mbyte/s to moscow.

    To answer your question: The point of this thread is/was not to put pressure on OVH, it was just to investigate if this problem is more wide-spread than just my own setup, and maybe get some solutions I (and google) failed to think of.

    Given that half of the people that have replied so far either told me to not expect to get any decent kind of connection using kimsufi, and the other half showing that they actually do get quite a decent connection, I feel that this thread is slowly fading into some weird place.

    I would therefore request it to be closed, given that it has served it purpose. @elliotJ

  • TheLinuxBugTheLinuxBug Member
    edited June 2017

    teamacc said: To answer your question: The point of this thread is/was not to put pressure on OVH, it was just to investigate if this problem is more wide-spread than just my own setup, and maybe get some solutions I (and google) failed to think of.

    The answer to your question is, the customers who have servers in racks with a higher usage contention (people who expect to be able to use their 100Mbit for torrents, etc 24/7) will end up with slower transfer rates as you will always actively be triggering QOS on the switch. The only solution to your problem would be to be placed on a switch with lower contention, which for the Kimsufi's level of service is not something they can/will realistically do.

    You can think of it the same as a cheap VPS provider here on LET that oversells the shit out of their servers. If you try to put 50 users which are expecting to be able to use 100mbit 24/7 (unmetered) on a server with a single gigabit port your node will constantly be doing QOS to be able to try and provide those users an equal share and will never end up providing what you promised but when the customer complains they will point you to their fair-share policy and just QOS down your noisy neighbors even more (causing those customers to get even slower transfers) to try and provide you better service. In the end though because the usage exceeds the available bandwidth there will never really be a way to resolve this without moving said user to another less populated node.

    You should consider a Kimsufi server to be just like a VPS when it comes down to the shared network aspect -- the more users connected to the switch sharing the bandwidth with you who decide to fully use their bandwidth 24/7, the slower things will get. There just isn't the available bandwidth to allow better and their only possible solution to this is to make QOS more aggressive on other users which if everyone is being abusive really just results in everyone on that switch with slower connectivity.

    I hope this helps to better answer your question.

    my 2 cents.

    Cheers!

  • Closed by request!

This discussion has been closed.