Lags/warps

[Dragonji]

Our server started lagging really bad some time ago (don't remember when). A lot of players are complaining about lags/warps when there are more than 26 people on the server (I noticed them as well to be honest). I think I tried everything. I was testing fixedphysics, both antiwarp methods (g_antiwarp / g_skipcorrection - second one is better IMO), loaded/unloaded Luas etc... I think I tested everything on server side... Maybe you have any ideas? My userdb.db has about 3MB, can it be too much? By warps I mean that there are moments when fighting 1vs1 that my opponent "jumps" from point A to point B (his moves aren't smooth).

 

Screenshot with lagometer:

http://obrazki.elektroda.net/32_1344262380_thumb.png

 

My forcecvar file:

forcecvar snaps 20
forcecvar cl_pitchspeed 0
forcecvar cl_timenudge 0
forcecvar r_zfar 0
forcecvar cl_maxpackets 100
sv_cvar rate IN 25000 45000
//forcecvar rate 25000
forcecvar r_clamptoedge 1
forcecvar cl_nodelta 0
//sv_cvar cg_landmineNotifyType IN 1 2
forcecvar cg_gun_fovscale 0
//forcecvar cg_themedCMap 1
forcecvar r_wolffog 0
forcecvar r_drawfoliage 1
forcecvar r_znear 3
forcecvar r_showtris 0
forcecvar r_primitives 0
forcecvar r_drawworld 1
forcecvar r_drawentities 1
//forcecvar cg_drawRanks 0
//forcecvar ui_themedCursor 0

set team_maxPanzers "12%-"
set team_maxMortars "12%-"
set team_maxFlamers "12%-"
set team_maxMG42s "12%-"

[players 0-15]
set team_maxGrenLaunchers 1
set g_excludedMaps ":goldrush:fueldump:rushers11:mlb_hotchkiss:italyfp2:cathedral_final:tounine_b2:beerrun_b7a:"
[players 16-19]
set team_maxGrenLaunchers 2
set g_excludedMaps ":goldrush:fueldump:rushers11:mlb_hotchkiss:cathedral_final:tounine_b2:"
[players 20-24]
set team_maxGrenLaunchers 2
set g_excludedMaps ":goldrush:fueldump:"
[players 25-*]
set team_maxGrenLaunchers 2
set g_excludedMaps ":battery:goldrush:fueldump:purefrag:"
[/players]

 

Any thoughts are appriciated!

Edited August 6, 2012 by Dragon

[gaoesa]

* First, be sure that the getstatus exploit is properly removed from the threats.

 

* Take a look at the cpu and memory consumption with top command.

 

If the problem is recent, i.e. there wasn't problems before with same player amounts and same settings, the issue may be external. E.g. the getstatus exploiting, the ET300 which I suspect you are using.

 

3 MB user.db is not a really big yet and should not cause problems.

 

It is too early to make promises but the networking has been investigated again and it is possible that improvements will be made to the next version.

[Dragonji]

* First, be sure that the getstatus exploit is properly removed from the threats

We use IPTables method on our root with no problems so far.

 

* Take a look at the cpu and memory consumption with top command.

ET process uses around 40% of one thread when server is full (root's CPU got 4 cores which is 8 threads in HT technology).

 

If the problem is recent, i.e. there wasn't problems before with same player amounts and same settings, the issue may be external. E.g. the getstatus exploiting, the ET300 which I suspect you are using.

I think it's not caused by ET 3.00 because it would lag/warp other servers as well.

 

3 MB user.db is not a really big yet and should not cause problems.

Thanks for info.

Edited August 6, 2012 by Dragon

[gaoesa]

Do you have VPS or dedicated. One of the problems with VPS can be that the network buffering might not be sufficient with really high packet amounts.

[Dragonji]

VPS.

[Dragonji]

Funny thing, looks like our IPTables does not work. I enabled ET 3.00's built-in getstatus fix and so far the game is almost lag-free. Thank you for help gaoesa, will let you know if I have new problems

[gaoesa]

Just for curiosity, what kind of limits did you set for it?

[Dragonji]

A max of 90 requests per minute.

[belstgut]

A max of 90 requests per minute.

 

thats only build in getstatus fix.

 

in iptables we have hitcount 4 in 2 seconds

[Dragonji]

Those crappy warps are still present on Fuel Dump for example. 16v16 on this map is almost unplayable. Increasing rate to 50k helps, but just a bit.

[clan DIABOLIK]

Do you have an etconsole.log (or screenlog) activated ?

[Petbark]

Try and get some tracert done just incase it is something else causing lag.

 

I have had it before where on oyr server it turned out to be a data switch failing.

 

With lag everyone immediatly blaims server when it is actually other factors at work.

[Aniky]

Sometimes the factor can be the map itself as well, i know for instances baserace map never was actually playable above 30 players, caused to lag pretty much everyone on the server and i assume there are some other maps with the same problem.

[Dragonji]

Looks like it's not a server itself. Just played a while on an ETPub server with similar amount of players (30+) and I was warping even worse than on our own server.

[belstgut]

maybe its just that the game engine cant handle that many players at once without producing a few lags.

[phantasm]

Lag is often map-dependent. Fueldump and baserace are notorious for lag in the open areas. ET lags more when the server has to render more open map area. It has something to do with the size of the open area. I am not an expert on how maps are rendered, but I know big open maps lag more.

[Dragonji]

Lag is often map-dependent. Fueldump and baserace are notorious for lag in the open areas. ET lags more when the server has to render more open map area. It has something to do with the size of the open area. I am not an expert on how maps are rendered, but I know big open maps lag more.

I'm wondering if anything can be done about it? It's pretty damn annoying that maps like Supply or Bremen cause lags in players movement. It seems to happen only on maps where a lot of players from both teams (who shoot to each other of course) are concetrated on a small horizontally open (it doesn't matter if it's inside the building or outside) area though. Edited May 31, 2013 by Dragonji

[gaoesa]

Warping is caused by network issues. You can try to get players use proper maxpackets setting. For example if player has 125 FPS, the value to use would be 63. If he uses 100, he is still sending the 62-63 packets in a second but if he gets FPS drop to below or equal to 100, he will be sending them 100 times (or his FPS amount) in a second. It combined with delays and possible buffering by ISP, can cause sudden faster moves then regularly. Do note that the packet sizes are typically irrelevant as the packets are very small and it would be a rare case if someone wouldn't have bandwidth for the data. The packet count is the bad thing as each of them can be buffered and delayed to give way for higher priority traffic.

[Dragonji]

Sounds weird, in my logic maxpackets should be somehow dynamic then, calculated on client side.

 

A silly theory: I think (unstable) FPS connection with packets was never an issue with Jaymod. (I never had stable FPS in Jaymod but I was not lagging on full servers, regardless of maxpackets setting)

Edited May 31, 2013 by Dragonji

[gaoesa]

The packets sent is dynamic. The maxpackets setting should be dynamic too because it generates weird results when it is max.