MTR is a powerful tool that allows administrators to identify and isolate network errors and to provide network status reports to providers going upstream. MTR represents the emergence of the traceroute command by providing a sample of large data as if enlarging the traceroute with ping output. This document provides an in-depth overview of the MTR, the data generated, and the method of interpreting and reaching conclusions based on the data provided by it.
Network Diagnostics Background #
Network diagnostic tools including ping, traceroute, and mtr use Internet Control Message Protocol (ICMP) packets to monitor contention and traffic between two Internet points. When a user ping a host online, a series of ICMP packets are sent to the host and they respond by sending feedback packets. The user client is then able to calculate travel time and return between two points online.
In contrast, tools such as traceroute and MTR send ICMP packets with TTLs that gradually grow to view the route or series of hops formed by the packet between the source and destination. TTL, or lifetime, controls how many hops a pack will make before “death” and return to host. By sending a series of packets and making them come back after one hop, then two, then three, MTR is able to connect the traffic route between web hosts.
Instead of providing a simple framework for traffic that takes you across the Internet, MTR collects more information about the status, connections, and responses of moderators. Thanks to this additional information, MTR can provide a complete view of the communication between the two hosts online. The following sections explain how to install MTR software and how to interpret the results provided by this tool.
Install MTR #
Linux #
Debian/Ubuntu
apt update && apt upgrade
apt install mtr-tinyCentOS/RHEL/Fedora
yum update
yum install mtrWindows #
For Windows, there is a port of MTR called “WinMTR”. You can download this application from WinMTR upstream.
macOS #
Install MTR on macOS with either Homebrew or MacPorts. To install MTR with Homebrew, run:
Generate an MTR Report #
Because MTR provides a traffic image of a route from one host to another, it is a guiding tool. The route taken between the two points online can vary greatly depending on the location and the routes located at the top of the river. For this reason, it is a good idea to collect MTR reports on both indicators of all hosts experiencing connection problems.
Lectron Customer Support will usually request MTR reports both to or from your Lectron if you experience communication problems. This is because, from time to time, MTR reports will not detect errors on one side if there is still packet loss from the other side.
When referring to MTR reports, this document refers to the host running mtr as the source host and the host hosted by the question as the local host.
Use MTR on Unix-based Systems #
Generate MTR reports using the following syntax:
mtr -rw [destination_host]
For example, to test the route and connection quality of traffic to the destination host example.com
mtr -rw example.com
An MTR report to your Lectron can be run from your local computer. Replace 172.65.215.58 with the IP address of your Lectron:
mtr -rw 172.65.215.58
SSH into your Lectron and collect an MTR report from your Lectron to your home network. Replace 192.168.1.1 with the IP address of your home network.
mtr -rw 192.168.1.1
If you don’t know your home IP address, use WhatIsMyIP.com.
If no packet loss is detected, a support technician may ask you to run a faster interval:
mtr -rwc 50 -rw 192.168.1.1
On some systems, using this flag may require administrative privileges:
sudo mtr -rwc 50 -rw 192.168.1.1Note
The r option flag generates the report (short for --report).
The w option flag uses the long-version of the hostname so our technicians and you can see the full hostname of each hop (short for --report-wide).
The c option flag sets how many packets are sent and recorded in the report. When not used, the default will generally be 10, but, for faster intervals, you may want to set it to 50 or 100. The report can take longer to finish when doing this.
Use MTR on Windows Systems #
Using MTR on Windows uses the GUI. Open WinMTR, type the host in the box as instructed, and select the first option to start generating report data. You will need to use the Linux version of the MTR as shown above to generate the MTR report on your Lectron.
Read MTR Reports #
Because MTR reports contain a great deal of information, they can be difficult to interpret at first. The following example is a report from a local connection to google.com :
$ mtr --report google.com
HOST: example Loss% Snt Last Avg Best Wrst StDev
1. inner-cake 0.0% 10 2.8 2.1 1.9 2.8 0.3
2. outer-cake 0.0% 10 3.2 2.6 2.4 3.2 0.3
3. 68.85.118.13 0.0% 10 9.8 12.2 8.7 18.2 3.0
4. po-20-ar01.absecon.nj.panjde 0.0% 10 10.2 10.4 8.9 14.2 1.6
5. be-30-crs01.audubon.nj.panjd 0.0% 10 10.8 12.2 10.1 16.6 1.7
6. pos-0-12-0-0-ar01.plainfield 0.0% 10 13.4 14.6 12.6 21.6 2.6
7. pos-0-6-0-0-cr01.newyork.ny. 0.0% 10 15.2 15.3 13.9 18.2 1.3
8. pos-0-4-0-0-pe01.111eighthav 0.0% 10 16.5 16.2 14.5 19.3 1.3
9. as15169-3.111eighthave.ny.ib 0.0% 10 16.0 17.1 14.2 27.7 3.9
10. 72.14.238.232 0.0% 10 19.1 22.0 13.9 43.3 11.1
11. 209.85.241.148 0.0% 10 15.1 16.2 14.8 20.2 1.6
12. lga15s02-in-f104.1e100.net 0.0% 10 15.6 16.9 15.2 20.6 1.7Report created with mtr –report google.com. This uses the reporting option, which sends 10 packets to the google.com host and generates a report. Without the option – report, mtr will work continuously in the workspace. Collaborative mode shows the current travel and return times for each host. In most cases, the –report mode provides sufficient data in a useful format.
Each numbered line in the report represents hop. Hops Internet packages go through it to get to their destination. The names of the hosts (e.g. “internal cake” and “outer cake” in the example) are determined by the DNS lookups. If you want to leave the rDNS view you can use the – and dns option, which produces output such as the following:
% mtr --no-dns --report google.com
HOST: deleuze Loss% Snt Last Avg Best Wrst StDev
1. 192.168.1.1 0.0% 10 2.2 2.2 2.0 2.7 0.2
2. 68.85.118.13 0.0% 10 8.6 11.0 8.4 17.8 3.0
3. 68.86.210.126 0.0% 10 9.1 12.1 8.5 24.3 5.2
4. 68.86.208.22 0.0% 10 12.2 15.1 11.7 23.4 4.4
5. 68.85.192.86 0.0% 10 17.2 14.8 13.2 17.2 1.3
6. 68.86.90.25 0.0% 10 14.2 16.4 14.2 20.3 1.9
7. 68.86.86.194 0.0% 10 17.6 16.8 15.5 18.1 0.9
8. 75.149.230.194 0.0% 10 15.0 20.1 15.0 33.8 5.6
9. 72.14.238.232 0.0% 10 15.6 18.7 14.1 32.8 5.9
10. 209.85.241.148 0.0% 10 16.3 16.9 14.7 21.2 2.2
11. 66.249.91.104 0.0% 10 22.2 18.6 14.2 36.0 6.5In addition to seeing the path between servers taken by packets to reach their host, the MTR provides important statistics about the strength of that connection in the next seven columns. Loss Column% shows the percentage of packet loss in each hop. Snt column counts the number of packets sent. Option -report will send 10 packets except specified –report-cycles = [packet-number], where [packet-number] represents the total number of packets you want to send to the remote host.
The next four columns Last, Medium, Best, and Wrst are all in milliseconds of delay (e.g. ms). Lastly the last packet sent delay, Avg is the intermediate delay of all packets, while the Best and worst show the best (shortest) and worst (longest) travel and return time packages to this host. In most cases, the middle column (Avg) should be your focus.
The last column, StDev, provides a standard deviation of latencies for each host. The higher the standard deviation, the greater the difference between the delay rates. The standard deviation allows you to check whether the given rating (rating) represents the actual center of the data set, or is distorted by some type of event or measurement error. If the normal deviation was high, the delay rates were inconsistent. After measuring the delay of 10 packets sent, the measure looks normal but does not actually represent the data properly. If the standard deviation is high, look for the best and worst delay ratings to make sure the rating is a good representation of the actual delay and not the result of major fluctuations.
In most cases, you can consider the release of MTR in three major phases. Depending on the configuration, the first 2 or 3 hops usually represent the ISP of the source host, while the last 2 or 3 hops represent the ISP of the local host. Mid-range routers are a passing package to get to their destination.
For example, if MTR is used from your home PC to your Lectron, the first 2 or 3 hops belong to your ISP. The last 3 hops belong to the data center where your Lectron resides. Any medium hops are medium hops. If you are using MTR locally, if you notice a rare occurrence in the first few hop near the source, contact your local service provider or investigate your local network configuration. Conversely, if you see something unusual near your destination you may want to contact your local server operator or network support for that device. Unfortunately, in cases where there are problems with medium hops, both service providers will have limited ability to resolve the issue.
Analyze MTR Reports #
Verify Packet Loss #
When analyzing MTR output, you want two things: loss and delay. If you see a percentage loss on any particular hop, that could be an indication that there is a problem with that router. However, it is a common practice among some service providers to measure the ICMP traffic limit used by the MTR. This can give the illusion of packet loss when in fact there is no loss. To determine if the loss you are experiencing is real or is due to a limit, see the following hop. If that hop shows a 0.0% loss, then you may be seeing the ICMP level limit and not the actual loss:
root@localhost:~# mtr --report www.google.com
HOST: example Loss% Snt Last Avg Best Wrst StDev
1. 63.247.74.43 0.0% 10 0.3 0.6 0.3 1.2 0.3
2. 63.247.64.157 50.0% 10 0.4 1.0 0.4 6.1 1.8
3. 209.51.130.213 0.0% 10 0.8 2.7 0.8 19.0 5.7
4. aix.pr1.atl.google.com 0.0% 10 6.7 6.8 6.7 6.9 0.1
5. 72.14.233.56 0.0% 10 7.2 8.3 7.1 16.4 2.9
6. 209.85.254.247 0.0% 10 39.1 39.4 39.1 39.7 0.2
7. 64.233.174.46 0.0% 10 39.6 40.4 39.4 46.9 2.3
8. gw-in-f147.1e100.net 0.0% 10 39.6 40.5 39.5 46.7 2.2In this case, the loss reported between hops 1 and 2 is likely due to rate limiting on the second hop. Although traffic to the remaining eight hops all touch the second hop, there is no packet loss. If the loss continues for more than one hop, than it is possible that there is some packet loss or routing issues. Remember that rate limiting and loss can happen concurrently. In this case, take the lowest percentage of loss in a sequence as the actual loss:
root@localhost:~# mtr --report www.google.com
HOST: localhost Loss% Snt Last Avg Best Wrst StDev
1. 63.247.74.43 0.0% 10 0.3 0.6 0.3 1.2 0.3
2. 63.247.64.157 0.0% 10 0.4 1.0 0.4 6.1 1.8
3. 209.51.130.213 60.0% 10 0.8 2.7 0.8 19.0 5.7
4. aix.pr1.atl.google.com 60.0% 10 6.7 6.8 6.7 6.9 0.1
5. 72.14.233.56 50.0% 10 7.2 8.3 7.1 16.4 2.9
6. 209.85.254.247 40.0% 10 39.1 39.4 39.1 39.7 0.2
7. 64.233.174.46 40.0% 10 39.6 40.4 39.4 46.9 2.3
8. gw-in-f147.1e100.net 40.0% 10 39.6 40.5 39.5 46.7 2.2In this case, there is a 60% loss between 2 and 3 hops and between 3 and 4 hops. You would think that the third and fourth hop may lose a certain amount of traffic because no future host reports that the egg has lost. However, some losses are due to standard restrictions as the last few hops lose 40%. If different loss rates are reported, always rely on reports from the latest hops.
Other losses can also be attributed to problems on the return route. The packages will arrive at their destination without error but have difficulty making the return trip. For this reason, it is often best to collect MTR reports in both directions when you have a problem.
Resist the temptation to investigate or report all cases of packet loss to your contacts. Internet protocols are designed to withstand certain network vulnerabilities, and routes the data they download across the internet can fluctuate due to uploads, short fix events, and other router issues. If your MTR report shows small losses in the area of 10%, there is no reason to worry as the application layer will compensate for possible temporary losses.
Network Latency #
In addition to helping you check for packet loss, MTR will also help check for communication delays between your host and the targeted host. Due to physical problems, the delay is always increased by the number of hops on the track. However, the increase should be consistent and consistent. Unfortunately, delays are often related and largely dependent on the quality of both the host and their physical distance. When examining MTR reports for potentially problematic communications, consider previous reports that work more fully as a context than the known connection speeds among other hosts.
Connection quality may also affect the amount of delay you receive on a particular route. Predictably, dial connections will have significantly higher delays than cable modem connections in the same location. The following MTR report shows high delays:
root@localhost:~# mtr --report www.google.com
HOST: localhost Loss% Snt Last Avg Best Wrst StDev
1. 63.247.74.43 0.0% 10 0.3 0.6 0.3 1.2 0.3
2. 63.247.64.157 0.0% 10 0.4 1.0 0.4 6.1 1.8
3. 209.51.130.213 0.0% 10 0.8 2.7 0.8 19.0 5.7
4. aix.pr1.atl.google.com 0.0% 10 388.0 360.4 342.1 396.7 0.2
5. 72.14.233.56 0.0% 10 390.6 360.4 342.1 396.7 0.2
6. 209.85.254.247 0.0% 10 391.6 360.4 342.1 396.7 0.4
7. 64.233.174.46 0.0% 10 391.8 360.4 342.1 396.7 2.1
8. gw-in-f147.1e100.net 0.0% 10 392.0 360.4 342.1 396.7 1.2The latency value exceeds the maximum between 3 and 4 hops and remains high. This may refer to the problem of network delays as turnaround times remain high after the fourth hop. From this report, it is impossible to pinpoint the cause even though a full viewing session, a poorly prepared router, or a crowded link are common causes.
Unfortunately, high delays do not always mean a problem with the current route. A report like the one above says that despite some problems with 4th hop, traffic still reaches the local host and returns to the source host. Delays may be caused by a problem with the return route as well. The return route will not appear in your MTR report, and packages may take completely different routes to and from a specific location.
In the example above, although there is a large wait jump between hosts 3 and 4 the delay does not rise sharply in any subsequent hop. In this case, it is reasonable to assume that there is something wrong with the 4th rack.
Decreasing the ICMP level may also result in the appearance of delays, such as how it may cause the appearance of packet loss:
root@localhost:~# mtr --report www.google.com
HOST: localhost Loss% Snt Last Avg Best Wrst StDev
1. 63.247.74.43 0.0% 10 0.3 0.6 0.3 1.2 0.3
2. 63.247.64.157 0.0% 10 0.4 1.0 0.4 6.1 1.8
3. 209.51.130.213 0.0% 10 0.8 2.7 0.8 19.0 5.7
4. aix.pr1.atl.google.com 0.0% 10 6.7 6.8 6.7 6.9 0.1
5. 72.14.233.56 0.0% 10 254.2 250.3 230.1 263.4 2.9
6. 209.85.254.247 0.0% 10 39.1 39.4 39.1 39.7 0.2
7. 64.233.174.46 0.0% 10 39.6 40.4 39.4 46.9 2.3
8. gw-in-f147.1e100.net 0.0% 10 39.6 40.5 39.5 46.7 2.2At first glance, thAt first glance, a delay between 4 and 5 hops draws attention. However, after the fifth hop, latency dropped dramatically. The actual delay measured here is about 40ms. In such cases, the MTR draws attention to a matter that does not affect the service. Consider the last hop delay when reviewing the MTR report.
Common MTR Reports #
Some networking issues are novel and require escalation to the operators of the upstream networks. However, there are a number of common MTR reports that describe common networking issues. If you’re experiencing some sort of networking issue and want to diagnose your problem, consider the following examples.
Destination Host Networking Improperly Configured #
In the next example, it appears that there is 100% loss to the destination host because of an incorrectly configured router. At first glance, it appears that the packets are not reaching the host but this is not the case.
root@localhost:~# mtr --report www.google.com
HOST: localhost Loss% Snt Last Avg Best Wrst StDev
1. 63.247.74.43 0.0% 10 0.3 0.6 0.3 1.2 0.3
2. 63.247.64.157 0.0% 10 0.4 1.0 0.4 6.1 1.8
3. 209.51.130.213 0.0% 10 0.8 2.7 0.8 19.0 5.7
4. aix.pr1.atl.google.com 0.0% 10 6.7 6.8 6.7 6.9 0.1
5. 72.14.233.56 0.0% 10 7.2 8.3 7.1 16.4 2.9
6. 209.85.254.247 0.0% 10 39.1 39.4 39.1 39.7 0.2
7. 64.233.174.46 0.0% 10 39.6 40.4 39.4 46.9 2.3
8. gw-in-f147.1e100.net 100.0 10 0.0 0.0 0.0 0.0 0.0Traffic arrives at the local host. However, the MTR report shows a loss because the local host is not sending a response. This may be the result of improperly configured network rules or a firewall (iptables) that causes the host to discard ICMP packets.
The way you can see that the loss is due to a host not well-prepared to watch hop shows of 100% loss. From previous reports, you can see that this is the last hop and that MTR is not trying more hops. Although it is difficult to diagnose this problem without a basic measure, these types of errors are very common.
Residential or Business Router #
Residential gateways sometimes cause misleading reports:
% mtr --no-dns --report google.com
HOST: deleuze Loss% Snt Last Avg Best Wrst StDev
1. 192.168.1.1 0.0% 10 2.2 2.2 2.0 2.7 0.2
2. ??? 100.0 10 8.6 11.0 8.4 17.8 3.0
3. 68.86.210.126 0.0% 10 9.1 12.1 8.5 24.3 5.2
4. 68.86.208.22 0.0% 10 12.2 15.1 11.7 23.4 4.4
5. 68.85.192.86 0.0% 10 17.2 14.8 13.2 17.2 1.3
6. 68.86.90.25 0.0% 10 14.2 16.4 14.2 20.3 1.9
7. 68.86.86.194 0.0% 10 17.6 16.8 15.5 18.1 0.9
8. 75.149.230.194 0.0% 10 15.0 20.1 15.0 33.8 5.6
9. 72.14.238.232 0.0% 10 15.6 18.7 14.1 32.8 5.9
10. 209.85.241.148 0.0% 10 16.3 16.9 14.7 21.2 2.2
11. 66.249.91.104 0.0% 10 22.2 18.6 14.2 36.0 6.5The 100% loss reported at the second hop does not indicate that there is a problem. You can see that there is no loss on subsequent hops.
An ISP Router Is Not Configured Properly #
Sometimes a router on the route your packet takes is incorrectly configured and your packets may never reach their destination:
root@localhost:~# mtr --report www.google.com
HOST: localhost Loss% Snt Last Avg Best Wrst StDev
1. 63.247.74.43 0.0% 10 0.3 0.6 0.3 1.2 0.3
2. 63.247.64.157 0.0% 10 0.4 1.0 0.4 6.1 1.8
3. 209.51.130.213 0.0% 10 0.8 2.7 0.8 19.0 5.7
4. aix.pr1.atl.google.com 0.0% 10 6.7 6.8 6.7 6.9 0.1
5. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0
6. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0
7. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0
8. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0
9. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0
10. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0The question marks appear when there is no additional route information. Sometimes, a poorly configured router will send packets in a loop. You can see that in the following example:
root@localhost:~# mtr --report www.google.com
HOST: localhost Loss% Snt Last Avg Best Wrst StDev
1. 63.247.74.43 0.0% 10 0.3 0.6 0.3 1.2 0.3
2. 63.247.64.157 0.0% 10 0.4 1.0 0.4 6.1 1.8
3. 209.51.130.213 0.0% 10 0.8 2.7 0.8 19.0 5.7
4. aix.pr1.atl.google.com 0.0% 10 6.7 6.8 6.7 6.9 0.1
5. 12.34.56.79 0.0% 10 0.0 0.0 0.0 0.0 0.0
6. 12.34.56.78 0.0% 10 0.0 0.0 0.0 0.0 0.0
7. 12.34.56.79 0.0% 10 0.0 0.0 0.0 0.0 0.0
8. 12.34.56.78 0.0% 10 0.0 0.0 0.0 0.0 0.0
9. 12.34.56.79 0.0% 10 0.0 0.0 0.0 0.0 0.0
10. 12.34.56.78 0.0% 10 0.0 0.0 0.0 0.0 0.0
11. 12.34.56.79 0.0% 10 0.0 0.0 0.0 0.0 0.0
12. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0
13. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0
14. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0These reports show that the router at hop 4 is not properly configured. When these situations occur, the only way to resolve the issue is to contact the network administrator’s team of operators at the source host.
ICMP Rate Limiting #
ICMP rate limiting can cause apparent packet loss. When there is packet loss to one hop that doesn’t persist to subsequent hops, the loss is caused by ICMP limiting. See the following example:
root@localhost:~# mtr --report www.google.com
HOST: localhost Loss% Snt Last Avg Best Wrst StDev
1. 63.247.74.43 0.0% 10 0.3 0.6 0.3 1.2 0.3
2. 63.247.64.157 0.0% 10 0.4 1.0 0.4 6.1 1.8
3. 209.51.130.213 0.0% 10 0.8 2.7 0.8 19.0 5.7
4. aix.pr1.atl.google.com 0.0% 10 6.7 6.8 6.7 6.9 0.1
5. 72.14.233.56 60.0% 10 27.2 25.3 23.1 26.4 2.9
6. 209.85.254.247 0.0% 10 39.1 39.4 39.1 39.7 0.2
7. 64.233.174.46 0.0% 10 39.6 40.4 39.4 46.9 2.3
8. gw-in-f147.1e100.net 0.0% 10 39.6 40.5 39.5 46.7 2.2This report does not show a cause for concern. Rate limiting is a common practice and it reduces congestion to prioritize more important traffic.
Timeouts #
Timeouts can happen for various reasons. Some routers will discard ICMP and absent replies will be shown on the output as timeouts (???). Alternatively, there may be a problem with the return route:
root@localhost:~# mtr --report www.google.com
HOST: localhost Loss% Snt Last Avg Best Wrst StDev
1. 63.247.74.43 0.0% 10 0.3 0.6 0.3 1.2 0.3
2. 63.247.64.157 0.0% 10 0.4 1.0 0.4 6.1 1.8
3. 209.51.130.213 0.0% 10 0.8 2.7 0.8 19.0 5.7
4. aix.pr1.atl.google.com 0.0% 10 6.7 6.8 6.7 6.9 0.1
5. ??? 0.0% 10 7.2 8.3 7.1 16.4 2.9
6. ??? 0.0% 10 39.1 39.4 39.1 39.7 0.2
7. 64.233.174.46 0.0% 10 39.6 40.4 39.4 46.9 2.3
8. gw-in-f147.1e100.net 0.0% 10 39.6 40.5 39.5 46.7 2.2Timeouts are not necessarily an indication of packet loss. Packets still reach their destination without significant packet loss or latency. Timeouts may be attributable to routers dropping packets for QoS (quality of service) purposes or there may be some issue with return routes causing the timeouts. This is another false positive.
Advanced MTR techniques #
Newer MTR versions are now able to work with TCP mode in a specific TCP port, compared to the default use of the ICMP (ping) protocol. However, in most cases this mode should not be used as TCP reports can be misleading in diagnosing intermediate routes. TCP MTR will use SYN packets instead of ICMP pings, and many internet level routers will not respond to this, indicating an error loss.
A useful feature of the TCP test is to determine whether the rules of the route protection system in a particular area restrict a protocol or port, possibly because port transfers are not properly configured. Implementing a TCP test over a certain hole may reveal this more clearly while the ICMP test may not be possible.
Running MTR in TCP mode will require super-user privileges on most machines:
sudo mtr --tcp --port 80 --report --report-cycles 10 speedtest.dallas.lectron.com
sudo mtr --tcp --port 22 --report --report-cycles 10 50.116.25.154
Resolve Routing and Networking Issues Identified in your MTR report #
Most of the route problems shown by the MTR reports are temporary. Most problems will resolve on their own within 24 hours. In most cases, while you can detect a problem with the router, the Internet service provider’s watchdog has already reported the problem and administrators are working to fix the problem. In cases where you experience a long-term reduced service, you may choose to notify the provider of any problems you are experiencing. When you contact a service provider, send MTR reports and any other relevant data you may have. Apart from usable data, providers have no way to verify or fix problems.
Although routing errors and problems make up the percentage of network-related speeds, they are by no means the only cause of malfunction. Network congestion, especially over long distances at very high altitudes, can be very serious. Trans-Atlantic and trans-Pacific traffic can fluctuate and are subject to normal network congestion. In these cases, it is recommended that you place strangers and equipment close to the area and their target audience as much as possible.
