Sign in to follow this  
Skula1975

Info: connection losses, high ping and related issues

Recommended Posts

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?

  1. 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.
  2. 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.
  3. 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 :)
  4. 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.
  • Like 2
  • Confused 1
  • Sad 1
  • Upvote 2

Share this post


Link to post
Share on other sites

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

Картинка 1.png

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.exe
Type:

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:
 
 
1Run 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.
 
2Run 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

  • Like 1
  • Upvote 3

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.