MinErrorToSend feedback needed

[.kju 3244]

MinErrorToSend is set in the basic.cfg on the server.

MinErrorToSend basically set the cycle time of the server sending info about

units (including their position, speed, animation etc) to the clients.

MinErrorToSend is by default set to 0.01.

Now reducing the number can help to combat AI units warping and other visual

issues with remote AI units movement.

Suma considers to lower the default value.

It would be very useful to have server admins test lower values (0.005 or 0.001)

and provide feedback here on additional CPU use (like server FPS with #monitor 1)

and traffic sent by the server/received by clients.

Use the latest beta both on the server and as much as feasible for the clients too.

Especially high player count or complex missions like Warfare, Domination

and similar may not be able to cope with lower MinErrorToSend value.

That said a lower default might be still the way to go.

It might mean that some server admins have to get back to higher values

again for specific missions/scenarios.

More info here:

Bug #24015: Remote AI infantry at beaming back and forth while moving

Bug #24014: Remote AI ground vehicles at large distance are not updated properly

PS: Suma confirmed that also clients can set network values in a local basic.cfg (see this note).

Edited September 23, 2011 by .kju [PvPscene]

[Anunnaki Nibiru 10]

EXT community:

Server (100Mbit full duplex):

MinErrorToSend=0.001;

MaxMsgSend=2048;

MaxSizeGuaranteed=1400;

MaxSizeNonguaranteed=1400;

MinBandwidth=50000000;

MaxBandwidth=100000000;

All clients (basic ADSL with maximum 512kbit Upload + some reserve for TeamSpeak communication):

MinErrorToSend=0.001;

MaxMsgSend=128;

MaxSizeGuaranteed=1400;

MaxSizeNonguaranteed=1400;

MinBandwidth=256000;

MaxBandwidth=480000;

We were using those settings about 4 years on our servers (A1,A2,A2OA). Only MaxSizeNonguaranteed was 32 later 64, and about 3 months ago we switch to 1400 after some hard tests. Around this time, we start using similar settings on all our clients too.

MaxSizeNonguaranteed=32 was creating too much small packets, with many players on server it was too much packets = very big packet overheat. It is best to have bigger packets to prevent header overheat and save line bandwidth from server. Some clients can have also some limits from internet providers, how much packet per second they can accept, and any more packets about threshold can be dropped.

We are playing Domination with ACE, about 8-14 human players, some with AIs on clients.

FPS on server is around maximum for all time, after "MaxSizeNonguaranteed=1400" there is not too much traffic, compared with 32.

I was not playing on any other servers on internet, because I was not able to find any other server for YEARS, with good settings like was on our server. So on other server was too much jerky motion compared to ours.

PS: I have fixed some terms in text in WIKI to use correct terms like "packet" instead "message" (putted to bracket) or "frame" (confusing with 2. layer Ethernet frames) http://community.bistudio.com/wiki/basic.cfg#Performance_Tuning_Options .

Edited September 23, 2011 by Anunnaki Nibiru

[Horus 83]

Question... where to put basic.cfg for client.... in main installation folder,like basic.cfg file, or put that values in ArmA2OA.cfg?

Edited September 24, 2011 by Horus

[.kju 3244]

-cfg=basic.cfg => .\arma\basic.cfg

or

-cfg=x:\path\to\file\basic.cfg => x:\path\to\file\basic.cfg

[Horus 83]

thx Kju :)

[.kju 3244]

No worries buddy :bounce3:

@ Anunnaki

Why do you such high MaxSizeGuaranteed/MaxSizeNonguaranteed values?

[nobrainer 0]

Used 0.008 a long time.

Playing a lot of different coop types of games. Still warping.

Wondering if I should move down a bit.

But then again, 0.008 and 0.01 is not that far away form each other.

But can't you use it in ArmA2OA.cfg

-cfg=basic.cfg => .\arma\basic.cfg

or

-cfg=x:\path\to\file\basic.cfg => x:\path\to\file\basic.cfg

EDIT:

Sorry, I read wrong. We already use 0.001. With the result mentioned above.

Edited September 24, 2011 by NoBrainer

[Anunnaki Nibiru 10]

No worries buddy :bounce3:

@ Anunnaki

Why do you such high MaxSizeGuaranteed/MaxSizeNonguaranteed values?

This is only how big can packet be (payload), and there is no reason, why lower this value.

I prefer less number of packets per second, but with longer payload. Longer packets means less (header/crc) overhead, less game/CPU utilization and more line capacity for payload (useful data).

It works like this:

