Skula1975 218 Report post Posted May 17, 2017 What to do and whom to blame for the high ping and package losses Short version Whom to blame: one of the units on the route from the client application to its server part. What to do: To solve or to get round the trouble with the unit or to wait till it's solved by itself. Long version Lets take a look of the scheme of the common route between the user, who seeks truth, and the server. On the scheme: digits - "a number" of the next "hop" (retranslator, router) in the route chain. "ISP" - Internet Service Provider. "Home router" - Wi-Fi router of the user. "|" - channel (link) between the units of the route. All the units on the route of packages of the client-server application (Crossout, Star Conflict, etc.) are shown as digits in the first column. Spoiler 0 [Application-client on the user's PC] | 2 [Home router] | 3 [ISP uplinks] | .. the unpredictable Internet | 7 [Data center's uplinks] | 8 Data center | 9 Server The closer the problem is to one or another side - the more is the responsibility of this side to solve it. Whom to blame? It is possible to find the problem segment of the route by using diagnostic utilities. Almost every modern OS has such utilities "out-of-the-box". Of course, it's also possible to find different analogs in the Internet. Here we are going to use pathping - a console utility that is included in Windows. Spoiler pathping -n 219.18.15.139 We advise to use the key -n. Sometimes it happens so, that pathping stops to work if can't resolve the problem. If you want to resolve hosts on the route (and it's recommended to do it) you can use pathping alongside with the utility traceroute (for example), that is launched in another window. The result of pathping's work consists of three parts: First of all, the route is revealed (just like when you're using traceroute). There's nothing valuable there. Then, each unit on the route is "pinged" with 100 packages, the statistics is gathered and the calculations are made. The result of these calculations are main thing that is valuable in this utility. It's necessary to stay patient and wait till the end of the utility's work. Gathering of the statistics can take some time, depending on the number of transitional hosts. Finally, your patience will be rewarded with the more wide variant of traceroute: Spoiler Hop - Number of the unit (host) on the route, just like in traceroute Primal unit - Latencies (RTT) and losses (Lost/Sent, %) on the route to the unit - these are just the results of the ping to this unit. RTT stands for Road Trip Time (the calculation includes time that takes the package to move further and back) Route unit - that's where all the interesting starts. All the numbers of losses in this column are calculated and based on the statistics. This numbers show the particular place where the genocide of the packages occurs and which unit or link is responsible for that. The unite may be overloaded (CPU of the common Chinese router is not enough), the channel between two links may be overloaded (queues to send or to receive the packages may be way too long) or there may be some physical damage on the line. Unfortunately, it's impossible to find out for sure, who is guilty. The more the problem is away from us - the less chances we have. The Internet is much more complicated than it seems. The fact that two hosts in one sub-network are different only in 1 digit (1.1.1.1 vs 1.1.1.2), doesn't mean that they are located in the same data center. They can be virtual machines or servers, that are located in different countries and are connected on low network level with a group of reserves channels that belong to a bunch of partner networks. What to do? When losses of the packages and high latency are located on your side. In this situation all the responsibility lies on you. You have to solve the problem by yourself or using some help on the forum. When losses of the packages and high latency start from the provider's channel and his uplinks. You have to solve the problem with your provider. When losses of the packages and high latency are located somewhere in the Internet (right after the third "hop"). You have almost no variants to choose from. Usually there are some massive units, that posess some reserved links. And usually connection losses occur because of the rebuilding of routing tables or reconnection to the reserved link. What can you do? Just relax Everything will be alright in 24 hours. You are not the only person who suffers, and it's necessary for the unit to be up as fast as possible. You can go to your friends or somewhere else to find the Internet (provider should be different from yours) and check the quality of the route there. Then choose the provider with the most advantageous route. Change your provider and enjoy till the 3rd option happens again When losses of the packages and high latency start from uplinks of the data center of the server. Probably we are already aware of this problem and are working on it. Nevertheless, you can push us, but only with pathping or traceroute reports attached, at least. 2 1 1 2 Share this post Link to post Share on other sites
BjKalderon 3,104 Report post Posted May 18, 2017 Testing the connection to the current game server Option A: Running tests manually This option should only be used when it is not possible to use the automated windows script (Option B). 1. Find the IP address of the current server from the active game.log file located here: Quote 1. For Win XP: {drive}: \Documents and Settings {username} \My Documents\My MyGames\StarConflict\logs\ 2. For Win Vista/7: {drive}:/Users/{username} \Documents\My Games\StarConflict\logs\ Linux: ~/.local/share/starconflict/logs/MAC OS: Users\<user>\Library\Application Support\Star Conflict\logs\ Navigate to the log folder (direcotry shown above), sort the content by date and open the newest folder. For example: ...My Games\Crossout\logs\2015.10.09 22.18.55 There may be several directories with the same date, therefore it is required to look for the the time as well. Open the file: game.log Search the game.log for the string: client: connected to There may be several strings. You need the last one. If you did not play a battle (some map) yet, there will be no such string for today's game.log An example of the string: 12:21:54.115 | client: connected to 219.18.15.139|35004, setting up session... Server IP address: 219.18.15.139 Attention! This IP written for example only! You should find real current server IP in the game logs! If you searched while being in battle, then the IP will be shown from the current server. If you searched immediately after the end of the battle, then the IP will be shown from the last server you played on. Servers can vary from battle to battle. 2. Checking latencies and packet losses: Pefroming the server check with WinMTR Wait for WinMtr to work for 30 seconds and the window screenshot. 2.3 Performing the MTU check Use the ping command with the -f -l 1472 parameters (here l - is the English L (el). case sensitive)Click "Start" and run cmd.exeType: Quote ping -f -l 1472 <IP address of the dedicated server> here l - is the lowcase L (el).Obtain the server address by one of the methods mentioned above For example: Quote ping -f -l 1472 11.222.333.444 If the MTU is "squeezed", you will see the message: Quote require packet fragmentation, but prohibiting flag is set. require packet fragmentation, but prohibiting flag is set. require packet fragmentation, but prohibiting flag is set. ... 2.4. Make a screenshot. Option B: Using the script (Windows 7 and above) Download con_tester and navigate to the main directory In this directory you will find two scripts: - XO_Active_Srv_nettest.cmd - main script - PacketLoss_Trapper.cmd - additional script that starts with the main script After executing the main script, it will expect an entry in the game.log with the server IP address. This entry only appears if your ship ever departures on the map today If you did not play a battle yet, there will be no such string. And the script will wait until a battle is started. If you played at least one battle, the last server address will be used. If there are multiple enties, the last one will be used: 1. Run tests Instantly via the current (latest) server 'Instantly' - means tests will be performed immediately after running a script, unlike the other script in paragraph 2. (below) Run XO_Active_Srv_nettest.cmd If you run the script while being in battle, the current server will be checked. If you run the script being in the hangar, the last server you played on will be used. Window will be opened with testing procedure of the current (latest) server : Quote ********************************************************* 0:29:18 2014-12-10 (Wed Dec 2014) RTZ 2 (чшьр) UTC+03:00 GameServer [US]219.18.15.139 WinMTR.exe or Windows utilites will launch (ping, pathping, tracert) Quote --------------------------------------------------------- [INFO] checking minimum MTU value with 1000byte, not-fragmented packets... Обмен пакетами с 5.178.86.27 по с 1000 байтами данных: Ответ от 5.178.86.27: число байт=1000 время=48мс TTL=58 Ответ от 5.178.86.27: число байт=1000 время=47мс TTL=58 ... --------------------------------------------------------- [INFO] Testing route path... Трассировка маршрута к 91.230.61.167 с максимальным числом прыжков 30 1 2 ms 1 ms 1 ms 192.168.1.1 2 11 ms 5 ms 7 ms 187.24.238.1 3 * 2 ms 2 ms 95.54.92.82 4 30 ms 30 ms 29 ms 95.167.92.31 5 43 ms 42 ms 58 ms 81.91.186.66 6 42 ms 42 ms 44 ms 91.230.61.167 Трассировка завершена. Post a screenshot of the results and attach the game logs. 2. Run the script in monitor mode: automatically run tests on high packet loss detection. PacketLoss_Trapper.cmd Use this script when you want to keep track of the deteriorations of the connection. When you run the script, it starts monitoring the game.log for records on the communication with the server. Use this script when you want to keep track of the link quality to the server. It will immediately run tracert and ping on packet loss above 10% : Spoiler Waiting for DS server record in game.log play any map to continue or press CtrlC to exit...DS record found Monitoring game.log for packet loss record >10% at 1 seconds intervals Once the deterioration is detected (packet loss > 10%), it starts tracert and modified ping utility toserver. Each one in its own window. Each line in pings window shows: average delay, packet loss, number of packets sent (the percentage of losses): Spoiler 0:48:39 2014-12-10 (Wed Dec 2014) RTZ 2 (чшьр) UTC+03:00 Pinging current server. Press Ctrl-C to exit or just close this window [ 0:48:47] 91.230.61.167: avg:42ms lost:0/8 (0%) [ 0:48:55] 91.230.61.167: avg:42ms lost:0/8 (0%) [ 0:49:03] 91.230.61.167: avg:42ms lost:0/8 (0%) In the second window you will see tracert in a loop. Spoiler 0:48:38 2014-12-10 (Wed Dec 2014) RTZ 2 (чшьр) UTC+03:00 Tracing current server. Log file is: nettest-tracing.15.12.2014.log [ 0:48:38] Run 1. Collecting tracing data. Press Ctrl-C to abort... Трассировка маршрута к 91.230.61.167 с максимальным числом прыжков 30 1 2 ms 1 ms 1 ms 192.168.1.1 2 11 ms 5 ms 7 ms 187.24.238.1 3 * 2 ms 2 ms 95.54.92.82 4 30 ms 30 ms 29 ms 95.167.92.31 5 43 ms 42 ms 58 ms 81.91.186.66 6 42 ms 42 ms 44 ms 91.230.61.167 Трассировка завершена. [ 0:48:53] Run 2. Collecting tracing data. Press Ctrl-C to abort... Трассировка маршрута к 91.230.61.167 с максимальным числом прыжков 30 Both utilities will run in a loop. Let them run for at least a minute to collect enough statistics. To stop utilities, in each window press Ctrl + C and confirm the completion. If the problem has been identified and is visible, take a screenshot and proceed as stated above The utility detects the switching of the game servers and will determine the correct one for the next test. Therefore, you can play and keep the script running in background. Don't worry, you won't miss any important information. The script keeps a log file of all traces (see below). Every tracert run is logged into the file named nettest-tracing.<current date>.log The results of the ping utility will not be saved in the log file. This way you can play a lot of battles in a row and view the content of the log file. If a problem is detected, attach the screenshots and the log file. If you do not see a problem in the screenshots (but there is a log file) - only attach the log. Screenshots are only needed for convenience when watching posts on the Forum. con_tester-0.4.3.1.zip WinMTR-v092.zip 1 3 Share this post Link to post Share on other sites
