Why does Frankfurt IP 35.198.121.205 give better latency to/from Singapore vs 35.198.121.166 ?

[JAsOk]

I did a traceroute / MTR for both of them and they both appear to be using Premium network and are going through the exact same hops.

35.198.121.205 - average 156ms from SG
35.198.121.166 - average 225ms from SG

Both appear to be in Frankfurt going by their IP address geo location

I am looking to start a E2 VM with 156ms latency in region Frankfurt europe-west3 for personal reasons. But all the VMs I start in Frankfurt give 230ms from SG and I am trying to get the 156ms one. What could be the reason? I tried all the Frankfurt zones A, B and C.

I also tried starting with Standard network settings in zones A, B and C and the results are worse (300ms+).

[Marvin_Lucero]

Hi @JAsOk ,

Double check the latency on your console under Network Intelligence > Performance Dashboard. Check for packet loss under "Average packet loss between region pairs".

We cannot really tell the reason for the latency, unless a support from Google Cloud will be able to check further on your project and run some testing, and check the related logs. However, for you to improve and optimize the latency, let me give you a brief overview about it. When optimizing for latency, many system architects consider only network latency or distance between the user's ISP and the virtual machine instance. However, this is only one of many factors affecting user latency.

Region selection can only affect the latency to the Compute Engine region and not the entirety of the latency. Depending on the use case, this might be only a small part of overall latency. For example, if your users are primarily using cellular networks, it might not be valuable to try to optimize your regions, as this hardly affects total user latency. We can optimize the region selection and app latency, but have no control over the users' last mile and latency to the closest Google edge Points of Presence (POP).

Make sure to take inter regional topology into consideration when deciding which regions to deploy in. For example, if you want to deploy an app with a global user base in a single region, it is usually best to have this app hosted in one of the US regions–because the US is connected to most other regions. Although there is direct connectivity between many continents, there are cases where it is missing, for instance, between Europe and Asia, so traffic between Europe and Asia flows through the US.

If your VM is hosted across multiple regions and you need to synchronize data, be aware of latency between those regions. While this latency can change over time, it is usually stable. Either measure latency yourself by bringing up test instances in all potential regions or use third-party websites to get an idea of current latencies between regions.