If transfers to or from your VPS are slower than expected, or you see packet loss, these checks narrow down where the problem is. BinaryLane does not filter or shape traffic by content or protocol: there is no QoS, no per-protocol throttling and no traffic inspection. The only filtering is the rules you set in your VPS's External Firewall, and Port Blocking of outgoing TCP ports 22, 25 and 3389 on newly created servers.


TABLE OF CONTENTS



1. Check the MTU first


Large packets can be dropped when the MTU on your server, or on the device or router at your end, is larger than the path between them carries. This shows up most with UDP: TCP negotiates a smaller packet size on its own (MSS clamping), but UDP does not, so full-size packets are fragmented or dropped. If UDP loses packets while TCP to the same server is fine, an MTU mismatch is the usual cause, whether or not the server is in a VPC.

Check the MTU on both ends. The steps to change it on the server are in Why do I need to adjust the MTU size for servers within a VPC?


2. Run traceroutes to and from the looking glass


If you suspect a routing problem, collect these three traceroute reports:

  1. From your own connection to your VPS's IP address.
  2. From your own connection to the BinaryLane looking glass in the same region as your server.
  3. If you can, from that looking glass back to your own connection's public IP address.

Looking glass IP addresses by region:

  • Brisbane: 103.230.157.80
  • Melbourne: 45.124.55.30
  • Perth: 203.29.240.49
  • Sydney: 103.1.187.96
  • Singapore: 103.100.37.6

The looking glass web page for each location is listed in Where are BinaryLane servers located?; use the one in your VPS's region for the third report. The looking glass limits how many tests one address can run in a short time. If it refuses a test, wait an hour and try again.


3. Tools for traceroute reports


  • Windows: WinMTR.
  • Linux: the mtr or traceroute command.


4. Reading the results


An intermediate hop that does not respond is not in itself evidence of packet loss, as long as the hops after it and the destination respond normally.


5. Testing with iperf3


If the problem appears across several regions or from several source networks, check the test method next. For each iperf3 test, record:

  • The exact iperf3 command used on each end, and the complete output from both ends.
  • For UDP tests: the requested bitrate, the UDP datagram (block) size, and the reported jitter and packet-loss figures.
  • Whether the test used a single stream or parallel streams.
  • The iperf3 version on both the client and the server.


Then run a TCP test between the same two endpoints for comparison, and repeat the UDP test at increasing rates, below, around and above the rate where the problem appears, to isolate the cause.


Outbound speed and packet-rate limits


Your VPS's outbound traffic is limited to its plan speed, and separately to about 100 packets per second for each Mbit/s of that speed. Normal traffic does not reach the packet limit; a test that sends very small packets (for example a UDP test with 64-byte datagrams) will, so measure throughput with full-size packets.


If you require assistance, feel free to submit a support ticket at our helpdesk here: Submit a ticket | BinaryLane