Game engine creates every frame internal game/engine "simple messages", I think every message contains one event (one object move or state, but this is not important). Don't be confused be another term "aggregate messages", which means packet. Then engine takes those "simple messages", and starts filling packet payload with those simple messages, till limit MaxSizeGuaranteed/MaxSizeNonguaranteed. When this limit is reached, packet is send, and game creates new packet and continue fill payload with rest of simple messages in queue. There is limit, how much packers (=aggregate messages) can be created every frame (MaxMsgSend). When this limit is reached, rest of simple messages are dropped (or queued to next frame, I am not sure on this one). With lower payload and many simple messages to send, there would be much more packets (=aggregate messages) per second send, and if payload is very low, and there are more players, you can even consume upload line capacity with this overhead. Even more, many players have not only bandwidth limit, but also packet rate limit (around 800-1200packets per second per whole line (all other traffics on line not just for Arma), this limit can be even lower, when they use SOHO home routers (NAT/firewall), and perhaps they can use more computers on this line.

In the case, when you have high payload, and the engine does not have many messages to send, the packet would be short (every frame there is at least one packet send, even when there are no simple messages inside). So it can't hurt, but in case when there is many simple messages (datas) to send, it can magnificently help.

Difference in response (packet delivery and confirmation time) between 64 bytes payload and 1400 bytes payload on slow ADSL line is about 25ms (12,5ms to server). I think this (12,5ms) is not noticeable at all for anyone. On Ethernet lines there is even much much less difference.

Example:

Imagine there is 1,4kBytes of data every FPS:

When ... MaxSizeGuaranteed/Nonguaranteed=1400 ... then ... ppf=1, pps=50.

When ... MaxSizeGuaranteed/Nonguaranteed=64 ... then ... ppf=22, pps=750.

Imagine there is 25,0kBytes of data every FPS:

When ... MaxSizeGuaranteed/Nonguaranteed=1400 ... then ... ppf=18, pps=900, useful payload=10,0Mbit (1,25MByte), overhead=0,28Mbit (0,036MByte) .

When ... MaxSizeGuaranteed/Nonguaranteed=64 ... then ... ppf=391, pps=19550, useful payload=10,0Mbit (1,25MByte), overhead=6,25Mbit (0,782MByte).

Note:

ppf ... packets per frame (game frame, maximum 50)

pps ... packets per second

every packet have have 38 or 42 bytes overhead (header+crc+qos)

Edited September 27, 2011 by Anunnaki Nibiru

[sickboy 13]

Used 0.008 a long time.

Playing a lot of different coop types of games. Still warping.

Wondering if I should move down a bit.

But then again, 0.008 and 0.01 is not that far away form each other.

But can't you use it in ArmA2OA.cfg

EDIT:

Sorry, I read wrong. We already use 0.001. With the result mentioned above.

Try again but with the beta patch: http://www.arma2.com/beta-patch.php

[.kju 3244]

@ Anunnaki

Great post and info! :bounce3:

A couple of questions:

1) Packet rate limit is coming from network equipment/hardware?

2) It is not the same as connection limited set by the OS?

3) Can be a low connection limit by the OS by a problem? Windows has it quite low, doesn't it?

4) Is that comment wrong for MaxSizeNonguaranteed: Increasing this value may improve bandwidth requirement, but it may increase lag. Default: 256

5) Do you think a "full" packet (aggregate message) will be sent ASAP or at the end of a frame basically?

6) Shouldn't BI bump up the defaults a little for MaxMsgSend, MaxSizeGuaranteed,MaxSizeNonguaranteed ?

7) What do you think is MinBandwidth about?

Tx :cool:

Ref: http://community.bistudio.com/wiki/basic.cfg

[andersson 285]

Truly a great post! Will update my server cfg's and try it.

Thank you!

[nobrainer 0]

Try again but with the beta patch: http://www.arma2.com/beta-patch.php

Sorry sir.

My clan has desided they won't do any beta for a while.

So I have to follow their word on this one.

Have to wait until 1.60...

:(

[sickboy 13]

Sorry sir.

My clan has desided they won't do any beta for a while.

So I have to follow their word on this one.

Have to wait until 1.60...

:(

Best MP fixes yet but your clan has decided not do betas eh? :D

Oh well. In any case, this thread is only really relevant to the beta versions.

[nobrainer 0]

oohhh

I think I might have convinced them to do beta's....

Even forcing all clients to use the same beta...

O happy days

hihi

btw: When I posted, we used beta. But not right now.

[sickboy 13]

New Beta out with minErrorToSend defaulted to 0.001, and a new property to play with: minErrorToSendNear

http://forums.bistudio.com/showthread.php?t=125396

[.kju 3244]

I am pretty happy after my brief tests.

While the movement is not perfectly smooth at closer distances (<1000m),

it seems to me this is mainly/mostly due to animation issues and not due to network issues.

Especially at large distances the minErrorToSend improves it massively.

This and the interpolation brings arma MP unit movement to another level. Excellent job!

For my final review more real MP play is needed though. Probably to happen once 1.60 is out.

[sickboy 13]

Agreed, this is some really great progress, thanks to everyone involved, testing the betas, reporting bugs and feedback, and of course the endless efforts of Suma and others at BI improving and fixing the game!

[Anunnaki Nibiru 10]

1) Packet rate limit is coming from network equipment/hardware?

Limit is mostly set by Internet providers manually to prevent flooding. Also every SOHO home routers (or ADSL modems with NAT router) have some HW limits too.

2) It is not the same as connection limited set by the OS?

