i need every time atleast 3 times try to connect after triangulation
[game.log](< base_url >/applications/core/interface/file/attachment.php?id=9217)
[game.net.log](< base_url >/applications/core/interface/file/attachment.php?id=9218)
As of this post, there is currently no problem server side. Could be a problem on the route to our server but from the server side there is no network error.
You could try [this.](< base_url >/index.php?/topic/25324-info-connection-losses-high-ping-and-related-issues/?p=316704)
I have the same issues.
also, after the disconnected message I get a prompt if I would like to reconnect. I always answer with ‘yes’ but am never successfully re-connected. When I then invoke a game again it works (either pvp or pve) most of the time, until it happens again at seemingly random intervals.
It always happens during triangulation (on average every 1 out of 10 games). Once in the game it appears to be stable.
I am permanently connected to the internet wit a high-speed connection (56 Mbps) and have no connectivity issues with any other applications.
I am also running a terminal window on a second screen and did a ping to the game server that I was connected to during triangulation as per game.log.
I did a ping when the disconnect message (before the prompt to re-connect and again after the reconnect failed.
In both cases the ping was successful.
This is from where I got the IP in game.log:
18:45:58.996 WARNING| MasterServerEndpoint: leave matchmaking queue ( but will join the game soon )
18:46:01.839 WARNING| m_bufferizedUICalls delivery took 31.1 ms
18:46:02.383 | MasterServerSession: connect to dedicated server, session 11393332, at addr 159.8.55.4|35000
18:46:02.394 | client: start connecting to 159.8.55.4|35000…
18:46:02.539 | client: connected to 159.8.55.4|35000, MTU 1492. setting up session… <--------------------------------------- IP -----------------------------
18:46:02.638 | client. send version check message
18:46:17.373 WARNING| client: couldn’t connect by timeout (frameTimeReal = 0.030114)
18:46:17.373 | client: avgPing 0.0/0.0; avgPacketLoss 0.0/0.0%; avgSnapshotLoss 0.0/0.0%
18:46:17.373 | client: connection closed. DR_CLIENT_COULD_NOT_CONNECT
18:46:17.373 | Network stats (bytes per second): avg pushed 1, max pushed 3, avg sent 37, max sent 61, avg received 76, max received 145
18:46:17.482 WARNING| frame 3238 gameGlobals.frameTimeReal is too large (0.101975)
18:46:29.231 | SN_PLAYER_BOUGHT_PREMIUM_VESSEL: filtered due to notificationRank = 3 and myRank = 9
18:46:44.681 | GameApp shutdown
18:46:44.685 | disconnected from masterServer with reason 41
18:46:44.685 | Closed connection with masterServer addr 5.153.37.199:3802, reason 41
This is the ping result:
~: ping 159.8.55.4
PING 159.8.55.4 (159.8.55.4): 56 data bytes
64 bytes from 159.8.55.4: icmp_seq=0 ttl=52 time=34.576 ms
64 bytes from 159.8.55.4: icmp_seq=1 ttl=52 time=35.058 ms
64 bytes from 159.8.55.4: icmp_seq=2 ttl=52 time=36.338 ms
64 bytes from 159.8.55.4: icmp_seq=3 ttl=52 time=36.011 ms
64 bytes from 159.8.55.4: icmp_seq=4 ttl=52 time=35.310 ms
64 bytes from 159.8.55.4: icmp_seq=5 ttl=52 time=35.490 ms
64 bytes from 159.8.55.4: icmp_seq=6 ttl=52 time=35.025 ms
64 bytes from 159.8.55.4: icmp_seq=7 ttl=52 time=36.334 ms
^C
— 159.8.55.4 ping statistics —
8 packets transmitted, 8 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 34.576/35.518/36.338/0.609 ms
~:
I am also attaching 2 log files: One of a client session where the error occurred, one where it did not.
[game_no_error.log](< base_url >/applications/core/interface/file/attachment.php?id=9219)[game_error.log](< base_url >/applications/core/interface/file/attachment.php?id=9220)
Best regards
Addition based on sephirothsk’s link:
I changed my MTU settings according to the method described in the link, (from OS X default of 1500 to the 1472 I computed withe the said method).
Hasn’t made a difference.
As of this post, there is currently no problem server side. Could be a problem on the route to our server but from the server side there is no network error.
You could try [this.](< base_url >/index.php?/topic/25324-info-connection-losses-high-ping-and-related-issues/?p=316704)
lol well everyone was getting disconnected today.
I changed my MTU settings according to the method described in the link, (from OS X default of 1500 to the 1472 I computed withe the said method).
Hasn’t made a difference.
please, include game.log when you were disconnected with the new MTU value.
p.s.: your current MTU value can be found in game log when you try to enter the map.
it looks like this:
client: connected to 159.8.55.4|35000, MTU 1492. setting up session…
i wish you guyz would just say, known bug or something. cuz i’ve been told you guys know about server problems.
My solution is: California server, Texas server, New york (or east coast server), Server in Spain, Server in Germany, Server in Eastern Russia, Server in middle of russia, and server in western Russia, and maybe some servers in south america. like in brazil.
Better ping 4 all. God bless murica. *drops mic*
please set MTU valuse to 1460
then issue chat command
/netlog 2
this will enable low-level debugging of the net.packets.
then try to enter the map
after error occures, post your game.log
sgdmiry: As you suggested, I set my MTU to 1460, invoked /netlog 2, and am attaching the game.log from after the error happened again (got an error about the file size, so I compressed it).
[game.log.zip](< base_url >/applications/core/interface/file/attachment.php?id=9256)
nope, your game.log says MTU is 1492, not 1460:
client: connected to 159.8.55.4|35043, MTU 1492. setting up session.
…
Hi, I don’t know what you write to the gamelog, but in my settings for my ethernet I have 1460 for sure.
I did notice that the MTU you log often changes, but I am keeping my setting to 1460 since you posted your request to set it so, (see screen shot).
Is there somewhere else I should / could change my settings?
Best regards
hm, that is strange seems like the new value wasnt applied or was reverted back by the OS
ok, lets go to command line…
at first, switch back to MTU 1500.
then determine the maximum MTU value to one of our servers. use the command:
ping -D -g 1200 -G 1550 -h 10 5.153.37.199
this command will send unfragmented packets with size from 1200 to 1500 bytes, step by 10
when (if) you see string Message too long, interrupt the process.
The last good ping will show you the maximum packet size (without IP headers). Add to it 28 (the headers size) and you’ll get your maximum MTU value
On the example below its 1470+28=1498
...
1460 bytes from 5.153.37.199: icmp_seq=44 ttl=64 time=0.966 ms
1470 bytes from 5.153.37.199: icmp_seq=44 ttl=64 time=0.966 ms
ping: sendto: Message too long
Then use command line to set MTU to the found value (if it less then 1500) as per this post
after changing the value, recheck it with networksetup -getMTU
also check with this postabout MacOS auto switch back its MTU and what to do to disable this behavior
if the problem persist, screenshot all the the command windows with all your commands
I did as you suggested, but the problem persists as described.
Even after today’s update to 1.1.4.
Attachments as you requested.
The game.log consists of one successful game, and next the game where the error happened again.
Best regards
[game.log](< base_url >/applications/core/interface/file/attachment.php?id=9305)
[terminal.log](< base_url >/applications/core/interface/file/attachment.php?id=9306)
P.S.: There terminal log was created right after the error occured.
Sure, no problem.
Thanks…
and i noticed there is no command “networksetup” in your terminal logs:
have you tried to appy the command
networksetup -setMTU en0 1448
where is the output of it?
and where is the output of
networksetup -getMTU
at the very top of my console log you’ll find a command ‘networksetup -getMTU en0’.
It shows mine is currently set to 1476.
Obviously that indicates that I have previously set it so, as Mac default is 1500, as you can see earlier in this thread.
I calculated that as per the post you indicated above (last successful ping (1448) + 28 (the header) = 1476.
So I am not sure how you mean the 1448 in your latest reply, was that just an example or are you suggesting I should try that?
If so, for what reason?
Thanks and best regards
sorry, i’v missed the line at the top
but i suggest you to set the MTU a bit lower then the calculated one. just for a test. try it with 1448 or 1453
It is a magic for me that the game.log reports MTU of 1492, while you run changed value
have you tried to give a command ?
sudo sysctl -w net.inet.tcp.path_mtu_discovery=0
as per this post
and then set the MTU value?
I always wondered where the value in the log comes from (the value from the game in game.log).
I am assuming you are a developer and have access to the code. if so, can you say exactly what value is written to the log, at what point in time (in the process to obtain and hold the connection)?
The number that is written to the game log varies often and is not the value of the servers when I ping them, nor is ist equal to mine.
PS: I also made sure OS X doesn’t change my MTU settings by putting this (net.inet.tcp.path_mtu_discovery=0) in my /etc/sysctl.conf, also as suggested in the article you reference above).
In my humble opinion, none of this should be necessary, as I am not sure set setting my MTU lower is the solution to the problem.
When I use 1500 (the max for this protocol and the OS X default for a reason), it works most of the time, going down to 1478 didn’t make a difference. I could go lower until I find a stable connection and think the problem is solved, but as you well know the lower I go the worse the lag becomes.
We would bypass the problem rather than solve it.
Normally, MTU fluctuation should balance out automatically as part of the protocol, starting with the max as default and tcp/ip regulating it dynamically down until stable.
And up and down again and so on during the lifetime of the connection.
All this should happen on the level of the protocol and not be managed by the game or the client.
So I am rather suspecting a problem with how the game manages connections.
I doubt I am the only one encountering this problem.
I always wondered where the value in the log comes from (the value from the game in game.log).
I am assuming you are a developer and have access to the code. if so, can you say exactly what value is written to the log, at what point in time (in the process to obtain and hold the connection)?
The number that is written to the game log varies often and is not the value of the servers when I ping them, nor is ist equal to mine.
PS: I also made sure OS X doesn’t change my MTU settings by putting this (net.inet.tcp.path_mtu_discovery=0) in my /etc/sysctl.conf, also as suggested in the article you reference above).
In my humble opinion, none of this should be necessary, as I am not sure set setting my MTU lower is the solution to the problem.
When I use 1500 (the max for this protocol and the OS X default for a reason), it works most of the time, going down to 1478 didn’t make a difference. I could go lower until I find a stable connection and think the problem is solved, but as you well know the lower I go the worse the lag becomes.
We would bypass the problem rather than solve it.
Normally, MTU fluctuation should balance out automatically as part of the protocol, starting with the max as default and tcp/ip regulating it dynamically down until stable.
And up and down again and so on during the lifetime of the connection.
All this should happen on the level of the protocol and not be managed by the game or the client.
So I am rather suspecting a problem with how the game manages connections.
I doubt I am the only one encountering this problem.
the Game does not use its own (propriatary) network protocol.
Our game net.stack is based on 3d-party libraries (racknetto be more specific), and, of course, the OS network drivers, then to the lower level - every device on the path to the game servers. Any of them can be the one who spoils you network. The most often reason for your problem is that for some reason the relatively big packets dont reach back to you. And almost everytime this issues resolved by tuning the MTU either on your MAC/PC or on your home router, rarely on ISP. The other ways to resolve this issue is unkown for us for now
Thanks for the details.
I followed the link you provided and was glad to find that their code is now in the public domain.
I’ll look at it and see if that might give me some ideas.
I’ll see if that might get me any clues and will also check in more detail what’s going on with my router and my ISP.
I’ll post here what I find.
Thanks for your patience.