R3vo/Sandbox – User

From Bohemia Interactive Community
Jump to navigation Jump to search
mNo edit summary
mNo edit summary
Line 23: Line 23:
There are also some parameters that can be used to fine-tune network performance. You can add following entries to arma.cfg (the main Armed Assault configuration file)
There are also some parameters that can be used to fine-tune network performance. You can add following entries to arma.cfg (the main Armed Assault configuration file)


'''MaxMsgSend=<limit>;'''
{| class="wikitable"
    Maximum number of packets (aggregate messages) that can be sent in one simulation cycle ("frame").
|-
    Increasing this value can decrease lag on high upload bandwidth servers.
! Parameter !! Default !! Description
    '''Default: 128'''
|-
| MaxMsgSend || <tt>128</tt> || aximum number of packets (aggregate messages) that can be sent in one simulation cycle ("frame"). Increasing this value can decrease lag on high upload bandwidth servers.
'''MaxSizeGuaranteed=<limit>;'''
|-
    Maximum size (payload) of guaranteed packet in bytes (without headers).
| MaxSizeGuaranteed || <tt>512</tt> || Maximum size (payload) of guaranteed packet in bytes (without headers). Small messages are packed to larger packets (aggregate messages). Guaranteed packets (aggregate messages) are used for non-repetitive events like shooting.
    Small messages are packed to larger packets (aggregate messages).
|-
    Guaranteed packets (aggregate messages) are used for non-repetitive events like shooting.
| MaxSizeNonguaranteed || <tt>256</tt> || Maximum size (payload) of non-guaranteed packet in bytes (without headers). Small messages are packed to larger packets (aggregate messages). Non-guaranteed packets (aggregate messages) are used  for repetitive updates like soldier or vehicle position. Increasing this value may improve bandwidth requirement, but it may increase lag.
    '''Default: 512'''
|-
| MinBandwidth || <tt>131072</tt> || Bandwidth the server is guaranteed to have (in bps). This value helps server to estimate bandwidth available. Increasing it to too optimistic values can increase lag and CPU load, as too many messages will be sent but discarded.
'''MaxSizeNonguaranteed=<limit>;'''
|-
    Maximum size (payload) of non-guaranteed packet in bytes (without headers).
| MaxBandwidth || <tt>UNKOWN</tt> || Bandwidth the server is guaranteed to never have (in bps). This value helps the server to estimate bandwidth available.
    Small messages are packed to larger packets (aggregate messages).
|-
    Non-guaranteed packets (aggregate messages) are used  for repetitive updates like soldier or vehicle position.
| MinErrorToSend || <tt>0.001</tt> || Minimal error to send updates across network. Using a smaller value can make units  observed by binoculars or sniper rifle to move smoother at the trade off of increased network traffic.
    Increasing this value may improve bandwidth requirement, but it may increase lag.
* Example: A unit 1km (distance d = 1km) from the player with MinErrorToSend = 0.001 (METS = 0.001) would send an update when that unit moves 50m (error value E = 50).
    '''Default: 256'''
* Formula: d = sqrt[(20E)/METS] ; 1000 = sqrt[(20E)/0.001] -> E = 50
* In reality, other factors about the object are taken into effect as well according to a weighted scale.
'''MinBandwidth=<bottom_limit>;'''
* When the error value (E) between the master copy of an object (whoever "owns" the object) and a client's perceived/simulated copy of the same object >= MinErrorToSend (METS), a network update message will be sent for it.
    Bandwidth the server is guaranteed to have (in bps).
|-
    This value helps server to estimate bandwidth available.
| MinErrorToSendNear || <tt>0.01</tt> || Minimal error to send updates across network for near units. Using larger value can reduce traffic sent for near units. Used to control client to server traffic as well.
    Increasing it to too optimistic values can increase lag and CPU load, as too many messages will be sent but discarded.
* When using MinErrorToSend alone, for small values of distance (d) the frequency of high errors (E) would cause excessive network messages that are not necessary but could negatively impact FPS.
    '''Default: 131072'''
* Too large of a value for METSN can prevent timely desirable network update messages which can result in units appearing to "warp"
[http://forums.bistudio.com/showthread.php?125396-Arma-2-OA-beta-build-84984&p=2103305&highlight=minerrortosend#post2103305 Detailed explanation of METS and METSN by Suma]
'''MaxBandwidth=<top_limit>;'''
|-
    Bandwidth the server is guaranteed to never have (in bps).
! colspan="3" | Networking Tuning Options
    This value helps the server to estimate bandwidth available.
|-
|
'''MinErrorToSend=<limit>;'''
  class sockets
    Minimal error to send updates across network.
  {
    Using a smaller value can make units  observed by binoculars or sniper rifle to move smoother at the trade off of
    maxPacketSize = <limit>;
    increased network traffic.
  };
    '''Default: 0.001''' ('''was 0.01''' until ARMA 2:OA version 1.60, ARMA 2 version 1.11 uses 0.01)
| <tt>1400</tt>
| Maximal size of packet sent over network. This '''can be set for both''' client-to-server and server-to-client(s) independently''! {{Feature|important|Only use in the case your router or ISP enforces lower packet size and you have connectivity issues with the game.}} ''Desync might happen if used '''MaxSizeGuaranteed/MaxSizeNonguaranteed values over the maxPacketSize'''.
'''MinErrorToSendNear=<limit>;'''
|-
    Minimal error to send updates across network for near units.
| MaxCustomFileSize || <tt>UNKNOWN</tt> || Users with custom face or custom sound larger than this size are kicked when trying to connect.
    Using larger value can reduce traffic sent for near units. Used to control client to server traffic as well.
|}
    '''Introduced in Arma 2 1.60, Default: 0.01'''


* METS:
= Notes =
** Example: A unit 1km (distance d = 1km) from the player with MinErrorToSend = 0.001 (METS = 0.001) would send an update when that unit moves 50m (error value E = 50).
The greatest level of optimization can be achieved by setting the MaxMsgSend and MinBandwidth parameters. For a server with 1024 kbps we recommend the following values:
** Formula: d = sqrt[(20E)/METS] ; 1000 = sqrt[(20E)/0.001] -> E = 50
** In reality, other factors about the object are taken into effect as well according to a weighted scale.
** When the error value (E) between the master copy of an object (whoever "owns" the object) and a client's perceived/simulated copy of the same object >= MinErrorToSend (METS), a network update message will be sent for it.
* METSN:
** When using MinErrorToSend alone, for small values of distance (d) the frequency of high errors (E) would cause excessive network messages that are not necessary but could negatively impact FPS.
** Too large of a value for METSN can prevent timely desirable network update messages which can result in units appearing to "warp"
* detailed explanation of METS and METSN by Suma: http://forums.bistudio.com/showthread.php?125396-Arma-2-OA-beta-build-84984&p=2103305&highlight=minerrortosend#post2103305
 
== Networking Tuning Options ==
'''class sockets{maxPacketSize = <limit>;};'''
    Maximal size of packet sent over network.
    This '''can be set for both''' client-to-server AND server-to-client(s) independently''!
    ''see client([[arma2.cfg#Generic_config]] or [[arma2oa.cfg#Generic_config]], )''
    '''Default: 1400'''
    {{Feature|important|Only use in the case your router or ISP enforces lower packet size and you have connectivity issues with the game.}}
    ''Desync might happen if used '''MaxSizeGuaranteed/MaxSizeNonguaranteed values over the maxPacketSize'''.
    maxPacketSize default reduced from 1490 to 1400 since 1.60, thus MaxSize... values over 1300 could be affected negatively.''
 
== Other Tuning Options ==
 
{{Feature|important|NOTE: See the [[Talk:basic.cfg|talk page]] for some more background info by Suma.}}
 
'''MaxCustomFileSize=<size_in_bits>;'''
    Users with custom face or custom sound larger than this size are kicked when trying to connect.
 
'''Note'''
The greatest level of optimization can be achieved by setting the MaxMsgSend
and MinBandwidth parameters. For a server with 1024 kbps we recommend the
following values:
     MaxMsgSend = 256;
     MaxMsgSend = 256;
     MinBandwidth = 768000;
     MinBandwidth = 768000;
While connected to the dedicated server, you can use the [[Multiplayer Server Commands|admin command]] <code>#monitor</code> to monitor server resource usage. (You have to be logged in as or voted as game admin to do this.) The server never runs at more than 50 fps. When running slower, it always uses all available CPU processing power to maintain the smoothest possible gameplay. When running at less than 20 fps, you can consider the server overloaded – the mission currently played is probably too complex for given server. If you see the server is not using bandwidth that it could use, you can try increasing values MaxMsgSend and MinBandwidth.
While connected to the dedicated server, you can use the [[Multiplayer Server Commands|admin command]] {{ic|#monitor}} to monitor server resource usage. (You have to be logged in as or voted as game admin to do this.) The server never runs at more than 50 fps. When running slower, it always uses all available CPU processing power to maintain the smoothest possible gameplay. When running at less than 20 fps, you can consider the server overloaded – the mission currently played is probably too complex for given server. If you see the server is not using bandwidth that it could use, you can try increasing values ''MaxMsgSend'' and ''MinBandwidth''.


== Example Configuration File ==
== Example Configuration File ==


<pre>
<pre>
// These options are created by default
language="English";
adapter=-1;
3D_Performance=1.000000;
Resolution_W=800;
Resolution_H=600;
Resolution_Bpp=32;
// These options are important for performance tuning
MinBandwidth = 131072; // Bandwidth the server is guaranteed to have (in bps). This value helps server to estimate bandwidth available. Increasing it to too optimistic values can increase lag and CPU load, as too many messages will be sent but discarded. Default: 131072
MinBandwidth = 131072; // Bandwidth the server is guaranteed to have (in bps). This value helps server to estimate bandwidth available. Increasing it to too optimistic values can increase lag and CPU load, as too many messages will be sent but discarded. Default: 131072
MaxBandwidth = 10000000000; // Bandwidth the server is guaranteed to never have. This value helps the server to estimate bandwidth available.
MaxBandwidth = 10000000000; // Bandwidth the server is guaranteed to never have. This value helps the server to estimate bandwidth available.
Line 122: Line 81:


MaxCustomFileSize = 0; // (bytes) Users with custom face or custom sound larger than this size are kicked when trying to connect.
MaxCustomFileSize = 0; // (bytes) Users with custom face or custom sound larger than this size are kicked when trying to connect.
</pre>
{{GameCategory|arma3|Multiplayer}}
----
FROM TALK PAGE<br/>
Official Response to the meaning of a Simulation Cycle
Quote:
"Simulation cycle" is what makes "frame" in a normal game.
However, as there is no rendering on server, we cannot talk
about frames, and we talk about simulation cycles instead.
One cycle break down approximately to:
simulate all units AI
simulate all units movement including collisions and physics
detect visibility between units
simulate scripts and FSMs
receive network updates about remote entities
send network updates about what has changed to the server (if on client) or to other clients (if on server)
ref: http://forums.bistudio.com/showthread.php?p=1363400
----
Related comments by Suma ({{ExternalLink|link= http://dev-heaven.net/issues/24014|text= source}})
---
Q: Does a 10x times lower MinErrorToSend mean also 10x times the traffic from the server?
A: In extreme case (provided you have enough bandwidth available) it might mean 10x more traffic.
I think it should be easy to measure the effect, using #monitor command or external tools.


</pre>
---
 
Q: Do lower MinErrorToSend take more CPU processing on the server?
 
A: Yes, some more processing, as there are more messages to handle, but I do not expect anything major.
 
---
 
Q: Do basic.cfg settings on clients also have an effect?
Like for the player entity itself or the AI under his command (AI local to the player)?
 
A: Yes, it affects what client sends to a server as well, but in a different way (the error computation is different,
it is not considering any camera position).
 
---
 
Q: From what I understand, this is limit, how much "messages" are created by engine "every frame".
As we now, there are maximum 50 frames per second. Those messages are than packed to packet
(till packet limit MaxSizeNonguaranteed is reached) and than packet is send.
Is following logic correct (when FPS on server is constant 50):
MaxMsgSend=1 means there would be maximum 50 messages (not packets) per second?
MaxMsgSend=1000 means there would be maximum 50000 messages (not packets) per second?
 
A: MaxMsgSend is maximum number of "packets" (you have described packet creation fine,
we call them "aggregate messages" internally).
 
---
 
Q: Is that correct, that every message containt motion update (or other update) ONLY FOR ONE object?
So when we have 1000 AIs near player, and we wish to have update 50x per second for all AIs,
so we must set MaxMsgSend to higher than 1000?
 
A: The aggregate message contains multiple logical messages, which are related to multiple objects.
 
 
----
 
Related comment by Suma ([http://forums.bistudio.com/showpost.php?p=2029545&postcount=5 source])
 
MinErrorToSendNear is used differently from MinErrorToSend.
When computing the error for MinErrorToSend, the error is divided by (distance_in_m/20m)^2.
Because of this, when MinErrorToSend is small enough so that distant units move smooth,
the near units move "supersmooth" (the updates are sent even when the movement is so smooth,
it makes no gameplay difference).
MinErrorToSendNear gives a way to give another absolute (not distance dependent) limit
("never send update smaller than 1 cm, even if MinErrorToSend would allow it to be sent").
 
 
----


== See Also ==
Would it be safe to assume the following based on previous knowledge and discussions?


* [[ArmA: Server configuration|Server Configuration]]
* MinErrorToSendNear (METSN) is not derived from a formula.
* [[server.cfg|Server Config File]]
* It's a statically chosen value used as the minimum overall error value (E) before a network update message will be sent.
* [[Arma 2: Startup Parameters|Arma 2 Startup Parameters]]
* [[Arma 3 Startup Parameters|Arma 3 Startup Parameters]]
* [[Arma_3_Dedicated_Server|Arma 3 Dedicated Server]]


* [[Armed Assault:Dedicated Server]]
* [[Operation Flashpoint:Dedicated Server]]


{{GameCategory|arma1| Multiplayer}}
----
{{GameCategory|arma2|Multiplayer}}
{{GameCategory|arma3|Multiplayer}}

Revision as of 13:40, 31 May 2021

Arma 3 Server Configuration Overview
Topic Pages
Setup Arma 3: Dedicated Server Arma 3: Dedicated Server (Chinese Simplified) Arma 3: Dedicated Server (Chinese Traditional)
Files Arma 3: Server Config File basic.cfg server.armaprofile
Other Multiplayer Server Commands Arma 3: Mission voting Arma 3: Headless Client

This article deals with the basic.cfg, the name means nothing, and can be called anything. The real name is determined by the -cfg command line option when launching the dedicated server or the game executable - in other words it also works for clients. When you do not provide a name, the default Arma3.cfg file is loaded located in the user profile folder.

In this configuration file you should configure your server's connectivity, mainly for performance tuning.

Performance Tuning Options

There are also some parameters that can be used to fine-tune network performance. You can add following entries to arma.cfg (the main Armed Assault configuration file)

Parameter Default Description
MaxMsgSend 128 aximum number of packets (aggregate messages) that can be sent in one simulation cycle ("frame"). Increasing this value can decrease lag on high upload bandwidth servers.
MaxSizeGuaranteed 512 Maximum size (payload) of guaranteed packet in bytes (without headers). Small messages are packed to larger packets (aggregate messages). Guaranteed packets (aggregate messages) are used for non-repetitive events like shooting.
MaxSizeNonguaranteed 256 Maximum size (payload) of non-guaranteed packet in bytes (without headers). Small messages are packed to larger packets (aggregate messages). Non-guaranteed packets (aggregate messages) are used for repetitive updates like soldier or vehicle position. Increasing this value may improve bandwidth requirement, but it may increase lag.
MinBandwidth 131072 Bandwidth the server is guaranteed to have (in bps). This value helps server to estimate bandwidth available. Increasing it to too optimistic values can increase lag and CPU load, as too many messages will be sent but discarded.
MaxBandwidth UNKOWN Bandwidth the server is guaranteed to never have (in bps). This value helps the server to estimate bandwidth available.
MinErrorToSend 0.001 Minimal error to send updates across network. Using a smaller value can make units observed by binoculars or sniper rifle to move smoother at the trade off of increased network traffic.
  • Example: A unit 1km (distance d = 1km) from the player with MinErrorToSend = 0.001 (METS = 0.001) would send an update when that unit moves 50m (error value E = 50).
  • Formula: d = sqrt[(20E)/METS] ; 1000 = sqrt[(20E)/0.001] -> E = 50
  • In reality, other factors about the object are taken into effect as well according to a weighted scale.
  • When the error value (E) between the master copy of an object (whoever "owns" the object) and a client's perceived/simulated copy of the same object >= MinErrorToSend (METS), a network update message will be sent for it.
MinErrorToSendNear 0.01 Minimal error to send updates across network for near units. Using larger value can reduce traffic sent for near units. Used to control client to server traffic as well.
  • When using MinErrorToSend alone, for small values of distance (d) the frequency of high errors (E) would cause excessive network messages that are not necessary but could negatively impact FPS.
  • Too large of a value for METSN can prevent timely desirable network update messages which can result in units appearing to "warp"

Detailed explanation of METS and METSN by Suma

Networking Tuning Options 
 class sockets
 {
    maxPacketSize = <limit>;
 };
1400 Maximal size of packet sent over network. This can be set for both client-to-server and server-to-client(s) independently!
⚠
Only use in the case your router or ISP enforces lower packet size and you have connectivity issues with the game.
Desync might happen if used MaxSizeGuaranteed/MaxSizeNonguaranteed values over the maxPacketSize.
MaxCustomFileSize UNKNOWN Users with custom face or custom sound larger than this size are kicked when trying to connect.

Notes

The greatest level of optimization can be achieved by setting the MaxMsgSend and MinBandwidth parameters. For a server with 1024 kbps we recommend the following values: 

   MaxMsgSend = 256;
   MinBandwidth = 768000;

While connected to the dedicated server, you can use the admin command #monitor to monitor server resource usage. (You have to be logged in as or voted as game admin to do this.) The server never runs at more than 50 fps. When running slower, it always uses all available CPU processing power to maintain the smoothest possible gameplay. When running at less than 20 fps, you can consider the server overloaded – the mission currently played is probably too complex for given server. If you see the server is not using bandwidth that it could use, you can try increasing values MaxMsgSend and MinBandwidth.

Example Configuration File

MinBandwidth = 131072;			// Bandwidth the server is guaranteed to have (in bps). This value helps server to estimate bandwidth available. Increasing it to too optimistic values can increase lag and CPU load, as too many messages will be sent but discarded. Default: 131072
MaxBandwidth = 10000000000;		// Bandwidth the server is guaranteed to never have. This value helps the server to estimate bandwidth available.

MaxMsgSend = 128;			// Maximum number of messages that can be sent in one simulation cycle. Increasing this value can decrease lag on high upload bandwidth servers. Default: 128
MaxSizeGuaranteed = 512;		// Maximum size of guaranteed packet in bytes (without headers). Small messages are packed to larger frames. Guaranteed messages are used for non-repetitive events like shooting. Default: 512
MaxSizeNonguaranteed = 256;		// Maximum size of non-guaranteed packet in bytes (without headers). Non-guaranteed messages are used for repetitive updates like soldier or vehicle position. Increasing this value may improve bandwidth requirement, but it may increase lag. Default: 256

MinErrorToSend = 0.001;			// Minimal error to send updates across network. Using a smaller value can make units observed by binoculars or sniper rifle to move smoother. Default: 0.001
MinErrorToSendNear = 0.01;		// Minimal error to send updates across network for near units. Using larger value can reduce traffic sent for near units. Used to control client to server traffic as well. Default: 0.01

MaxCustomFileSize = 0;			// (bytes) Users with custom face or custom sound larger than this size are kicked when trying to connect.


FROM TALK PAGE
Official Response to the meaning of a Simulation Cycle Quote: 

"Simulation cycle" is what makes "frame" in a normal game.

However, as there is no rendering on server, we cannot talk about frames, and we talk about simulation cycles instead. One cycle break down approximately to: 

simulate all units AI
simulate all units movement including collisions and physics
detect visibility between units
simulate scripts and FSMs
receive network updates about remote entities
send network updates about what has changed to the server (if on client) or to other clients (if on server)

ref: http://forums.bistudio.com/showthread.php?p=1363400


Related comments by Suma (source (dead link))

--- 

Q: Does a 10x times lower MinErrorToSend mean also 10x times the traffic from the server?

A: In extreme case (provided you have enough bandwidth available) it might mean 10x more traffic.
I think it should be easy to measure the effect, using #monitor command or external tools.

--- 

Q: Do lower MinErrorToSend take more CPU processing on the server?

A: Yes, some more processing, as there are more messages to handle, but I do not expect anything major.

--- 

Q: Do basic.cfg settings on clients also have an effect?
Like for the player entity itself or the AI under his command (AI local to the player)?

A: Yes, it affects what client sends to a server as well, but in a different way (the error computation is different,
it is not considering any camera position).

--- 

Q: From what I understand, this is limit, how much "messages" are created by engine "every frame".
As we now, there are maximum 50 frames per second. Those messages are than packed to packet
(till packet limit MaxSizeNonguaranteed is reached) and than packet is send.

Is following logic correct (when FPS on server is constant 50):
MaxMsgSend=1 means there would be maximum 50 messages (not packets) per second?
MaxMsgSend=1000 means there would be maximum 50000 messages (not packets) per second?

A: MaxMsgSend is maximum number of "packets" (you have described packet creation fine,
we call them "aggregate messages" internally).

--- 

Q: Is that correct, that every message containt motion update (or other update) ONLY FOR ONE object?
So when we have 1000 AIs near player, and we wish to have update 50x per second for all AIs,
so we must set MaxMsgSend to higher than 1000?

A: The aggregate message contains multiple logical messages, which are related to multiple objects.


Related comment by Suma (source) 

MinErrorToSendNear is used differently from MinErrorToSend.

When computing the error for MinErrorToSend, the error is divided by (distance_in_m/20m)^2.
Because of this, when MinErrorToSend is small enough so that distant units move smooth,
the near units move "supersmooth" (the updates are sent even when the movement is so smooth,
it makes no gameplay difference).

MinErrorToSendNear gives a way to give another absolute (not distance dependent) limit
("never send update smaller than 1 cm, even if MinErrorToSend would allow it to be sent").


Would it be safe to assume the following based on previous knowledge and discussions?

  • MinErrorToSendNear (METSN) is not derived from a formula.
  • It's a statically chosen value used as the minimum overall error value (E) before a network update message will be sent.


Retrieved from "https://community.bistudio.com/wiki?title=User:R3vo/Sandbox&oldid=258814"