No, OS (like Windows) does not have any limits as far as I know in packets per second.

3) Can be a low connection limit by the OS by a problem? Windows has it quite low, doesn't it?

Arma engine use IP UDP packets, and there are not real connections created on 3. layer. Connections are created by TCP packets, and normally, you create (establish) one connection from port to port, and when this TCP connection is established, you can send many many packets per second withouth need to create another connection between different ports.

4) Is that comment wrong for MaxSizeNonguaranteed: Increasing this value may improve bandwidth requirement, but it may increase lag. Default: 256

I think yes, it is misleading (technically it is true in some cases). Bigger payload in packet can little increase delivery time (few milliseconds), but only in case, when there are many data to send. Because when there are not to much data to send, packets are still short (short payload) so result is the same as with low value in MaxSizeNonguaranteed . But when this value is low, and there are many data to send, there would be plenty of packets created. Overhead can be greater then line capacity is, so many short packets would be send with bigger delay, and even some can be dropped (not delivered). So lower value can create many more lags and problems, than bigger value. Low value is good, but only when server and all clients are on single ethernet LAN, no other routers in the way. 100Mbit FullDuplex LAN ethernet can send great amount of small packets withouth delay or dropping. But on internet, it can do more harm than good.

5) Do you think a "full" packet (aggregate message) will be sent ASAP or at the end of a frame basically?

Normally, packet from OS are "queued" as they are created, and than send in the same order. So there is nothing like prioritization for small packets. But, you can have QoS setted on OS level, Network card level, or your Home router, or even or your internet provider. In some cases, there are way how you can prioritize small packets over bigger, but it is not easy to do. Normally, QoS prioritization is done on source/desitnation (TCP/UDP) "ports".

6) Shouldn't BI bump up the defaults a little for MaxMsgSend, MaxSizeGuaranteed,MaxSizeNonguaranteed ?

For MaxMsgSend, I think that current values are too big for clients, and OK for servers. But you must always consider the next variables in conjunction, because those together are creating how much packets and how big they would be.

For MaxSizeGuaranteed and MaxSizeNonguaranteed , I think yes, they should set this to 1400 as default.

7) What do you think is MinBandwidth about?

It is how fast is your upload line in any time, even evenings, when most people from your internet provider are "on internet". Sometimes, you can upload at nights or morning at speed about 20Mbps but evening, it goes only 10Mbpps. This is your real line speed at any time, and server/client is trying use that amount of line. Sometimes, server and client can try to send more data than you set in this limit, but those data are probably not so critical, so they can be send with bigger delay or lost in the way.

Edited October 2, 2011 by Anunnaki Nibiru

[.kju 3244]

Thanks a lot Anunnaki! Very insightful and helpful. :bounce3:

[piffaroni 10]

EXT community:

Server (100Mbit full duplex):

MinErrorToSend=0.001;

MaxMsgSend=2048;

MaxSizeGuaranteed=1400;

MaxSizeNonguaranteed=1400;

MinBandwidth=50000000;

MaxBandwidth=100000000;

All clients (basic ADSL with maximum 512kbit Upload + some reserve for TeamSpeak communication):

MinErrorToSend=0.001;

MaxMsgSend=128;

MaxSizeGuaranteed=1400;

MaxSizeNonguaranteed=1400;

MinBandwidth=256000;

MaxBandwidth=480000;

We were using those settings about 4 years on our servers (A1,A2,A2OA). Only MaxSizeNonguaranteed was 32 later 64, and about 3 months ago we switch to 1400 after some hard tests. Around this time, we start using similar settings on all our clients too.

MaxSizeNonguaranteed=32 was creating too much small packets, with many players on server it was too much packets = very big packet overheat. It is best to have bigger packets to prevent header overheat and save line bandwidth from server. Some clients can have also some limits from internet providers, how much packet per second they can accept, and any more packets about threshold can be dropped.

We are playing Domination with ACE, about 8-14 human players, some with AIs on clients.

FPS on server is around maximum for all time, after "MaxSizeNonguaranteed=1400" there is not too much traffic, compared with 32.

I was not playing on any other servers on internet, because I was not able to find any other server for YEARS, with good settings like was on our server. So on other server was too much jerky motion compared to ours.

PS: I have fixed some terms in text in WIKI to use correct terms like "packet" instead "message" (putted to bracket) or "frame" (confusing with 2. layer Ethernet frames) http://community.bistudio.com/wiki/basic.cfg#Performance_Tuning_Options .

do you use the class sockets brackets and set it to 1400? for example

class sockets

{

maxPacketSize=1400;

};

[icomrade 1]

do you use the class sockets brackets and set it to 1400? for example

class sockets

{

maxPacketSize=1400;

};

1400 is default by ArmA DON'T MAKE IT HIGHER, you will cause issues with people that have restrictions or problems with their ISP or network equipment (they will be unable to connect to your server).